Re: Link error

On 14/05/2008, at 7:54 PM, Vivian Chen wrote:
> Because my library has called some standard C library functions in  
> it. And when I debug the project, there's a crash.

As I've already said, without the actual error messages you're  
getting from the computer we can only guess what the problem is.

> Do you have some suggetions when use the standerd C library  
> functions in Garnet?

The short answer is "don't do it".

> In "Palm OS 68K API Documentation", it says that to use Palm OS 

> functions rather than standard C library functions directly.
...
> But Palm OS functions are also based on standard C library  
> functions. Are they?

The Palm OS functions are not based on "the standard C library". The 

standard C library is just an API that many systems provide. Palm OS  
does not provide the standard C library but it provides analogues for  
some of the functions.

When you build an app for Palm OS and you use standard C library  
functions there are 2 things you need to be aware of.

1) The function must be available. The easiest way to ensure this is  
to link to a static libc.

2) The function must not use kernel calls that are not provided on  
Palm OS. Things like string handling can be done entirely in user  
space but thing like malloc rely on the kernel to do their work.

If you are creating a .dll for the simulator then I'm pretty sure you  
must use the same standard C library that the simulator uses so you  
will need to confirm which one that is. It could be Cygwin, it could  
be the Windows C library (crt.dll) or even one of the newer Visual  
Studio libs (eg. msvcrt.dll).

Getting a crash using standard C library functions could indicate  
that you are using a function that makes kernel calls or that your C  
library's structures have not been initialised properly (eg. because  
the process that loads your .dll was using a different libc).

If you really want to use libc functions you would be better off  
implementing them yourself on top of the Palm OS APIs because then  
you would be sure that they will work identically in .dlls and as 68k  
or ARM code running on a device.

-- 
Link