The -p2 option is to the catalina compile command, not payload. For payload there are some other options you can try adding.
-z do a "double" reset -u 50 increase reset time (to 50ms) -o1 override the propeller version detection and force Propeller 1 (-o2 for Propeller 2). -l use older style lfsr check (for Propeller 1 only). -j disable lfsr check (for Propeller 1 only).
All these are described in the documentation, or just enter payload without any options for a list.
Since it seems to be the lfsr check that is failing, here is a command I just used - this one uses -l to try a different lfsr check:
payload -d -t1000 -z -l -o1 -u50 hello_world_3 -i
You could also try disabling the lfsr check altogether by using -j in place of -l. For example:
payload -d -t1000 -z -j -o1 -u50 hello_world_3 -i
What's odd is that you said payload works from the command line. But Geany uses exactly the same command.
Can you add just the -d option to your working command-line command and post what it prints?
@TommieBoy said:
I see that it is looking for a P2. From the Getting Started, on page 2 it says that P1 is the default and that I would need to add -P2 option to each Catalina command. I checked the Build->Set Build Commands but I don't see **-P2 **anywhere.
It is not "looking" for a P2 - payload is checking if the chip is a P2 if it fails to identify it as a P1 (because the lfsr check fails).
Also, it is worth noting that case is important in options - i.e. -P2 is not the same as -p2
I have ordered a P2 HyperRam add-on board, so Catalina should soon be able support XMM execution on P2 platforms other than the P2_EDGE (e.g the P2_EVAL).
I now have Catalina's source-level debugger (blackbox) working for Propeller 2 XMM programs (it already supported non-XMM programs), so Catalina can now debug XMM programs on the Propeller 2 using a gdb-like source level debugger. I may release this version separately, or I may wait till I also have the HyperRam working - not sure yet.
Also, I have decided to retire blackcat, which was Bob Anderson's C debugger with a GUI interface (blackbox is my command-line equivalent, necessary because blackcat is a windows-only GUI written in a Microsoft proprietary language, whereas blackbox is written in plain old C and runs on both Linux and Windows). Normally I like to give a release or two deprecation warning before I discontinue support for something, but the reality is that blackbox outstripped blackcat in functionality a while ago (since Bob no longer supports it). Also, a debugger like blackbox or blackcat is a hideously complicated program - in some respects more complicated than the compiler it supports - and I no longer have the time to support two such beasts (I used to wonder why gdb was so flaky ... until I had to write my own!)
Somehow the Project Path wasn't being used correctly. I don't know what was amiss, but under Project->Base Path, I had a specific path for the project. (C:\Parallax\Hello World).
Using File Explorer, I looked into the folder and found the .c file, but no object or binary file! Odd, because there were no compiler errors. I found a different folder called "C:\Parallax\Geany Test" and it had object and binary files!
Once I deleted the Geany Test folder, everything loaded as expected.
I continued to poke around and the only reference to "C:\Parallax\Geany Test" was listed in my Environment variables. I don't know why. I got rid of that variable too.
Under Set Build Commands, Working Directory, everything was set to %p, which I'm assuming %p = Project Properties, Base Path, which was c:\Parallax\Hello World.
Is there another place where a folder may be specified? Any idea how the object and binary files may have gotten into a folder other than the Project Base Path?
Here's what I speculate happened.
1) I opened a project called Hello World in C:\Parallax\Geany Test and created a file called Hello World.c in that folder.
2) I inadvertently closed Hello World.c in Catalina.
3) Oops! I didn't mean to do that. I created a new file from template, called it Hello World.c and saved it to c:\Parallax\Hello World.
4) I changed the Project Path to c:\Parallax\Hello World.
5) I think Catalina was still using the original Project Path.
Anyway, long story short, I'm back on track with the tutorials.
I don't know where "Geany Test" came from. Nothing to do with Catalina AFAIK. However, I probably don't correctly cater for case that someone changes the base directory of an existing project, so the "Download and Interact" payload command should probably be:
payload -p11 %x "%p/%e" -i -b%b
I'll investigate a bit more and update the next release.
Yes, I can confirm that Geany has issues in circumstances like yours. For instance, if you open a project, any file you then open is "remembered" by the project, even if it has the same name as another file already in the project. If you close the project, and then re-open it, Geany will re-open all the open files quite happily, which can make you think you are looking at the version that is part of the project. But it may not be. It may have nothing to do with the project at all.
I knew about this ambiguity, and indeed had documented it - but I had not realized quite how confusing it could get. It turns out that there is no way to write a set of Geany commands that uses both the "open" files and the "project" files consistently in such circumstances - e.g. you can make Geany always use the open version rather than the project version for "compile" and "build" commands, but not for commands like "compile all", "link" or "make".
The best solution I can come up with at the moment is that all Geany commands work on the project files except for the "compile" and "build" commands, which have to work on open file - not least because this assumption is hardcoded into the Geany tool bar - but make those commands put their output in the project directory rather than the source directory. At least that makes some kind of sense, and is something you might do if you wanted - for example - to try a different version of a file already in your project without modifying the one already there.
I believe the concept of "projects" was bolted on to Geany late, and it has not been fully washed through yet. But without re-writing Geany, the best I can do is just document it better.
Thanks Ross. I'm sure I'll remember this 'gotcha' for a good long while and take care not to duplicate files and to keep stray files away from a project.
I guess as a rule of thumb, if things don't compile and load as expected, check the folder and make sure that the object and binaries are there as expected. It only takes a minute.
Thanks for taking the time to guide me through this.
Nothing major - debugger support for XMM programs on the Propeller 2, and improved ymodem support in the Comms terminal emulator.
Here is the relevant extract from the README.TXT:
RELEASE 5.7
New Functionality
-----------------
1. Catalina's stand-alone vt100 emulator (comms.exe) has an improved ymodem
implementation and dialog box:
- A ymodem transfer can now be aborted in the middle of a send or
receive operation.
- The dialog box now responds to Windows messages. This stops Windows
complaining that the application is not responding during a long
ymodem transfer.
- The Abort button now attempts to abort both the local and the remote
ymodem applications if a transfer is in progress. Previously, it
could only abort the remote ymodem application and only while the
local ymodem application was not executing.
- The Start and Done buttons now check and give an error message if a
ymodem transfer is in progress. Previously, they simply performed their
respective actions, which could lead to a comms program lock up.
- Opening the dialog box no logner crashes comms if no port has been
opened.
2. Payload's interfile delay has been set to 500ms on Linux. This makes the
downloading of XMM programs more reliable on Linux (it was already 500ms
on Windows).
3. The blackbox source level debugger can now debug XMM programs on the
Propeller 2.
4. Some blackbox information messages have been changed to make them more
accurate.
5. Command line parameters (argc &argv) were not being correctly initialized
when programs were run under the blackbox debugger. However, note that it
is not possible to pass command-line parameters when using the debugger
so they should always be initialized to null values.
6. On all Propeller 2 platforms, the default pins to use for debugging are
now pins 62 & 63, which means that if you need to debug a program that
uses a serial HMI on those pins, you will need to have a Prop Plug
connected to some other pins, and then modify the pins specified in the
platform configuration file, which by default are as follows:
#define _BLACKCAT_RX_PIN 63
#define _BLACKCAT_TX_PIN 62
7. The blackcat debugger is no longer supported, and has not been updated
to debug Propeller 2 XMM programs. This debugger still works on Propeller
1 programs and non-XMM Propeller 2 programs, but it is now deprecated, and
has been removed from the release.
8. The Catalina-specific Geany commands (on the Build menu) have been updated
slightly to make them less confusing - e.g. 'Build' has been changed to
'Build File' and 'Compile' to 'Compile File' - these commands operate on
the currently selected file only, and not necessarily the files in the
project directory (even thought the currently selected file may have the
same name as a project file!). The 'Link' command has been changed to
'Link All' to match 'Compile All', to indicates that these commands act
on all files in the project directory. Other changes ensure that any
output generated when a project is selected end up in that project
directory.
9. Payload now accepts a baud rate of zero (i.e. -b0 or -B0) to indicate that
the default baudrate appropriate for the propeller should be used (which is
115200 on a P1 or 230400 on a P2). This was the default if NO baudrate was
specified, but Geany HAS to have a baud rate specified, so specifying it
as 0 is now allowed, and is equivalent to not specifying it. All the Geany
projects have been updated to use baud rate 0.
Other Changes
-------------
1. The compiler now reports the correct code size when compiling XMM LARGE
programs.
EDIT: I just noticed that the actual README.TXT file said "You must install this over an existing installation of Catalina.", which is not true - this is a full stand-alone release. I have now fixed it in the distribution, but if your README.TXT still says this (which you probably only noticed AFTER installing it) then just ignore it.
I updated the files to fix the README.TXT, but you may have caught it mid-update. I have just checked again now, and it looks ok to me. If your page still doesn't show the 5.7 files, or still says 5.6 is the latest version, try refreshing the page. Also, you may have to wait for the mirror sites to be updated - not sure how long that process takes.
I've just put up a very small patch update (5.7.1) to Catalina 5.7 here. No changes to Catalina, just minor changes to the build_utilities scripts and a small tweak to the BlackBox debugger ...
RELEASE 5.7.1
New Functionality
-----------------
1. The build_utilities script now deletes any existing load utilities in
Catalina's bin directory if you ask it to copy the utility binaries there.
This is to resolve an issue for those compiling for both the Propeller 1
and the Propeller 2 - previously, the Propeller 2 binaries were left in
place even if you compiled new binaries for a Propeller 1. If you did not
then explicitly specify the extension in the payload command (e.g. if you
just said 'xmm' instead of 'xmm.binary', then payload would use the
Propeller 2 '.bin' file if it existed, even when loading a Propeller 1.
It still leaves the old binaries in the utilities directory in case you
really did need both - it only deletes them from the bin directory.
Other Changes
-------------
2. Blackbox now assigns the code address to the correct line in more cases.
Previously, if the compiler emitted the same code address for two source
lines (typically if one of the lines was the beginning or end of a C block)
then BlackBox would assign the code to the FIRST such line and ignore
the fact that the same address for code applies to the other lines. But
in fact it is almost always correct to assign the code to the LAST such
line. This makes no functional difference, but it makes it more logical
when identifying which lines can have breakpoints placed on them.
Just before I finally drop BlackCat altogether - Bob Anderson's Windows GUI source-level C debugger for Catalina (BlackBox is my Windows/Linux command-line equivalent) - I thought I'd post here and see if either Bob Anderson or anyone who knows him is still around.
The main reason I didn't include BlackCat in the current release is that unlike BlackBox, BlackCat was never open source, so I have to maintain it and I can only release binary versions. I asked Bob before the last update whether I could release the source, but he never responded and I have not heard from him since.
BlackCat is written in C# and I am not very experienced at C# programming so it is very likely that at some point it will get beyond my ability to maintain - but I can't in good conscience either release his source or pass it on to anyone else to maintain without his permission.
If Bob sees this, or anyone knows how to contact him, please get in touch.
@RossH - I'm starting to use Catalina for more than just Hello World, and that means I need to use libraries. I'm reading A Tutorial on using the Catalina C Compiler and I see a bit about compiling libraries. I'd like to use the Simple Libraries that I've used in the passed.
I tried using -ldatetime but it was ignored.
I followed your steps to compile a library that I created myself. It has 173 functions so I tried Catalina -S *.c but I got too many errors to count. Mostly about missing header files, but they should all be found in the PATH.
I set CATALINA_LIBRARY to C:\Parallax\Simple Libraries, but the compiler didn't find them.
How do I incorporate these libraries into my programs? It seems to be a significant project to recompile them in two memory modes and then catalog them.
First, a command-line parameter like -ldatetime (that's minus "little l for library") tells Catalina to look for a directory called libdatetime - either in the current directory or in the library path. But you probably neither want nor need to change the library path - for the moment just create and use the library in your working directory. Catalina will always look there for libraries as well as in the path specified by CATALINA_LIBRARY - but If you change the library path then Catalina will not be able to find its own libraries. So get your library working in your working directory first.
Next, Catalina does not search the PATH for include files. If they are not standard include files then you have to tell it where to look for them using -I (that's minus capital "I for include") on the command line to specify an include path. You can use multiple -I options, and they can be absolute or relative paths. For example:
Your compile command looks ok, assuming the files are all in libdatetime:
cd libdatetime
catalina -S *.c
cd ..
Once the programs in the library compile, remember you need to run catbind in the library to create an index. For example:
cd libdatetime
catbind –i –e *.s –o catalina.index
cd ..
Then try using your library. If there are undefined symbols, it probably means the functions in your library depend on other functions that you will need to find and add.
I tried finding these "Simple Libraries" you referred to. I recall I tried to do this once before, without much luck. I found two different things that call themselves "Simple Libraries" but neither of them are really "simple" and both of them seem to be compiler-specific (see Note 1). Neither will be easy to port "in toto" to another C compiler - individual parts of them look easy enough to port, but then other parts are quite compiler-specific and I wouldn't even try. It would be easier to just rewrite them (see Note 2).
Let me know which particular Simple Libraries you are using, and I can have a deeper look.
Instead of trying to port the whole library, you may be better off identifying which specific functions you need, and then seeing if Catalina has an alternative or equivalent (it does for many of the functions I looked at, but I don't know if they are the ones you need). Then port only the specific functions you need.
In many cases, the Simple Libraries seem intended to just provide smaller versions of some standard C functions (e.g. the "stdio" functions, which can be quite memory hungry). But Catalina already offers several alternatives to those - e.g. I noticed some of Eric Smith's code in there, but Catalina already incorporates a version of his "tiny" stdio library functions, so you probably don't need the Simple Library ones when you are using Catalina - in many cases you can just use the normal stdio functions but link your program with the -ltiny command line option.
Ross.
EDITS:
Note 1: I originally wrote "gcc-specific" but it seems one of them compiles with flexgui and the other with PropGCC - so not "gcc-specific" but "compiler-specific".
Note 2: It looks like this is actually what happened - i.e. flexgui took a subset of the original gcc Simple Libraries and rewrote them for that compiler. So I guess if we could all agree on the subset we wanted to support, I could do the same for Catalina.
So, just to ensure I understand fully, the Simple Libraries can't be used as is?
They must first be compiled with the command catalina -S *.c,
then I need to use catbind to create an index?
I tried one of the smaller libraries, but I've found a ton or errors. Just one function kicked up this...
I'm not sure how to proceed from here. The Simple Libraries are so important to the flexibility of the P1, yet it seems it would be a monumental task to edit them.
Am I correct in my assessment? Or is there another way?
Comments
Hello @TommyBoy
The -p2 option is to the catalina compile command, not payload. For payload there are some other options you can try adding.
-z do a "double" reset
-u 50 increase reset time (to 50ms)
-o1 override the propeller version detection and force Propeller 1 (-o2 for Propeller 2).
-l use older style lfsr check (for Propeller 1 only).
-j disable lfsr check (for Propeller 1 only).
All these are described in the documentation, or just enter payload without any options for a list.
Since it seems to be the lfsr check that is failing, here is a command I just used - this one uses -l to try a different lfsr check:
payload -d -t1000 -z -l -o1 -u50 hello_world_3 -iYou could also try disabling the lfsr check altogether by using -j in place of -l. For example:
payload -d -t1000 -z -j -o1 -u50 hello_world_3 -iWhat's odd is that you said payload works from the command line. But Geany uses exactly the same command.
Can you add just the -d option to your working command-line command and post what it prints?
Ross.
It is not "looking" for a P2 - payload is checking if the chip is a P2 if it fails to identify it as a P1 (because the lfsr check fails).
Also, it is worth noting that case is important in options - i.e. -P2 is not the same as -p2
Ross.
A quick update on progress ...
I have ordered a P2 HyperRam add-on board, so Catalina should soon be able support XMM execution on P2 platforms other than the P2_EDGE (e.g the P2_EVAL).
I now have Catalina's source-level debugger (blackbox) working for Propeller 2 XMM programs (it already supported non-XMM programs), so Catalina can now debug XMM programs on the Propeller 2 using a gdb-like source level debugger. I may release this version separately, or I may wait till I also have the HyperRam working - not sure yet.
Also, I have decided to retire blackcat, which was Bob Anderson's C debugger with a GUI interface (blackbox is my command-line equivalent, necessary because blackcat is a windows-only GUI written in a Microsoft proprietary language, whereas blackbox is written in plain old C and runs on both Linux and Windows). Normally I like to give a release or two deprecation warning before I discontinue support for something, but the reality is that blackbox outstripped blackcat in functionality a while ago (since Bob no longer supports it). Also, a debugger like blackbox or blackcat is a hideously complicated program - in some respects more complicated than the compiler it supports - and I no longer have the time to support two such beasts (I used to wonder why gdb was so flaky ... until I had to write my own!)
Ross.
Hello Ross,
A new day, a new result.
Somehow the Project Path wasn't being used correctly. I don't know what was amiss, but under Project->Base Path, I had a specific path for the project. (C:\Parallax\Hello World).
Using File Explorer, I looked into the folder and found the .c file, but no object or binary file! Odd, because there were no compiler errors. I found a different folder called "C:\Parallax\Geany Test" and it had object and binary files!
Once I deleted the Geany Test folder, everything loaded as expected.
I continued to poke around and the only reference to "C:\Parallax\Geany Test" was listed in my Environment variables. I don't know why. I got rid of that variable too.
Under Set Build Commands, Working Directory, everything was set to %p, which I'm assuming %p = Project Properties, Base Path, which was c:\Parallax\Hello World.
Is there another place where a folder may be specified? Any idea how the object and binary files may have gotten into a folder other than the Project Base Path?
Here's what I speculate happened.
1) I opened a project called Hello World in C:\Parallax\Geany Test and created a file called Hello World.c in that folder.
2) I inadvertently closed Hello World.c in Catalina.
3) Oops! I didn't mean to do that. I created a new file from template, called it Hello World.c and saved it to c:\Parallax\Hello World.
4) I changed the Project Path to c:\Parallax\Hello World.
5) I think Catalina was still using the original Project Path.
Anyway, long story short, I'm back on track with the tutorials.
Cheers!
Hello @TommyBoy
I don't know where "Geany Test" came from. Nothing to do with Catalina AFAIK. However, I probably don't correctly cater for case that someone changes the base directory of an existing project, so the "Download and Interact" payload command should probably be:
payload -p11 %x "%p/%e" -i -b%bI'll investigate a bit more and update the next release.
Glad you are back on track.
Ross.
Hello @TommyBoy
Yes, I can confirm that Geany has issues in circumstances like yours. For instance, if you open a project, any file you then open is "remembered" by the project, even if it has the same name as another file already in the project. If you close the project, and then re-open it, Geany will re-open all the open files quite happily, which can make you think you are looking at the version that is part of the project. But it may not be. It may have nothing to do with the project at all.
I knew about this ambiguity, and indeed had documented it - but I had not realized quite how confusing it could get. It turns out that there is no way to write a set of Geany commands that uses both the "open" files and the "project" files consistently in such circumstances - e.g. you can make Geany always use the open version rather than the project version for "compile" and "build" commands, but not for commands like "compile all", "link" or "make".
The best solution I can come up with at the moment is that all Geany commands work on the project files except for the "compile" and "build" commands, which have to work on open file - not least because this assumption is hardcoded into the Geany tool bar - but make those commands put their output in the project directory rather than the source directory. At least that makes some kind of sense, and is something you might do if you wanted - for example - to try a different version of a file already in your project without modifying the one already there.
I believe the concept of "projects" was bolted on to Geany late, and it has not been fully washed through yet. But without re-writing Geany, the best I can do is just document it better.
Ross.
Thanks Ross. I'm sure I'll remember this 'gotcha' for a good long while and take care not to duplicate files and to keep stray files away from a project.
I guess as a rule of thumb, if things don't compile and load as expected, check the folder and make sure that the object and binaries are there as expected. It only takes a minute.
Thanks for taking the time to guide me through this.
Ross, is there a way to load code over the air to an Activity Board WX?
Not with my loaders. But Propeller 1 Catalina LMM or CMM programs (but not XMM, EMM or SMM) should be able to be loaded with any loader.
Ross.
Catalina 5.7 has been released here.
Nothing major - debugger support for XMM programs on the Propeller 2, and improved ymodem support in the Comms terminal emulator.
Here is the relevant extract from the README.TXT:
RELEASE 5.7 New Functionality ----------------- 1. Catalina's stand-alone vt100 emulator (comms.exe) has an improved ymodem implementation and dialog box: - A ymodem transfer can now be aborted in the middle of a send or receive operation. - The dialog box now responds to Windows messages. This stops Windows complaining that the application is not responding during a long ymodem transfer. - The Abort button now attempts to abort both the local and the remote ymodem applications if a transfer is in progress. Previously, it could only abort the remote ymodem application and only while the local ymodem application was not executing. - The Start and Done buttons now check and give an error message if a ymodem transfer is in progress. Previously, they simply performed their respective actions, which could lead to a comms program lock up. - Opening the dialog box no logner crashes comms if no port has been opened. 2. Payload's interfile delay has been set to 500ms on Linux. This makes the downloading of XMM programs more reliable on Linux (it was already 500ms on Windows). 3. The blackbox source level debugger can now debug XMM programs on the Propeller 2. 4. Some blackbox information messages have been changed to make them more accurate. 5. Command line parameters (argc &argv) were not being correctly initialized when programs were run under the blackbox debugger. However, note that it is not possible to pass command-line parameters when using the debugger so they should always be initialized to null values. 6. On all Propeller 2 platforms, the default pins to use for debugging are now pins 62 & 63, which means that if you need to debug a program that uses a serial HMI on those pins, you will need to have a Prop Plug connected to some other pins, and then modify the pins specified in the platform configuration file, which by default are as follows: #define _BLACKCAT_RX_PIN 63 #define _BLACKCAT_TX_PIN 62 7. The blackcat debugger is no longer supported, and has not been updated to debug Propeller 2 XMM programs. This debugger still works on Propeller 1 programs and non-XMM Propeller 2 programs, but it is now deprecated, and has been removed from the release. 8. The Catalina-specific Geany commands (on the Build menu) have been updated slightly to make them less confusing - e.g. 'Build' has been changed to 'Build File' and 'Compile' to 'Compile File' - these commands operate on the currently selected file only, and not necessarily the files in the project directory (even thought the currently selected file may have the same name as a project file!). The 'Link' command has been changed to 'Link All' to match 'Compile All', to indicates that these commands act on all files in the project directory. Other changes ensure that any output generated when a project is selected end up in that project directory. 9. Payload now accepts a baud rate of zero (i.e. -b0 or -B0) to indicate that the default baudrate appropriate for the propeller should be used (which is 115200 on a P1 or 230400 on a P2). This was the default if NO baudrate was specified, but Geany HAS to have a baud rate specified, so specifying it as 0 is now allowed, and is equivalent to not specifying it. All the Geany projects have been updated to use baud rate 0. Other Changes ------------- 1. The compiler now reports the correct code size when compiling XMM LARGE programs.EDIT: I just noticed that the actual README.TXT file said "You must install this over an existing installation of Catalina.", which is not true - this is a full stand-alone release. I have now fixed it in the distribution, but if your README.TXT still says this (which you probably only noticed AFTER installing it) then just ignore it.
I just went to download the update, but the file name says it's 5.6. See highlighted in yellow.
Hi @TommieBoy
I updated the files to fix the README.TXT, but you may have caught it mid-update. I have just checked again now, and it looks ok to me. If your page still doesn't show the 5.7 files, or still says 5.6 is the latest version, try refreshing the page. Also, you may have to wait for the mirror sites to be updated - not sure how long that process takes.
Ross.
Great! All good now.
I've just put up a very small patch update (5.7.1) to Catalina 5.7 here. No changes to Catalina, just minor changes to the build_utilities scripts and a small tweak to the BlackBox debugger ...
Just before I finally drop BlackCat altogether - Bob Anderson's Windows GUI source-level C debugger for Catalina (BlackBox is my Windows/Linux command-line equivalent) - I thought I'd post here and see if either Bob Anderson or anyone who knows him is still around.
The main reason I didn't include BlackCat in the current release is that unlike BlackBox, BlackCat was never open source, so I have to maintain it and I can only release binary versions. I asked Bob before the last update whether I could release the source, but he never responded and I have not heard from him since.
BlackCat is written in C# and I am not very experienced at C# programming so it is very likely that at some point it will get beyond my ability to maintain - but I can't in good conscience either release his source or pass it on to anyone else to maintain without his permission.
If Bob sees this, or anyone knows how to contact him, please get in touch.
Ross.
.
@RossH - I'm starting to use Catalina for more than just Hello World, and that means I need to use libraries. I'm reading A Tutorial on using the Catalina C Compiler and I see a bit about compiling libraries. I'd like to use the Simple Libraries that I've used in the passed.
I tried using -ldatetime but it was ignored.
I followed your steps to compile a library that I created myself. It has 173 functions so I tried
Catalina -S *.cbut I got too many errors to count. Mostly about missing header files, but they should all be found in the PATH.I set CATALINA_LIBRARY to C:\Parallax\Simple Libraries, but the compiler didn't find them.
How do I incorporate these libraries into my programs? It seems to be a significant project to recompile them in two memory modes and then catalog them.
Guidance please.
Hello @TommieBoy
First, a command-line parameter like -ldatetime (that's minus "little l for library") tells Catalina to look for a directory called libdatetime - either in the current directory or in the library path. But you probably neither want nor need to change the library path - for the moment just create and use the library in your working directory. Catalina will always look there for libraries as well as in the path specified by CATALINA_LIBRARY - but If you change the library path then Catalina will not be able to find its own libraries. So get your library working in your working directory first.
Next, Catalina does not search the PATH for include files. If they are not standard include files then you have to tell it where to look for them using -I (that's minus capital "I for include") on the command line to specify an include path. You can use multiple -I options, and they can be absolute or relative paths. For example:
Your compile command looks ok, assuming the files are all in libdatetime:
Once the programs in the library compile, remember you need to run catbind in the library to create an index. For example:
Then try using your library. If there are undefined symbols, it probably means the functions in your library depend on other functions that you will need to find and add.
Ross.
Hello @TommyBoy
I tried finding these "Simple Libraries" you referred to. I recall I tried to do this once before, without much luck. I found two different things that call themselves "Simple Libraries" but neither of them are really "simple" and both of them seem to be compiler-specific (see Note 1). Neither will be easy to port "in toto" to another C compiler - individual parts of them look easy enough to port, but then other parts are quite compiler-specific and I wouldn't even try. It would be easier to just rewrite them (see Note 2).
Let me know which particular Simple Libraries you are using, and I can have a deeper look.
Instead of trying to port the whole library, you may be better off identifying which specific functions you need, and then seeing if Catalina has an alternative or equivalent (it does for many of the functions I looked at, but I don't know if they are the ones you need). Then port only the specific functions you need.
In many cases, the Simple Libraries seem intended to just provide smaller versions of some standard C functions (e.g. the "stdio" functions, which can be quite memory hungry). But Catalina already offers several alternatives to those - e.g. I noticed some of Eric Smith's code in there, but Catalina already incorporates a version of his "tiny" stdio library functions, so you probably don't need the Simple Library ones when you are using Catalina - in many cases you can just use the normal stdio functions but link your program with the -ltiny command line option.
Ross.
EDITS:
Note 1: I originally wrote "gcc-specific" but it seems one of them compiles with flexgui and the other with PropGCC - so not "gcc-specific" but "compiler-specific".
Note 2: It looks like this is actually what happened - i.e. flexgui took a subset of the original gcc Simple Libraries and rewrote them for that compiler. So I guess if we could all agree on the subset we wanted to support, I could do the same for Catalina.
So, just to ensure I understand fully, the Simple Libraries can't be used as is?
They must first be compiled with the command catalina -S *.c,
then I need to use catbind to create an index?
I tried one of the smaller libraries, but I've found a ton or errors. Just one function kicked up this...
I'm not sure how to proceed from here. The Simple Libraries are so important to the flexibility of the P1, yet it seems it would be a monumental task to edit them.
Am I correct in my assessment? Or is there another way?