We create a Monolithic build target for the application that uses the
library statically to test the library code out. We use a define to turn of
the trap dispatching in the library:
// If we're actually compiling the library code, then we need to
// eliminate the trap glue that would otherwise be generated from
// this header file in order to prevent compiler errors in CW Pro 2.
// One should also define BUILDING_XXX_LIB when building the
// library into an application as a monolithic executable.
#ifdef BUILDING_XXX_LIB
#define XXX_LIB_TRAP(trapNum)
#else
#define XXX_LIB_TRAP(trapNum) SYS_TRAP(trapNum)
#endif
Then add all the library code to the Monolithic target and define the
BUILDING_XXX_LIB define and then all your existing code should still work
through the library interface and the library code should be debuggable.
If you are using the A4 globals trick, then you also must turn that stuff
off with a similar mechanism:
// globals glue macro
#if !defined(BUILD_MONOLITHIC_APP)
#define EnterLibrary_(refnum) long oldA4 = SetCurA4(refnum);
#define ExitLibrary_() RestoreA4(oldA4);
#else
#define EnterLibrary_(refnum)
#define ExitLibrary_()
#endif //BUILD_MONOLITHIC_APP
Setting up your application with a Monolithic target for building your
library into your app allows one to jump back and forth from using the
library as a shared library and then to a static build where one can debug
into the library. Just don't go too long using only the Monolithic build as
you might be suprised about certain things that don't work when the library
is a shared library (use of globals, returning structures by value, etc.).
Kevin
> -----Original Message-----
> From: Greg Winton [mailto:[EMAIL PROTECTED]]
> Sent: Friday, March 05, 1999 11:06 AM
> To: [EMAIL PROTECTED]
> Subject: Re: Debugging Libraries with CW5
>
>
> Paul,
>
> At 03:49 PM 3/5/99 +0000, you wrote:
> >Has anyone been able to debug shared libraries on the palm.
>
> The short answer is that you can't debug shared libraries.
>
> What we do is develop the library in two parts. The public
> API functions
> lock the global data and immediately pass them on to private
> functions.
> These private function perform the actual functionality for the shared
> library. They return the appropriate value to the public
> function. The
> public function unlocks the globals and returns.
>
> Why this approach? We build testers that directly link to the private
> implementation, so we can debug that. This means that if there is a
> problem with the shared library, we can find it with the
> tester if its a
> bug in the implementation. If not, then it is something
> specific to the
> shared library plumbing.
>
> Anyhow, that's the general approach.
>
> I hope this helps.
>
> Regards,
> Greg
>
>
> Greg Winton
> Bachmann Software and Services, LLC
> mailto:[EMAIL PROTECTED]
> http://www.bachmannsoftware.com
> Software Development for Handheld & Mobile Computing, Windows
> and the Internet
> Home of Bachmann Print Manager, the only graphical printing
> solution for
> the Palm Computing Platform
>
>
