Lacking libgdbm when installing perl - linux

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

Related

HEXAGON Halide Tools 2.3: /usr/bin/ld: cannot find -lc++abi

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.

relocation R_X86_64_PC32 against symbol _ZTISt13runtime_error##GLIBCXX_3.4 can not be used when making a shared object; recompile with -fPIC

The project I am attempting compile is not in any way complex, and references nothing but the standard library and one self-contained library (everything compiles fine on another system). As indicated by the title, it can't even link against something in the standard library, due to things in there not having been compiled with -fPIC, supposedly. I didn't build it myself, nor do I want to, and reinstalling things with apt didn't seem to resolve the "recompile with -fPIC" issue.
I will say that I think one possible source of the issue is due to gcc-multilib or something being installed earlier, but I think that was purged. I don't know, maybe something was overwritten or a conflict arose. Might not even be related. Any ideas?
Running Ubuntu 18.04
g++ -I inc -I /usr/include/mono-2.0 -MMD -MF dep/Nonsense.d -std=c++17 -O3 -fno-stack-protector -fno-unroll-loops -fomit-frame-pointer -Wno-ignored-optimization-argument -c -o obj/Nonsense.o src/Nonsense.cpp
g++ -I inc -I /usr/include/mono-2.0 -MMD -MF dep/Socket.d -std=c++17 -O3 -fno-stack-protector -fno-unroll-loops -fomit-frame-pointer -Wno-ignored-optimization-argument -c -o obj/Socket.o src/Socket.cpp
g++ -shared -flto -o libNonsense.so obj/Nonsense.o obj/Socket.o -Llib -lenet
/usr/bin/x86_64-linux-gnu-ld: obj/Socket.o: relocation R_X86_64_PC32 against symbol `_ZTISt13runtime_error##GLIBCXX_3.4' can not be used when making a shared object; recompile with -fPIC
/usr/bin/x86_64-linux-gnu-ld: final link failed: Bad value
collect2: error: ld returned 1 exit status
makefile:22: recipe for target 'libNonsense.so' failed
make: *** [libNonsense.so] Error 1
Apparently, it is compulsory to compile with the -fPIC flag in 64bits platform. If you are making a 32-bits project with linkink with 32-bits library; you don't need -fPIC.
Indeed, without -fPIC, the dynamic linker recalculates adresses for global variables and functions (which are not known in advance in the step of compilation). However, in a 64-bits system, it is not possible to use this technique as it is required to guess in advance the size of adress.
PIC (Position Independent Code), a more sophisticated and complicated process is used. https://eli.thegreenplace.net/2011/11/11/position-independent-code-pic-in-shared-libraries-on-x64 for explanations.
As the error message says, you need to recompile with -fPIC. Your current compiler command does not show the -fPIC option:
g++ -I inc -I /usr/include/mono-2.0 -MMD -MF dep/Socket.d -std=c++17 -O3 -fno-stack-protector -fno-unroll-loops -fomit-frame-pointer -Wno-ignored-optimization-argument -c -o obj/Socket.o src/Socket.cpp
Same for -flto by the way—this flag also has to be specified when compiling in order to be effective.

Use only local library with cross compiler

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?

Cannot find ldl lnsl lpthread lrt when buildling?

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.

Unable to compile C program on Mac, but able to compile on Linux

I facing some trouble compiling my programming assignment on my local machine. The program is distribute to us with makefiles and compilation commands that are known to work on the school's Scientific Linux servers. My local machine is Mac OS X El Capitan.
When I compile my program running make on my Mac, I get the following error that prevents compilation from proceeding:
myid-MacBook-Pro:mp6 myid$ make
gcc -g -lm -std=c99 -Wall -Werror -c lodepng.c
clang: error: -lm: 'linker' input unused
make: *** [lodepng.o] Error 1
But when I push that very same code as work in progress to the Linux servers and compile there, everything works fine. The linux servers use gcc and not clang:
[netid#linux-a2 mp6]$ make
gcc -g -lm -std=c99 -Wall -Werror -c functions.c
gcc -g -lm -std=c99 -Wall -Werror main.o lodepng.o imageData.o functions.o -o mp6 -lm
gcc -g -lm -std=c99 -Wall -Werror -c test.c
gcc -g -lm -std=c99 -Wall -Werror test.o lodepng.o imageData.o functions.o solution.o -o test -lm
In the makefile, these are the variable definitions:
CC=gcc
CFLAGS=-g -lm -std=c99 -Wall -Werror
and the target definition for loadpng.o
lodepng.o: lodepng.c
$(CC) $(CFLAGS) -c lodepng.c
I would appreciate any help on understanding this error and overcoming it.
Thank you very much.
Also, on this note, I thought I would say that I've noticed a subtle difference between Clang and GCC. It seems to me that even warnings generated by Clang would prevent the compilation to proceed so the warnings behaves like errors. But for GCC, if it generates warnings, it still compiles the object file. Please correct me if I'm mistaken.
Right now you're getting a compilation error on your Mac because you're trying to pass linker commands (i.e. -lm) into a compilation(i.e. -c). Do not give link flags when you compile (-c flag) your source files.
In the other compilation snippet you provided, the unused linker command seems to pass by unnoticed which isn't a good thing.
For your last question, the flag -Werror should force all compilation warnings to become errors -- which is exactly what you are describing.

Resources