I am trying to compile some C code which I inherited from a colleague. I am running into some missing library issues - that is, the output of make is
gcc -L. -L/lib -L/lib -L/lib -L/lib64 -o gnd2fmdpara gnd2fmdpara.o git_version.o -lfmd -lnumerics -lmisc -llapack -lblas -lgfortran -lm -lz
/usr/bin/ld: cannot find -llapack
/usr/bin/ld: cannot find -lblas
/usr/bin/ld: skipping incompatible /lib/libm.so when searching for -lm
I have put the libraries where the LAPACK and BLAS stuff resides on the PATH, and importantly the LD_LIBRARY_PATH, but still hit the same error.
Can anyone suggest to me how I can help my Makefile find the missing libraries? Thank you so much!
Related
I have a problem compiling the following line of code :
gcc -o main.c -ldl -lpthread -lRTU_Module main.o
I have the following error message :
/usr/bin/ld: cannot find -lRTU_Module
collect2: error: ld returned 1 exit status
When i try to find the location of my .so it returns this :
locate libRTU_Module.so
/home/owasys/workspace/AccelTest/libRTU_Module.so
/home/owasys/workspace/Compiler_gcc-linaro-5.3_patch/files/lib/libRTU_Module.so
/home/owasys/workspace/Compiler_gcc-linaro-5.3_patch/files/lib/libRTU_Module.so.1.0.11
/opt/gcc-linaro-5.3-2016.02-x86_64_arm-linux-gnueabihf/arm-linux-gnueabihf/libc/lib/libRTU_Module.so
/opt/gcc-linaro-5.3-2016.02-x86_64_arm-linux-gnueabihf/arm-linux-gnueabihf/libc/lib/libRTU_Module.so.0
/opt/gcc-linaro-5.3-2016.02-x86_64_arm-linux-gnueabihf/arm-linux-gnueabihf/libc/lib/libRTU_Module.so.0.0.0
/opt/gcc-linaro-5.3-2016.02-x86_64_arm-linux-gnueabihf/arm-linux-gnueabihf/libc/lib/libRTU_Module.so.1.0.11
I have red multiple of answer to a similar question but i have not solve my problem.
Thank you.
ld normally scans a default/configured set of dirs, generally wouldn't know about custom stuff like /home/a/b/c
Should be easy enough to fix; does this work?
dir=/home/owasys/workspace/Compiler_gcc-linaro-5.3_patch/files/lib
gcc -o main.c -ldl -lpthread -lRTU_Module.so main.o -L $dir
May need to tell the runtime link editor to search there as well, eg adding this to gcc cmd-line:
-Wl,-rpath=$dir
I'm able to compile and run my application in C on CentOS with the following parameters:
gcc test.c -o test -lpcap -lssl -lcrypto -L /usr/local/lib -L /usr/local/opt/openssl/lib/ -lhiredis
But I need to run the application on a machine where I cannot compile, nor download ex. hiredis.
So I need to compile everything together on my own CentOS - which does match in setup.
I've read about the static flag, but when doing so I get the following errors:
gcc -static test.c -o test -lpcap -lssl -lcrypto -L /usr/local/lib -L /usr/local/opt/openssl/lib/ -lhiredis
/usr/bin/ld: cannot find -lpcap
/usr/bin/ld: cannot find -lssl
/usr/bin/ld: cannot find -lcrypto
/usr/local/lib/libhiredis.a(net.o): In function `_redisContextConnectTcp':
/home/alfredballe/hiredis/net.c:399: warning: Using 'getaddrinfo' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking
collect2: error: ld returned 1 exit status
What am I doing wrong?
I follow the ffmpeg tuorial, and install ffmpeg via ppa
But when I compiled the tuorial02.c, I got gcc error:
/usr/bin/ld: /opt/ffmpeg/lib//libavcodec.a(libvorbisenc.o): undefined reference to symbol 'vorbis_encode_setup_vbr'
//usr/lib/x86_64-linux-gnu/libvorbisenc.so.2: error adding symbols: DSO missing from command line
collect2: error: ld returned 1 exit status
My compile command is:
gcc -I /opt/ffmpeg/include/ -L /opt/ffmpeg/lib/ -o tutorial02 tutorial02.c -lavformat -lavcodec -lswscale `sdl-config --cflags --libs` -lpthread -lz -lm -ldl
I have searched the reason for hours. I can't solve this. Can anyone help me?
Added I have add -lvorbisenc to the end. the error is lib not found. and libvorivisenc2 has been install. so this question is not a duplicate of Strange linking error: DSO missing from command line
And My OS is Linux mint 17.3
The error is telling you that the static library libavcodec.a references symbols from libvorbisenc but libvorbisenc isn't explicitly in your link command (though it did find a good candidate from another shared library in the link command). You'll need to add -lvorbisenc or $(pkg-config --libs vorbisenc) explicitly to your command line.
(Older versions of binutils would let you bring in shared libraries implicitly in this situation; however, newer versions of binutils are stricter.)
I find a problem in the linking process of my application. I did not have the same with gcc 4.5. It tries to link math library with the following command.
gcc -Wall -Wno-unused -MD -o mems_seektest mems_seektest.o -lm -L. -g -DASSERTS -I../src// -I../ -I../src//src -DDEBUG -lmems_internals
and report following error massages:
undefined reference to `sqrt'
Any idea ?
recent gcc/ld uses the --as-needed linker flag as default. Practically, that means libraries have to be specified in the reverse order of dependencies on the command line. If the mems_internals library needs the sqrt function your -lm after -lmems_internals.
gcc -Wall -Wno-unused -MD -o mems_seektest mems_seektest.o -L. -g -DASSERTS -I../src// -I../ -I../src//src -DDEBUG -lmems_internals -lm
I've had the same problem with gcc 4.6.1, even with only one library. This doesn't work:
$ gcc -lm eg.o -o eg
eg.o: In function `foo':
/home/nick/tmp/eg.c:5: undefined reference to `sqrt'
collect2: ld returned 1 exit status
But this does:
$ gcc eg.o -o eg -lm
I hit this because I was using "LDFLAGS=-lm" in my Makefile. Works fine if you use "LDLIBS=-lm" instead.
You didn't tell us what -lmems_internals is, but maybe the unresolved symbol comes from there. The order of the -l options is generally important to the linker, you should always put system libraries last.
You can check where the unresolved symbol comes from by using something like
nm yourLibrary | grep sqrt
if there is a U in front of sqrt the symbol is undefined.
I'd say the linker is using the wrong libm.
I'm trying to use someone else's Makefile to complile a very simple c++ library. The makefile is as follows:
JNIFLAGS=-O2 -pthread -I/usr/lib/jvm/java-6-sun/include -I/usr/lib/jvm/java-6-sun/include/linux
all:
rm -f ../dist/libUtils.so
g++ $(JNIFLAGS) -c -m32 -o com_markets_utils_dates_NativeTime.o com_markets_utils_dates_NativeTime.cpp
g++ $(JNIFLAGS) -c -m32 -o DateUtil.o DateUtil.cpp
g++ -pthread -m32 -shared -fPIC -o ../dist/libUtils.so DateUtil.cpp
g++ -pthread -m32 -shared -fPIC -o ../dist/libNativeTime.so DateUtil.o com_markets_utils_dates_NativeTime.o
This compiles fine, but the linker complains:
...
/usr/bin/ld: skipping incompatible /usr/lib/gcc/x86_64-linux-gnu/4.4.1/libstdc++.so when searching for -lstdc++
/usr/bin/ld: skipping incompatible /usr/lib/gcc/x86_64-linux-gnu/4.4.1/libstdc++.a when searching for -lstdc++
/usr/bin/ld: skipping incompatible /usr/lib/gcc/x86_64-linux-gnu/4.4.1/libstdc++.so when searching for -lstdc++
/usr/bin/ld: skipping incompatible /usr/lib/gcc/x86_64-linux-gnu/4.4.1/libstdc++.a when searching for -lstdc++
/usr/bin/ld: cannot find -lstdc++
collect2: ld returned 1 exit status
make: *** [all] Error 1
FYI, I am on Ubuntu 9.10 64bit.
Posting for future reference, a solution I found was to install g++-multilib. I had the same incompatible problem relating to -lstdc++ on g++ version 4.6.1
On further probing: g++-multilib is a dummy package which installed g++4.6-multilib which in turn installed the appropriate libstdc++.so under the /usr/lib/gcc/x86_64-linux-gnu/4.6/32 folder.
Answering my own question:
Ths solution seems to be a bit of a hack, you need to create a symlink for the 32 bit version of the library (after installing the packages mentioned in #nos's answer):
$ sudo ln -s /usr/lib32/libstdc++.so.6 /usr/lib32/libstdc++.so
Once you've done this, the linker will automagically find the correct library to use.
It seems you're compiling a 32 bit library on a 64 bit machine, however a 32 bit version of libstdc++ is not present.
Try apt-get install ia32-libs libc6-i386 libc6-dev-i386 lib32gcc1 lib32stdc++6
(btw. you're producing a .so , you should specify -fPIC when compiling your .cpp files as well)