Very strange linker behavior

The explanation to what's happening is very simple:

1. Your libgplot.a depends on libm.so, yet the order of -lm and -lgplot on the link line is wrong. The order of libraries on the link line does matter. In general, system libraries (-lpthread, -lm, -lrt, -ldl) should follow everything else on the link line.

2. When you remove -lm from the link line, libm.so.6 is still pulled into the link by some other library that appears later on the link line (libgd, libxml2 or libcurl) because that library depends on libm.so.6. But now libm.so.6 is in correct place on the link line, and so everything works.

if I put -lm at the end of the link command, listing it as the last library, I do not get the error.

That confirms above explanation.

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

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

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.

Just to add to the list of answers, http://fedoraproject.org/wiki/UnderstandingDSOLinkChange It is informative. It isn't relevant to the question asked above, but, the explanation relates to the error message /usr/bin/ld: note: 'some_reference' is defined in DSO some.so so try adding it to the linker command line