Subject says it all, no PtNumericFloat in libph.so. I just encountered this
in Patch A, saw that Patch B was up, downloaded Patch B; same problem. This
is a wee bit of a show stopper for me at this point.
btw: Why does downloading a patch always nuke my permissions ? This is the
third time it has done it (I now know all the files I have to visit to fix
the problems, but why does this happen ?)
Previously, Rennie Allen wrote in qdn.public.qnxrtp.photon:
I can’t link against static libs, since I am writing a O-O framework for
Photon that is implemented as a shared lib. An app written using this
shared lib makes no direct photon calls (the calls are being made from the
shared lib). I am assuming that the static libs are not compiled PIC, since
this makes no sense (the only reason you would link against a static lib is
for a canned embedded system where speed and size would be tantamount).I have no intention of using the static lib so I don’t really care about the
malformed archive, but the lack of PtNumericFloat is a major problem.
Again, this is with Patch B.
If it’s any cosolation, Rennie, I reported this and other library
problems in both the original release and Patch A, and it’s still
broken in Patch B. It would be nice to either have the .so libraries
for everything, or (less useful) the .a libraries compiled -shared
(-fPIC).
Is there a technical reason why this cannot be done? It certainly
doesn’t sound like a Makefile chore.
Andrew
Previously, Rennie Allen wrote in qdn.public.qnxrtp.photon:
Subject says it all, no PtNumericFloat in libph.so. I just encountered this
in Patch A, saw that Patch B was up, downloaded Patch B; same problem. This
is a wee bit of a show stopper for me at this point.
I think I had the same problem with the shared lib. This fixed it:
From QNX Knowledge Base:
Photon Toolkit Pre-release
Linking PtNumericFloat() with static libs on QNX RTP.
PtNumericFloat is an undefined reference when linking with static libs.
PhAb has been updated for the future release.
But for older apps you need “-Bstatic -lph” added to the end of the link
line.
Linking PtNumericFloat() with static libs on QNX RTP.
PtNumericFloat is an undefined reference when linking with static libs.
PhAb has been updated for the future release.
But for older apps you need “-Bstatic -lph” added to the end of the link
line.
Thanks for the response, but this is not my problem.
I am not using PhAB.
$ nm /usr/lib/libph.so | grep PtNumericFloat (yields nothing).
$ nm /usr/lib/libph.a | grep PtNumericFloat
00000000000000c D PtNumericFloat
nm: libph.a: Malformed archive
I can’t link against static libs, since I am writing a O-O framework for
Photon that is implemented as a shared lib. An app written using this
shared lib makes no direct photon calls (the calls are being made from the
shared lib). I am assuming that the static libs are not compiled PIC, since
this makes no sense (the only reason you would link against a static lib is
for a canned embedded system where speed and size would be tantamount).
I have no intention of using the static lib so I don’t really care about the
malformed archive, but the lack of PtNumericFloat is a major problem.
Again, this is with Patch B.
If it’s any cosolation, Rennie, I reported this and other library
problems in both the original release and Patch A, and it’s still
broken in Patch B. It would be nice to either have the .so libraries
for everything, or (less useful) the .a libraries compiled -shared
(-fPIC).
Oh yes, I feel much better now 
Is there a technical reason why this cannot be done? It certainly
doesn’t sound like a Makefile chore.
I agree. Is there really a challenge here ? Is there something we don’t
know about PtNumericFloat ? Does it use advanced alien technology
captured from UFOs that is unsuitable for PIC ? Enquiring minds want
to know 
Hello
The libraries are being changed so that the little used widgets are
only in the .a libraries to improve the performance of applications. There is no alien technology in the PtNumericFloat although the developers do sometimes scare me with their intelligence (almost like they aren’t from ths world. HMMM you might be on to something).
Thanks
Rodney
Previously, John Doe wrote in qdn.public.qnxrtp.photon:
If it’s any cosolation, Rennie, I reported this and other library
problems in both the original release and Patch A, and it’s still
broken in Patch B. It would be nice to either have the .so libraries
for everything, or (less useful) the .a libraries compiled -shared
(-fPIC).Oh yes, I feel much better now >
Is there a technical reason why this cannot be done? It certainly
doesn’t sound like a Makefile chore.I agree. Is there really a challenge here ? Is there something we don’t
know about PtNumericFloat ? Does it use advanced alien technology
captured from UFOs that is unsuitable for PIC ? Enquiring minds want
to know >
\
Previously, John Doe wrote in qdn.public.qnxrtp.photon:
To put it simply, how is it intended that a shared library can be developed
that includes PtNumericFloat (and other “little used” widgets) ?
… and for completeness, PtFlash, PtHtml, and anything else hiding in
the wings, as yet undiscovered. The broader question - what is
stopping you from releasing everything as either .so or -fPIC .a
libraries?
I hate to sound like a broken record, but This Is Important.
Cheers,
Andrew
<gui@qnx.com> wrote in message
news:Voyager.010320111902.618529C@localhost.localdomain…
Hello
The libraries are being changed so that the little used widgets are
only in the .a libraries to improve the performance of applications.
There is no alien technology in the
PtNumericFloat although the developers do sometimes scare me with their
intelligence (almost like they
aren’t from ths world. HMMM you might be on to something).
With all due respect, I wouldn’t classify PtNumericFloat as being “little
used”. I would think that it would be to widgets what the letter ‘e’ is to
the alphabet. Are you saying that the .a lib (or at least PtNumericFloat.o)
is compiled PIC, so that I can link my .so against it ? If this is the case
(it seems odd - but - whatever) then I have a corrupt libph.a (at least “nm
libph.a” reports a malformed archive).
To put it simply, how is it intended that a shared library can be developed
that includes PtNumericFloat (and other “little used” widgets) ?
Rennie
Andrew Thomas <Andrew@cogent.ca> wrote:
Previously, John Doe wrote in qdn.public.qnxrtp.photon:
To put it simply, how is it intended that a shared library can be developed
that includes PtNumericFloat (and other “little used” widgets) ?… and for completeness, PtFlash, PtHtml, and anything else hiding in
the wings, as yet undiscovered. The broader question - what is
stopping you from releasing everything as either .so or -fPIC .a
libraries?I hate to sound like a broken record, but This Is Important.
Understood. It is my understanding that the shared version of the
photon library (ie S.a version) will be shipping in the future.
Additionally putting PtNumericFloat in the static will also be
changed. It was originally done so not to impose any dependancies
on the photon library on things like libm or the floating point
emulation library. However the floating point emulation library
is a run-time loaded object which is transparent to applications
using it.
Thomas
Understood. It is my understanding that the shared version of the
photon library (ie S.a version) will be shipping in the future.
Additionally putting PtNumericFloat in the static will also be
changed. It was originally done so not to impose any dependancies
on the photon library on things like libm or the floating point
emulation library. However the floating point emulation library
is a run-time loaded object which is transparent to applications
using it.
How many 32 bit devices (even embedded devices) that don’t have a
floating point unit, are you guys running into these days ? (not a
criticism, just curious - I would have thought 32 bit devices without FP
would be pretty rare).
How many 32 bit devices (even embedded devices) that don’t have a
floating point unit, are you guys running into these days ? (not a
criticism, just curious - I would have thought 32 bit devices without FP
would be pretty rare).
Almost every ARM/StrongARM processor has no FPU.
Sunil Kittur <skittur@qnx.com> wrote:
How many 32 bit devices (even embedded devices) that don’t have a
floating point unit, are you guys running into these days ? (not a
criticism, just curious - I would have thought 32 bit devices without FP
would be pretty rare).Almost every ARM/StrongARM processor has no FPU.
Several flavours of cheap PPC and MIPS CPU’s as well.
Thomas