Very strange linker behavior

Question

This is strange because I was able to get the error below to go away by removing the reference to libm.

gcc -o example example.o -Wl -L/home/kensey/cdev/lib          


        

Answer 1

Hard to tell. Because there are custom library directories in the command line it's conceivable that -lm links an incompatible alternative version. Without -lm the linker could pull in another version of it because it's needed by one of the libraries you link.

To make sure strace both invocations and see where libm.so is coming from in both cases.

BTW, -Wl switch seems to do nothing and -L/usr/lib/x86_64-linux-gnu is mentioned twice.

Answer 2

I've solved the same problem with export LDFLAGS="$LDFLAGS -lm"

Answer 3

Use this:

administrator@administrator-Veriton-M200-H81:~/ishan$ gcc polyscanline1.cpp -lglut -lGLU -lGL -lm

Answer 4

One explanation could be:

It's possibly there is a weakly linked function foo defined outside of libm that is replaced by a strongly linked version of foo defined inside libm, and it is this strongly linked version that calls the undefined function.

This would explain how adding a library can cause an undefined function error.

Answer 5

I just ran into a similar problem; I remember that the order of the libraries did not matter (at least not in the cases I worked with) in the past for gcc. In this question here somebody noticed that the behaviour seems to have changed between 4.4 and 4.5 .

In my case, I got rid of the error message by doing the linking at:

 g++ -Wl,--copy-dt-needed-entries [options] [libraries] [object files] -o executable-file

Answer 6

Perhaps, your library search paths (/usr/local/lib/ or /usr/lib/, ...) do not contain 64bit libm so gcc cannot locate it if you specify with l flag. If you only specify only the directory it looks like it can find the right one. So you can try:

LD_LIBRARY_PATH=/usr/lib/x86_64-linux-gnu

and use -lm