I run into this error when I try to test compiling a very simple program:

#ifdef __cplusplus
extern "C"
main ()
return 0;

And I got the following error message if I compile using g++:

g++ -o conftest -I/opt/include -L/opt/lib -Wl,--library-path=opt/lib testconftest.cpp

/opt/bin/ld: skipping incompatible /lib/libm.so.6 when searching for /lib/libm.so.6
/opt/bin/ld: cannot find /lib/libm.so.6
/opt/bin/ld: cannot find /lib/libmvec.so.1

But the compile will pass by gcc:

gcc -o conftest -I/opt/include -L/opt/lib -Wl,--library-path=opt/lib testconftest.cpp

Note the system is a hybrid of 32bit and 64bit, all 32bit programs and libararies are in /lib, /bin ,/sbin etc. All 64bits programs and libararies are in /opt/lib, /opt/bin, opt/sbin, etc. I know the /lib/libm.so.6 will be the wrong version and the corrected version is in /opt/lib. Also, gcc, g++, ld are all 64bits and in the /opt subfolders, and have successfully compiled other much complicated programs using gcc. File /lib/libm.so.6 is symlink to /lib/libm-2.6.1.so; File /opt/lib/lim.so.6 is symlink to /opt/lib/libm-2.22.so*

file /opt/lib/libm-2.22.so
/opt/lib/libm-2.22.so: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, for GNU/Linux 2.6.32, stripped

file /lib/libm-2.6.1.so
/lib/libm-2.6.1.so: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux.so.2, for GNU/Linux 2.6.8, stripped

g++ --version
g++ (OpenWrt GCC 4.8.5) 4.8.5
Copyright (C) 2015 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
  • /lib/libm.so.6 is a symlink to what, exactly? – schaiba Feb 16 '16 at 9:58
  • @schaiba, added symlink to info in the main body. – NathaneilCapital Feb 16 '16 at 10:10
  • your "g++" example calls gcc while your "gcc" example calls g++; can you clarify? – Jeff Schaller Feb 16 '16 at 13:44
  • @JeffSchaller My bad. Copied to wrong location. Just corrected them. – NathaneilCapital Feb 16 '16 at 13:47
  • Isn't there a slash missing in your --library-path? Shouldn't it be /opt/lib rather than opt/lib? – RealSkeptic Mar 9 '16 at 15:44

As I cannot reproduce the problem you're having, I can only give you a few pointers.

Have a look at this answer, as using g++ automatically adds some extra libs during the linker phase. You can use the -v option when compiling/linking to get a clearer view of what libs are being included.

-v Print (on standard error output) the commands executed to run the stages of compilation. Also print the version number of the compiler driver program and of the preprocessor and the compiler proper.

As g++ auto adds libstdc++ to the linker phase, have a look at where it is declared in your path.

$  ldconfig -p | grep stdc++
    libstdc++.so.6 (libc6,x86-64) => /usr/lib64/libstdc++.so.6
    libstdc++.so.6 (libc6) => /usr/lib/libstdc++.so.6
  • 1
    Thank you so much for pointing the right direction! I finally get to the problem. It is still very wired to me. It is actually because of a "bug" in the libm.so. The libm.so is required by g++ with the linker option "-lm". This version of libm.so itself is a linker script to link libm.so.6 and libmvec.so.1 . And the linker script have an absolute path for libm.so.6 and libmvec.so.1. So no matter how many times I tell the linker, compiler to look elsewhere, the g++ and ld won't listen!! I will try to compile some detailed solution and searches I have done to pin down the problem. – NathaneilCapital Mar 12 '16 at 17:45

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.