People moving to Palm OS from other platforms often want to build shared libraries on the device that use C++ features. This usually is a bad idea, because traditional 68K shared libraries on Palm OS are very limited, and those limitations cause real problems with C++ code.
First, lets look at how system shared libraries actually work. A Palm OS shared library is a single code resource with type 'libr' and ID 0 that stored in a resource database. When an application wants to call a shared library function, it first has to install the shared library using the SysLibLoad API call. Usually, the application will check first to see if the library is already loaded using the SysLibFind call, and will refrain from unloading the library when finished if it was loaded originally. To the application, the net result of this is a LibRef value, which is used for all future calls to the library.
A shared library call is actually done using the same system trap mechanism used to call OS functions. This causes the first problem with C++; for the shared library call to work, the LibRef value has to be the first argument passed to the function, but a C++ method call passes the "this" pointer as a hidden first argument. You've got a conflict here. The reason this first argument has to be the library reference is that your call doesn't go directly to the shared library code. It actually goes into the OS, where the LibRef is used to determine to which shared library in the system the call should be dispatched. If that argument weren't first on the stack, the OS wouldn't know how to route the call, and the whole shared library mechanism would fail.
So, we know that we can't call a C++ method in a shared library using the standard mechanism. Why can't I use C++ in the library and just expose a C interface? You can do this, but now you hit on another Palm OS shared library limitation: libraries don't have access to read/write global variables. Lots of features in C++ depend on global variables being available, including virtual functions, exception handling, and RTTI. Other C++ features, including new and delete, depend on a either the developer or the compiler's runtime library providing implementation code.
If you can live with those limits, you can use C++ for your shared library implementation, but I suspect most of the people wanting C++ shared libraries want to export classes, and that's just not supported or possible using the current mechanism. You have a C function that returns an interface pointer, similar to COM, but the shared library can't hold the virtual tables needed to make this work.
I'll talk more about the mechanics of how shared libraries work for the implementer later; the default way of implementing library installation doesn't support multiple code segments, but I have some ideas about how they could be done by creative and masochistic developers.
Note: some of this text doesn't apply to GLib shared libraries, an alternative mechanism supported by prc-tools. Ian Goldberg's article on GLib shared libraries is quite informative.