I am trying to build the RTI perftest in an i86 QNX architecture. When I try to build the makefile that I generated, I get the following:
Checking directory obj/i86QNX6.6qcc_cpp4.7.3/Release
Checking directory ../bin/i86QNX6.6qcc_cpp4.7.3/Release
qcc -V4.7.3,gcc_ntox86 -Y_cpp -lang-c++ -m64 -Wall -o ../bin/i86QNX6.6qcc_cpp4.7.3/Release/perftest_cpp obj/i86QNX6.6qcc_cpp4.7.3/Release/test.o obj/i86QNX6.6qcc_cpp4.7.3/Release/testPlugin.o obj/i86QNX6.6qcc_cpp4.7.3/Release/testSupport.o obj/i86QNX6.6qcc_cpp4.7.3/Release/Property.o obj/i86QNX6.6qcc_cpp4.7.3/Release/RTIDDSImpl.o obj/i86QNX6.6qcc_cpp4.7.3/Release/perftest_cpp.o -L/opt/RTI/ndds.5.1.0/lib/i86QNX6.6qcc_cpp4.7.3 -lnddscppz -lnddscz -lnddscorez -lm -lsocket -lpthread -lnsl -lrt -L/usr/lib/nptl
/opt/qnx/6.6.0/host/linux/x86/usr/bin/i486-pc-nto-qnx6.6.0-ld: cannot find -lpthread
/opt/qnx/6.6.0/host/linux/x86/usr/bin/i486-pc-nto-qnx6.6.0-ld: cannot find -lnsl
/opt/qnx/6.6.0/host/linux/x86/usr/bin/i486-pc-nto-qnx6.6.0-ld: cannot find -lrt
cc: /opt/qnx/6.6.0/host/linux/x86/usr/bin/i486-pc-nto-qnx6.6.0-ld error 1
make: *** [../bin/i86QNX6.6qcc_cpp4.7.3/Release/perftest_cpp] Error 1
I am not to familiar with QNX and its libraries, but when I remove those flags I get a ton of errors. Any tips on how to build the perftest for QNX or dealing with this error would be great, thanks!
My makefile has the following build line which resolves all symbols and results in a running executable:
qcc -o ../bin/i86QNX6.6qcc_cpp4.7.3/Release/perftest_cpp
obj/i86QNX6.6qcc_cpp4.7.3/Release/test.o
obj/i86QNX6.6qcc_cpp4.7.3/Release/testPlugin.o
obj/i86QNX6.6qcc_cpp4.7.3/Release/testSupport.o
obj/i86QNX6.6qcc_cpp4.7.3/Release/RTIDDSImpl.o
obj/i86QNX6.6qcc_cpp4.7.3/Release/perftest_cpp.o
-L/opt/RTI/rti_connext_dds-5.2.3/lib/i86QNX6.6qcc_cpp4.7.3
-lnddscppz -lnddscz -lnddscorez -lm -lsocket
-V4.7.3,gcc_ntox86 -Y_cpp -lang-c++ -Wall
Note that it has none of the libraries that you mention.
Related
I did not get response from Qualcomm forum so I decided to post here. When I was trying to run examples of Halide for Hexagon by running make run as written in the document. Then I got the following issue. The -lc++abi is missing.
clang++ -std=c++11 -I /opt/qcom/Hexagon_SDK/4.3.0.0/tools/HALIDE_Tools/2.3.03/Halide/include -stdlib=libc++ -O3 -g -fno-rtti -rdynamic conv3x3_generator.cpp /opt/qcom/Hexagon_SDK/4.3.0.0/tools/HALIDE_Tools/2.3.03/Halide/lib/libHalide.a /opt/qcom/Hexagon_SDK/4.3.0.0/tools/HALIDE_Tools/2.3.03/Halide/tools/GenGen.cpp -o /opt/qcom/Hexagon_SDK/4.3.0.0/tools/HALIDE_Tools/2.3.03/Halide/Examples/build/offload/hexagon_benchmarks/bin/conv3x3.generator -lz -lrt -ldl -lpthread -lm
/usr/bin/ld: cannot find -lc++abi
clang: error: linker command failed with exit code 1 (use -v to see invocation)
I checked the /usr/lib and find. So it should be there?
./x86_64-linux-gnu/libc++abi.so.1.0
./x86_64-linux-gnu/libc++abi.so.1
./llvm-10/lib/libc++abi.so.1.0
./llvm-10/lib/libc++abi.so.1
Did I miss anything or make anything stupid? Thanks!
ld is your system's host linker -- that's GNU BFD ld. clang++ must be in your PATH but it's the host clang++ and not the hexagon-clang++ that would be with Halide/Hexagon tools.
I contacted the person from Qualcomm. I am not supposed to use either /usr/bin/clang++ nor hexagon-clang++. I downloaded clang+llvm-7.0.1-x86_64-linux-gnu-ubuntu-18.04.tar.xz from https://releases.llvm.org/7.0.1/. You should use clang++ under the bin folder after you extract it. Now it works for me.
I'm trying to build one application with cross compiler on linux. Application is based on OpenEmbedded project. Compiler and all cross compiled libraries are located in build folder. But for one package build script is trying to use a library from my linux environment.
Command which is called from make script at the end:
/bin/sh ./arm-ABC-linux-gnueabi-libtool --tag=CXX --mode=link
arm-ABC-linux-gnueabi-g++ -march=armv7-a -mtune=cortex-a8
-mfpu=neon -mfloat-abi=softfp -g --std=c++0x -pthread -L/home/ABC/build/sysroots/armv7a-ABC-linux-gnueabi/opt/my/lib
-Wl,-rpath-link,/home/ABC/build/sysroots/armv7a-ABC-linux-gnueabi/opt/my/lib
-Wl,-O1 -Wl,--hash-style=gnu -L/opt/my/lib -o modbus_server_test modbus_server_test.o Serial.o SerialUtil.o Crc.o RtuFramer.o Pdu.o
SerialMaster.o
/home/ABC/build/sysroots/armv7a-ABC-linux-gnueabi/usr/local/apr/lib/libapr-2.la
-lcrypt -luuid -lrt -lcrypt -lpthread -ldl -lexpat -lstdc++
Most important from here that is use -lexpat flag for libexpat.so.1.5.2 library. This library is cross compiled and located in the build folder, and at the same time, we have one in my linux environment.
As result I recieve the next error:
| arm-ABC-linux-gnueabi-libtool: link:
arm-ABC-linux-gnueabi-g++ -march=armv7-a -mtune=cortex-a8
-mfpu=neon -mfloat-abi=softfp -g --std=c++0x -pthread -Wl,-rpath-link -Wl,/home/ABC/build/sysroots/armv7a-ABC-linux-gnueabi/opt/my/lib
-Wl,-O1 -Wl,--hash-style=gnu -o .libs/modbus_server_test modbus_server_test.o Serial.o SerialUtil.o Crc.o RtuFramer.o Pdu.o
SerialMaster.o
-L/home/ABC/build/sysroots/armv7a-ABC-linux-gnueabi/opt/my/lib
-L/opt/my/lib /usr/local/apr/lib/libapr-2.so -L/home/ABC/build/sysroots/armv7a-ABC-linux-gnueabi/usr/lib
/usr/lib/x86_64-linux-gnu/libexpat.so
/home/ABC/build/sysroots/armv7a-ABC-linux-gnueabi/usr/lib/libuuid.so
-lrt -lcrypt -lpthread -ldl /home/ABC/build/sysroots/armv7a-ABC-linux-gnueabi/usr/lib/libexpat.so
/home/ABC/build/build/sysroots/armv7a-ABC-linux-gnueabi/usr/lib/libstdc++.so
-lm -pthread -Wl,-rpath -Wl,/usr/local/apr/lib -Wl,-rpath -Wl,/home/ABC/build/sysroots/armv7a-ABC-linux-gnueabi/usr/lib
| /usr/lib/x86_64-linux-gnu/libexpat.so: file not recognized: File
format not recognized
| collect2: ld returned 1 exit status
| make[2]: *** [modbus_server_test] Error 1
From output I can see that it include two libraries: one from linux environment (/usr/lib/x86_64-linux-gnu/libexpat.so which is x86) and one from the build folder (build/sysroots/armv7a-ABC-linux-gnueabi/usr/lib/libexpat.so which is for ARM).At the end it complains about x86 type.
How can I exclude this library from searching in global environment? Why it even trying to use both of them?
I'm trying to load a library to Firefox, and I get the following error in the terminal:
http://pastebin.com/ZLryd20D,
gcc -Wall -fPIC -c 11.cpp ,
gcc -shared -o libshared.so 11.o -ldl ,
LD_PRELOAD=$PWD/libshared.so firefox ,
/bin/sh: symbol lookup error: /home/enigma/Desktop/compilacionproceso/libshared.so: undefined symbol: __gxx_personality_v0
gcc -shared -o libshared.so 11.o -ldl -lstdc++
That's the wrong solution, that happens to work on Linux by accident.
The correct command line to build your shared library is:
g++ -shared -o libshared.so 11.o
(contrary to popular belief, gcc and g++ are not the same thing).
Answer from the OP himself, taken from a revision of the question:
I solved the problem adding a flag -lstdc++ for create the library
thanks to this post
What is __gxx_personality_v0 for?
cd /directory
gcc -Wall -fPIC -c 11.cpp
gcc -shared -o libshared.so 11.o -ldl -lstdc++
LD_PRELOAD=$PWD/libshared.so program
I really want to know where does this libgdbm comes from and it seems it has been in
/usr/lib/libgdbm.so.2.0.0
/usr/local/lib/libgdbm.a
/usr/local/lib/libgdbm.la
/usr/local/lib/libgdbm.so
/usr/local/lib/libgdbm.so.3
/usr/local/lib/libgdbm.so.3.0.0
, but perl says
I used the command:
cc -o try -O2 -fno-strict-aliasing -pipe -fstack-protector -I/usr/local/include -fstack-protector -L/usr/local/lib try.c -lnsl -lgdbm -ldb -ldl -lm -lcrypt -lutil -lc
./try
and I got the following output:
./try: error while loading shared libraries: libgdbm.so.4: cannot open shared object file: No such file or directory
The program compiled OK, but exited with status 127.
(The supplied flags or libraries might be incorrect.)
You have a problem. Shall I abort Configure [y]
Ok. Stopping Configure.
so many files, I don't know why perl can't find any of them.
Try adding "-R/usr/local/lib" to LDFLAGS and/or CFLAGS environment variables.
If Linux perhaps change the order of searched directories in /etc/ld.so.conf
g++ -Wl,-rpath,/usr/local/lib -o /path-to/executable {list of .o files} -L/usr/X11R6/lib -L/usr/local/lib -lQtGui -L/usr/local/lib -L/usr/openwin/lib -lSM -lICE -lXext -lX11 -lresolv -lsocket -lnsl -lQtCore -lm -lrt -ldl -lpthread
I'm using the above command to compile an executable. Well actually a makefile is doing it for me..but regardless.
I'm getting an error with the above command:
ld: fatal: option -dn and -P are incompatible
ld: fatal: Flags processing errors
I don't see where -dn or -P are being supplied to the linker anywhere in the command or in the makefile. Where is the linker getting this info?
By trying to temporarily remove each segment of the linking command, I found that removing ",rpath,/usr/local/lib" made the thing work. Which got me thinking that I was setting linker options somewhere else in linux world.
Further investigation proved that I was setting LD_LIBRARY_PATH which included some linker options that caused the conflict. Upon changing that LD_LIBRARY_PATH, things worked as they should have.