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.
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.
For example, consider that I wrote a Fortran program in one computer and want to run it on another computer which may not have required libraries and/or has a different compiler (or even better, no Fortran compiler at all). Is it possible to create an executable with all its dependencies?
I am using gfortran (7.2.1) in Fedora 26 and sometimes use LAPACK routines in my code.
Using -static option with the program
program main
write (*,*) 'Hello'
end
I get the output
gfortran -static a.f90
/usr/bin/ld: cannot find -lm
/usr/bin/ld: cannot find -lm
/usr/bin/ld: cannot find -lc
collect2: error: ld returned 1 exit status
There is no error with gfortran -static-libgfortran a.f90
In Fedora, gcc does not ship by default with static libraries.
You need to install the package glibc-static for the -static option to work, as hinted in this related question.
Note that -static-libgfortran will only do static linking of the libgfortran library and that you must have static versions of your dependencies as well.
The best option is to use Alpine Linux that uses musl libc. I highly recommend using the docker image (only 5 Mb).
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 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
I wrote a basic hello world program in haskel and tried to compile it with:
ghc filename.hs. It produces .hi and .o files but no executable and displays
this error in the linker:
marox#IT-marox:~/Marox$ ghc tupel.hs
Linking tupel ...
/usr/bin/ld: --hash-size=31: unknown option
/usr/bin/ld: use the --help option for usage information
collect2: ld returned 1 exit status
Googling didn't return any useful information.
I am on ubuntu 12.04.
How can I fix this?
Have you binutils-gold installed? If yes, this is the problem (since the gold linker does not support --hash-size AFAIK).
Possible solutions:
remove gold
your ld probably links to ld.gold, so change the symlink to ld.ld
tell the haskell compiler explicitly which linker to use with the -pgml option: ghc -pgml ld.ld tupel.hs
install ghc from source, since the configure script of ghc will then build ghc so that it won't use --hash-size
Depending on your version of ghc, you can adjust the linker settings in ghc's setting file /usr/lib/ghc-your.ghc.version/settings
Update - gold on Ubuntu 12.10 appears to move GNU ld to ld.bfd. To fix this problem I deleted the ld link as recommended and remade the link with
ln -s ld.bfd ld
ghc compilations are now going through.
(Couldn't see how to subvert the settings file in usr/lib/ghc, as the entry is for gcc which passes through its commandline to ld, although this would have been my preferred option, in case something else needs ld to be the way it was.)
Thanks to Dominic for the pointer of where to look! It was driving me crazy...