This happened to me, too. Elia was nice enough to point out to me that when
CW updates and R4 project to R5, it sets the 'Floating Point' library in
the 68k Processor Panel back to Library. Setting this back to 'PalmOS'
will do the trick.
Alan Pinstein
Synergy Solutions, Inc.
http://www.synsolutions.com
1-800-210-5293
>I'll dig through source control for the preprocessor that was used in R4 and
>see if _DONT_USE_FP_TRAPS_ was defined by the compiler previously, but we're
>not in the habit of taking features out. The tools need to support 1.0
>devices, regardless of what percent of the installed base use them (until it
>gets ridiculously low and a burden on new features). If defining
>_DONT_USE_FP_TRAPS_ before <pilot.h> is an acceptable workaround for the
>moment, we'll look into this for R6.
>
>-E
>
>> -----Original Message-----
>> From: Steve Lemke [mailto:[EMAIL PROTECTED]]
>> Sent: Tuesday, March 23, 1999 10:54 PM
>> To: [EMAIL PROTECTED]
>> Cc: Richard Wagner
>> Subject: Re: CWR5- Floating Point Library & FlpFToA() - Argghh!
>>
>>
>> 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.
>>
