Frequently asked questions about prc-tools

This is a partial FAQ. Hopefully someone will materialise and volunteer to work on it...

I compiled with -g, but Poser didn't stop at the start of PilotMain, and when I finally broke into the debugger, all the addresses were completely messed up.

You need to link with -g as well.

Why are my code and global data bigger when I use C++ compared to when I use C?

Because of C++ features like exceptions and run-time time identification (RTTI).

We currently use one of the typical "zero run-time overhead" implementations of these features, but that implementation does have a cost in storage overhead. The extra code space used is mainly due to exception handling library routines which are pulled in during linking if you use exceptions. The global data overhead is due to various data tables generated for both exceptions and RTTI.

Especially if you are using C++ "as a better C", you may not be using these features anyway. You can avoid the storage overhead by compiling your code with -fno-exceptions -fno-rtti.

You also need to ensure that any C++ libraries with which you link were also compiled with these options. In practice, the usual culprits are the new and delete operators, which, in their standard versions, use exceptions to indicate memory exhaustion. You can solve this by overriding operator new et al with non-throwing versions (although of course you will then be using non-Standard C++). You can do this yourself, or you can use libnoexcept.a, which is provided by prc-tools for this purpose, by linking your code with -lnoexcept.

(The array versions of operator new[] were omitted from libnoexcept.a in prc-tools versions prior to 2.1. If you use these operators and the library, you should upgrade to the current version.)

(If you are wanting to use exceptions, you should note that actually throwing an exception is probably currently broken anyway, due to a bug in prc-tools.)

Why do I get "undefined reference" errors for Palm OS glue functions even though I'm linking with the PalmOSGlue library?

As noted in the linker documentation and the C FAQ, if you use a Palm OS glue function in foo.c and then link with a command like
m68k-palmos-gcc -lPalmOSGlue foo.o bar.o
then you're not actually gaining anything from libPalmOSGlue. The linker examines the specified object files and libraries in turn from left to right, and each library is searched to satisfy any unresolved references at the point at which it appears. In the example above, there aren't any unresolved references yet when -lPalmOSGlue appears because foo.o has not yet been examined, so nothing gets pulled in from the library.

Unless you have a reason for doing otherwise, libraries should be specified at the end of a link command line:

m68k-palmos-gcc foo.o bar.o -lPalmOSGlue

What preprocessor macros are predefined?

As the preprocessor documentation mentions, the best way to find out what macros are predefined by the preprocessor is to ask it:
echo foo | m68k-palmos-gcc -dM -E -
The one you are probably interested in is __palmos__.

You can also find this out by invoking the compiler with the -v option. In addition, this will tell you that the following assertions are predefined:

-Asystem(palmos) -Acpu(m68k) -Amachine(pilot)

But assertions are less portable and not so widely known, and so probably less interesting.

Why doesn't changing the sdk symbolic link affect the default SDK anymore?

In previous versions of prc-tools, the default SDK (i.e. the one that is used if you don't use any -palmosN option) was controlled by a symbolic link in the PalmDev directory:
$ cd /opt/palmdev or cd /PalmDev
$ ls -l
lrwxrwxrwx    1 root     root            5 May 25 16:43 sdk -> sdk-4
drwxr-xr-x    4 root     root         4096 Feb 21 14:50 sdk-3.5
drwxr-xr-x    4 root     root         4096 Feb 21 12:50 sdk-4

From prc-tools 2.1 onwards, anything -- symlink, directory, or otherwise -- named sdk in the PalmDev directory is ignored. Instead, you should use palmdev-prep's -d or --default option to change the default SDK.

Why doesn't the command "gdb myapp" work? It didn't understand "target palmos" either.

If you use gdb myapp, where myapp is the Palm OS executable file you gave to build-prc, all you'll get is
$ gdb myapp
"myapp": not in executable format: File format not recognized
(gdb) target palmos
Undefined target command: "palmos". Try "help target".
This is because the gdb command is a native debugger, for use on programs running locally on your host machine and operating system. It has no Palm OS-specific functionality, and in particular it doesn't know how to connect to a remote Palm OS device.

The command you want to use instead is m68k-palmos-gdb, which is GDB configured for Palm OS and with all the needed knowledge of Palm OS:

$ m68k-palmos-gdb myapp
(gdb) target palmos
Remote debugging under PalmOS using localhost:2000

Surely there are more FAQs and answers than this!

Much of this up-to-date Palm OS programming FAQ is aimed at prc-tools.

Back to prc-tools homepage