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
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
delete operators, which, in their standard
versions, use exceptions to indicate memory exhaustion. You can solve this
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
(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.)
foo.cand then link with a command like
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
m68k-palmos-gcc -lPalmOSGlue foo.o bar.o
foo.ohas 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
The one you are probably interested in is
echo foo | m68k-palmos-gcc -dM -E -
You can also find this out by invoking the compiler with the
option. In addition, this will tell you that the following
-Asystem(palmos) -Acpu(m68k) -Amachine(pilot)
But assertions are less portable and not so widely known, and so probably less interesting.
sdksymbolic link affect the default SDK anymore?
-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 --
sdk in the PalmDev directory is ignored.
Instead, you should use
--default option to change the default SDK.
gdb myapp, where
myappis the Palm OS executable file you gave to
build-prc, all you'll get is
This is because the
$ gdb myapp
"myapp": not in executable format: File format not recognized
(gdb) target palmos
Undefined target command: "palmos". Try "help target".
gdbcommand 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
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