I have some problems compiling my code. It’s a mix of C and C++ code.
The compiler compiles and links without any errors, but the result is
a corrupt file which is not executable (no x flag set).
I suspect it is because the linker misses some symbol, but since it does not
complain, I don’t know what it is missing.
Any ideas? QNX 6.1 on x86. Linking output below.
Cheers / Tom
$ make Grab7
QCC -w9
-o /sireos/bin/Grab7 Grab7.o GrabberServer.o GrabberInterface.o
Pxc200Server.o Image.o bmp.o writepng.o timer.o SireosUtil.o TrackerData.o /Sireos_1/QWIP-gimbal/software/math/qnx6.1/lib/expokit.o
/Sireos_1/QWIP-gimbal/software/math/qnx6.1/lib/mkl_qnx6.1_liblapack++.a
/Sireos_1/QWIP-gimbal/software/math/qnx6.1/lib/mkl_qnx6.1_libblas++.a
/Sireos_1/QWIP-gimbal/software/math/qnx6.1/lib/mkl_qnx6.1_liblamatrix++.a /Sireos_1/QWIP-gimbal/software/math/qnx6.1/lib/libmkl32_lapack.a
/Sireos_1/QWIP-gimbal/software/math/qnx6.1/lib/libmkl32_p3.a
/Sireos_1/QWIP-gimbal/software/math/qnx6.1/lib/libI77_qnx61.a
/Sireos_1/QWIP-gimbal/software/math/qnx6.1/lib/libF77_qnx61.a
/Sireos_1/QWIP-gimbal/software/math/qnx6.1/lib/randlib_qnx61.a
-Bstatic /Sireos_1/QWIP-gimbal/software/qnxvideo/drivers/pxc200.a
…/png/libpng-1.2.1/libpng.a
-Bdynamic -L/sireos/lib -lsbc -lm -lcpp -lstdc++ -lph -lphexlib
/usr/ntox86/bin/ld: warning: libm.so.1, needed by /x86/usr/lib/libstdc++.so, may conflict with libm.so.2
/usr/ntox86/bin/ld: warning: libc.so.1, needed by /x86/usr/lib/libstdc++.so, may conflict with libc.so.2
$ ls -l /sireos/bin/Grab7
-rw-rw-r-- 1 tomas sireos 10033908 Apr 16 14:23 /sireos/bin/Grab7
I have some problems compiling my code. It’s a mix of C and C++ code.
The compiler compiles and links without any errors, but the result is
a corrupt file which is not executable (no x flag set).
I suspect it is because the linker misses some symbol, but since it does
not
complain, I don’t know what it is missing.
Any ideas? QNX 6.1 on x86. Linking output below.
Cheers / Tom
$ make Grab7
QCC -w9
-o /sireos/bin/Grab7 Grab7.o GrabberServer.o GrabberInterface.o
Pxc200Server.o Image.o bmp.o writepng.o timer.o SireosUtil.o
TrackerData.o /Sireos_1/QWIP-gimbal/software/math/qnx6.1/lib/expokit.o
/Sireos_1/QWIP-gimbal/software/math/qnx6.1/lib/mkl_qnx6.1_liblapack++.a
/Sireos_1/QWIP-gimbal/software/math/qnx6.1/lib/mkl_qnx6.1_libblas++.a
/Sireos_1/QWIP-gimbal/software/math/qnx6.1/lib/mkl_qnx6.1_liblamatrix++.a
/Sireos_1/QWIP-gimbal/software/math/qnx6.1/lib/libmkl32_lapack.a
/Sireos_1/QWIP-gimbal/software/math/qnx6.1/lib/libmkl32_p3.a
/Sireos_1/QWIP-gimbal/software/math/qnx6.1/lib/libI77_qnx61.a
/Sireos_1/QWIP-gimbal/software/math/qnx6.1/lib/libF77_qnx61.a
/Sireos_1/QWIP-gimbal/software/math/qnx6.1/lib/randlib_qnx61.a
-Bstatic /Sireos_1/QWIP-gimbal/software/qnxvideo/drivers/pxc200.a
…/png/libpng-1.2.1/libpng.a
-Bdynamic -L/sireos/lib -lsbc -lm -lcpp -lstdc++ -lph -lphexlib
/usr/ntox86/bin/ld: warning: libm.so.1, needed by
/x86/usr/lib/libstdc++.so, may conflict with libm.so.2
/usr/ntox86/bin/ld: warning: libc.so.1, needed by
/x86/usr/lib/libstdc++.so, may conflict with libc.so.2
$ ls -l /sireos/bin/Grab7
-rw-rw-r-- 1 tomas sireos 10033908 Apr 16 14:23 /sireos/bin/Grab7
I got it to work finally by deleting all .o files and turning off optimization
and debug mode and finally got the warnings about missing symbols which
I needed.
I found out that I cannot use only -lcpp since the symbols _multi_threaded
and __iob are then undefined.
Tom
Tomas Högström wrote:
A good question, that must be a bug. Is -lcpp the preferred one?
But linking with only one of -lcpp or -lstdc++ doesn’t seem to help in this case.
Cheers / Tom
Allan wrote:
Why are you linking both the Dinkum Standard and the GNU C++ libraries?
-lcpp -lstdc++
Preferred? That’s for you to decide, but one or the other.
Maybe you could post the complete build output after choosing one.
Also, use objdump -x to see if there are any unexpected remaining
dependancies.
What development host are you using 6.1.0A or 6.2?
6.1.0A. Sure, I can give you some output. Both compilation and linking, and
for all files? Which warning level? You saw my posting that it works now?
Tom
Allan wrote:
Preferred? That’s for you to decide, but one or the other.
Maybe you could post the complete build output after choosing one.
Also, use objdump -x to see if there are any unexpected remaining
dependancies.
What development host are you using 6.1.0A or 6.2?
“Tomas Högström” <> tomas@scandicraft.se> > wrote in message
news:> 3CBC4AAD.1A3B1038@scandicraft.se> …
A good question, that must be a bug. Is -lcpp the preferred one?
But linking with only one of -lcpp or -lstdc++ doesn’t seem to help in
this case.
Cheers / Tom
Allan wrote:
Why are you linking both the Dinkum Standard and the GNU C++ libraries?
-lcpp -lstdc++
I think the recommended approach with C++ is to specify the “-lang-c++”
switch, and then don’t explicitly specify the C++ library.
However, I’ve had the same symptom you had when building this way. There are
unresolved linker references, but no complaints from the linker. The only
symptom is that the executable file does not have the x flags set.
I got it to work finally by deleting all .o files and turning off
optimization
and debug mode and finally got the warnings about missing symbols which
I needed.
I found out that I cannot use only -lcpp since the symbols _multi_threaded
and __iob are then undefined.
Tom
Tomas Högström wrote:
A good question, that must be a bug. Is -lcpp the preferred one?
But linking with only one of -lcpp or -lstdc++ doesn’t seem to help in
this case.
Cheers / Tom
Allan wrote:
Why are you linking both the Dinkum Standard and the GNU C++
libraries?
-lcpp -lstdc++
6.1.0A. Sure, I can give you some output. Both compilation and linking, and
for all files? Which warning level? You saw my posting that it works now?
__iob is part of the old 6.0 libc runtime, and if you have object files
or libraries that need this then you will need to recompile them with
your 6.1 development system in order for things to successfully link and
run.
Yes, I suspected that. I tried to recompile the library a while ago
but got into trouble, so I decided to use the old library. Will this
create any problems for me?
Thanks / Tom
Colin Burgess wrote:
6.1.0A. Sure, I can give you some output. Both compilation and linking, and
for all files? Which warning level? You saw my posting that it works now?
__iob is part of the old 6.0 libc runtime, and if you have object files
or libraries that need this then you will need to recompile them with
your 6.1 development system in order for things to successfully link and
run.
Yes, I suspected that. I tried to recompile the library a while ago
but got into trouble, so I decided to use the old library. Will this
create any problems for me?
Yeah, it’s not going to work I’m afraid, you’ll have to recompile.
Well, it works now. I was more thinking about what happens
when we upgrade to 6.2 or higher.
Colin Burgess wrote:
Yes, I suspected that. I tried to recompile the library a while ago
but got into trouble, so I decided to use the old library. Will this
create any problems for me?
Yeah, it’s not going to work I’m afraid, you’ll have to recompile.