Not sure how this would've worked in the past, and not now, but I was 
able to make it do the right thing by including the following at the 
top of my source file:

#define PILOT_PRECOMPILED_HEADERS_OFF 1
#define _DONT_USE_FP_TRAPS_ 1

Do this before:  #include <Pilot.h>

Give it a shot and see if it gives you the results you want...  It 
seemed to work for me.

Other than that, it may be possible to fix the Metrowerks compiler 
and/or the header files to make it work "right", but since this is 
only useful in supporting Palm OS floating point on 1.0 devices, and 
since 1.0 devices now number less than one or two percent of the 
whole installed base, I'm not sure it's worth the effort to fix it 
(or for you to support it with a separate build of your app).  Move 
on to 2.0 as a required base version for your app and you won't have 
to even worry about this anymore.  [Still, if you insist, the above 
should get it working again for you.]
--Steve


> Codewarrior R5 absolutely refuses to correctly handle the FlpFToA() in the
> metrowerks Floating Point Library!  After banging my head against the wall I
> quick put together a little app which demonstrates the problem.  The problem
> is easy to see, look at the output from the debugger:
>
>     err = FlpFToA(theComp.fd, szTemp);
> 100699CE: 486EFFD2        pea      -46(a6)
> 100699D2: 2F2EFFF4        move.l   -12(a6),-(sp)
> 100699D6: 2F2EFFF0        move.l   -16(a6),-(sp)
> 100699DA: 7401            moveq    #1,d2
> 100699DC: 4E4F            trap     #15
> 100699DE: A305            _FlpDispatch
>
> Why is it generating a TRAP???  I have the floating point set to "Library"
> in the IDE and most importantly REGULAR MATH WORKS FINE!  Yep, that's right,
> I can do multiplication, divides, et al and it correctly uses the library
> but it never links in the damn FlpFToA() function.  I checked the .MAP file
> and for some reason FlpFToA() isn't included.
>
> Looking at the NewFloatMgr.h file, I tried defining the _DONT_USE_FP_TRAPS_
> to 1
> and while it caused it to be linked, it also caused a line 1111 error in
> Poser.
>
> The part of this that really pisses me off is that it all worked perfectly
> under R4.

Reply via email to