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?
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 using Mint 15, I'm a total noob when it comes to compiling softwares, but I'm trying to compile the "infinite-qt" GUI from the Git repo.
I managed to get "infinitecoind"(daemon) compiled, using the 'Makefile.unix' file.
What I'm trying to do now is to get the "infinitecoin-qt GUI" working.
I think it kinda compiles alright to the point where I get this error message:
build/qrc_bitcoin.o -L/usr/lib/i386-linux-gnu -lrt -lssl -lcrypto -ldb_cxx -loleaut32 -lboost_system -lboost_filesystem -lboost_program_options -lboost_thread -lQtGui - lQtCore -lpthread
/usr/bin/ld: cannot find -loleaut32
collect2: error: ld returned 1 exit status
make: ** [infinitecoin-qt] Error 1
Seems like it's some kind of lib missing somehow related to Windows, but I can't find it.
Thanks in advance for your help!
oleaut32 is a library used by Microsoft for OLE technologies - you won't be able to link against it on Linux...
see: http://msdn.microsoft.com/en-us/library/aa268922(v=vs.60).aspx
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.
I am running client.c code in linux pangolin 12.04, happycoders-libsocket is installed
but still got error that says:
/usr/bin/ld: cannot find -lsocket
collect2: ld returned 1 exit status
May I know what can be done to resolve this please?
If you have C code that uses BSD sockets on Linux then you do not need to link against additional libraries; GLibC provides the socket functions through libc.
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.