I need your help about this problem if anyone has info.
I have configured speex1.2rc1 for xscale-elf (ARM architecture) ,then executed make and make install. So, I obtained libspeex.a in the /usr/local/lib with libogg.a compiled as well. but i when i link the library to my program (by adding LDFLAGS += -lspeex -lm), and try to compile, i get this error:
/usr/lib/gcc/xscale-elf/3.4.3/../../../../xscale-elf/bin/ld: cannot find -lspeex
collect2: ld returned 1 exit status
make: *** [exe0] Error 1
I passed ./configure options as :
./configure --host=xscale-elf
It's likely that the linker can't see libspeex.a, and I also tried the line LDFLAGS += /usr/local/lib/libspeex.a -lm in Makefile but got another error(also in linking):
/tmp/ccvi7Pns.o(.text+0x179c): In function `main':
: undefined reference to `BlinkC$speex_bits_init'
collect2: ld returned 1 exit status
make: *** [exe0] Error 1
./configure --host=xscale-elf
You didn't tell what host you are compiling this on, but given the path to your ld, it appears that you are cross-compiling. If so, your host is likely not xscale-elf (but probably i686-linux-gnu or some such).
You need to understand the difference between host and target, and rebuild your speex1 (whatever that is) using appropriate compiler and --target=xscale-elf.
Also, installing libraries intended for taget into /usr/local/lib is the wrong thing to do.
Related
I am compiling a golang package, which includes the integration of a shared c library using cgo.
Everything builds successfully inside docker images golang:1.15.15, golang:1.16.6, but since golang:1.16.7 (also golang:1.17) it fails with error:
/usr/bin/ld: src/foobar/lib/libXYZ.so: undefined reference to `feenableexcept'
/usr/bin/ld: src/foobar/lib/libXYZ.so: undefined reference to `floor'
...
/usr/bin/ld: src/foobar/lib/libXYZ.so: undefined reference to `memoFree'
/usr/bin/ld: src/foobar/lib/libXYZ.so: undefined reference to `memoMalloc'
collect2: error: ld returned 1 exit status
I checked the golang release notes, and could not find any relevant changes for cgo.
I checked versions of gcc and ld, those are all different. I even setup a ubuntu distro with go1.13.8, gcc (Ubuntu 8.4.0-3ubuntu2) 8.4.0 and GNU ld (GNU Binutils for Ubuntu) 2.34, where I run into this issue, so I guess, that go goes not cause it.
Do you have any clue or suggestion, how I can find the root cause of this issue? Is it right to check gcc and ld, or which other tools need investigation?
Thanks to Zyl, I was able to narrow down the problem.
I checked several distributions (bullseye, buster, stretch) and with bullseye, the build failed. In my case, neither the version of ld coming from binutils nor gcc caused the problem.
It seems, that the default settings for handling DT_NEEDED tags for the linker have changed. I resolved my problem taking the solution from https://stackoverflow.com/a/62117174/2290153 and adding export CGO_LDFLAGS=-Wl,--no-as-needed to the environment. According to https://manpages.debian.org/bullseye/binutils-common/gold.1.en.html this is the default for the ld.gold linker, but not for ld.
What helped me a lot, was the -x flag of the go build command to have a look at the gcc command being executed for cgo.
I'm trying to build GNUjump on Arch Linux (release 1 Oct. 2014), but i'm getting a strange error, and i don't know what to do.
./configure shows me no error. So, i launch make, and this appears:
/usr/bin/ld: SDL_rotozoom.o: undefined reference to symbol 'sincos##GLIBC_2.1'
/usr/lib/libm.so.6: error adding symbols: DSO missing from command line
collect2: error: ld returned 1 exit status
The same Makefile, on a Debian-based PC, works.
Surely, i'm missing something, but i don't know what.
You need to include -lm in the compiler/linker command line to link against the standard math library math.h.
See this: Why do you have to link the math library in C?
I'm trying to make a file in Ubuntu and when i make i keep getting this error:
/usr/bin/ld: ../../gtest-1.7.0/libgtest.a(gtest-all.cc.o): undefined reference to symbol 'pthread_key_delete##GLIBC_2.2.5'
/lib/x86_64-linux-gnu/libpthread.so.0: error adding symbols: DSO missing from command line
collect2: error: ld returned 1 exit status
make[2]: *** [src/tests/run_tests] Error 1
make[1]: *** [src/tests/CMakeFiles/run_tests.dir/all] Error 2
make: *** [all] Error 2
I saw someone mentioning to go into Makefile and adding '-L /lib64 -l pthread' to the variable LDFLAGS but how do you do that? Totally new to linux here =X
The above linking problem is solved by adding
-lpthread -lm to CMakeLists.txt (target link libraries for luxrender);
TARGET_LINK_LIBRARIES(... -lpthread -lm)
I hit the same issue: -lpthread should be last in your linking invocation
(has to do with mix of static and shared symbols)
So with CMake: ${CMAKE_THREAD_LIBS_INIT} should be last. For example:
target_link_libraries(mytestlib
${BINARY_DIR}/libgmock.a
glog
gflags
${Boost_LIBRARIES}
${CMAKE_THREAD_LIBS_INIT}
)
And for the OP: Search for "thread" in the CMakeLists.txt for the project your are building and paste those section (or link which project you are trying to build if it is open source) - if the above isn't self explanatory
If you are building with Make or something else, add -pthread to the compilation command line (so GCC would generate thread-safe static locals) and to the linking command line (so GCC would tell the linker to do the right thing, most notably link with -lpthread).
If you are building with CMake - then most probably you need these (full example):
# always
FIND_PACKAGE(Threads REQUIRED)
# if using boost
SET(Boost_USE_MULTITHREADED ON)
TARGET_LINK_LIBRARIES(my_app ... ${CMAKE_THREAD_LIBS_INIT})
I have installed boost along with other dependencies needed for Cassandra cpp driver on my ubuntu 12.04 LTS. When I try to run command below it ends up with two errors. I have looked for solutions but can't find any. Some say to link in the libboost_system by adding the option -lboost_system which I tried, but doesn't help.
Here is the cmd: cmake . && make && make cql_demo && make cql_test && make test && make install -lboost_system
All i want to do is to run the demo from the driver and to communicate with the cassandra database!
Errors:
-- info CMAKE_BINARY_DIR: /home/pi/experiments/cpp-driver-master2
-- Configuring done
-- Generating done
-- Build files have been written to: /home/pi/experiments/cpp-driver-master2
[ 42%] Built target cql
[ 85%] Built target cql_static
[ 87%] Built target CCMBridge
Linking CXX executable cql_integration_tests
/usr/bin/ld: warning: libboost_thread.so.1.55.0, needed by /usr/local/lib/libboost_log.so, may conflict with libboost_thread.so.1.46.1
/usr/bin/ld: CMakeFiles/cql_integration_tests.dir/src/test_utils.cpp.o: undefined reference to symbol 'boost::future_category()'
/usr/bin/ld: note: 'boost::future_category()' is defined in DSO /usr/local/lib/libboost_thread.so.1.55.0 so try adding it to the linker command line
/usr/local/lib/libboost_thread.so.1.55.0: could not read symbols: Invalid operation
collect2: ld returned 1 exit status
make[2]: *** [test/integration_tests/cql_integration_tests] Error 1
make[1]: *** [test/integration_tests/CMakeFiles/cql_integration_tests.dir/all] Error 2
make: *** [all] Error 2
The following error:
/usr/bin/ld: warning: libboost_thread.so.1.55.0, needed by /usr/local/lib/libboost_log.so, may conflict with libboost_thread.so.1.46.1
is basically saying that you have two versions of Boost installed:
Custom built one in /usr/local/lib/, probably version 1.55.0.
Another one in system directories, probably version 1.46.1.
and when they both get linked to your binary version 1.46.1 wins.
You need to see all complete command lines that CMake invokes for you to tell exactly where the problem is.
On ubuntu-13.04, I got an error when building an executable from shared libraries, using GCC-4.7.3 provided by the linux distribution.
I guess the problem is between libpng and zlib (the former uses the latter), but I don't know why.
First, my command is:
$ gfortran -o test_muesli_config_fml test_muesli_config_fml.o -fopenmp
-Wl,--rpath,/usr/local/lib/muesli /usr/local/lib/muesli/libfml.so -lstdc++
-Wl,--rpath,/usr/lib /usr/lib/liblapack.so -Wl,--rpath,/usr/lib /usr/lib/libblas.so
-lpng -lz -lpthread -lreadline -lhistory
which gives the following error:
/usr/local/lib/muesli/libfml.so: undefined reference to `gzwrite'
/usr/local/lib/muesli/libfml.so: undefined reference to `gzopen'
/usr/local/lib/muesli/libfml.so: undefined reference to `gzclose'
/usr/local/lib/muesli/libfml.so: undefined reference to `gzread'
collect2: error: ld returned 1 exit status
But note that -lz is present. After that, I added the linker option --trace-symbol= in order to get more information:
$ gfortran -o test_muesli_config_fml test_muesli_config_fml.o -fopenmp
-Wl,--rpath,/usr/local/lib/muesli /usr/local/lib/muesli/libfml.so -lstdc++
-Wl,--rpath,/usr/lib /usr/lib/liblapack.so -Wl,--rpath,/usr/lib /usr/lib/libblas.so
-lpng -lz -lpthread -lreadline -lhistory -Wl,--trace-symbol=gzwrite
which in turn gives the results:
/usr/local/lib/muesli/libfml.so: reference to gzwrite
/usr/lib/gcc/x86_64-linux-gnu/4.7/../../../x86_64-linux-gnu/libz.so: definition of gzwrite
/usr/local/lib/muesli/libfml.so: undefined reference to `gzwrite'
/usr/local/lib/muesli/libfml.so: undefined reference to `gzopen'
/usr/local/lib/muesli/libfml.so: undefined reference to `gzclose'
/usr/local/lib/muesli/libfml.so: undefined reference to `gzread'
collect2: error: ld returned 1 exit status
so, gzwrite is found in libz.so but the linker don't use it!
By chance, I thought to remove the -lpng option (actually, the libpng library is not used) and my problem is solved! Why?
Secondly, I compile my whole code with another version of GCC-4.7.3 (compiled by myself -- I am used to test many versions of the compiler), and the error didn't occur, even using both -lpng and -lz!
Any idea?
In addition, a different try with another program (which USE libpng) leads to a successful build.
Edited on 2013-10-08
I'm pretty sure now that it is a bug in ubuntu-13.04: I've tried two other linux distros (Fedora 16 -- Ubuntu-10.04) and the linker behavior is standard, not as described above in the first part of my message.
I plan to report this problem on ubuntu community. Regards.
Edited on 2013-10-09
The bug has been reported to https://bugs.launchpad.net/ubuntu/+source/gcc-defaults/+bug/1237270
Two possible fixes (until ubuntu doesn't repair itself):
Try to compile in libpng.a and libz.a as a static library (it can be only a temporary solution, because static libs are evil in most cases).
Recompile libpng from the original source, and compile libz.a as static herein.