- How to fix «skipping incompatible /usr/lib/libc.a»
- skipping incompatible /libSDL.a when searching for -lSDL
- ld error «/opt/bin/ld: skipping incompatible /lib/libm.so.6 when searching for /lib/libm.so.6» when using g++
- /usr/bin/ld: skipping incompatible foo.so when searching for foo
- Skipping Incompatible Libraries at compile
- 2 Answers 2
How to fix «skipping incompatible /usr/lib/libc.a»
I get the following error when I try to build an embedded Linux target on a 64 bit Fedora 16 (Verne):
make[3]: Entering directory `/export/home/git/minerva-5.x/third_party/multifiles' mips-linux-gnu-gcc -EL -O -D_GNU_SOURCE -Wall -isystem /export/home/git/minerva-5.x/cs_rootfs_1.2.15/cross_rootfs/include -c -o md5.o md5.c mips-linux-gnu-gcc -EL -O -D_GNU_SOURCE -Wall -isystem /export/home/git/minerva-5.x/cs_rootfs_1.2.15/cross_rootfs/include -c -o bitmapfs.o bitmapfs.c mips-linux-gnu-gcc -EL -O -D_GNU_SOURCE -Wall -isystem /export/home/git/minerva-5.x/cs_rootfs_1.2.15/cross_rootfs/include -c -o mfcln.o mfcln.c mips-linux-gnu-gcc -EL -Wl,-rpath /export/home/git/minerva-5.x/cs_rootfs_1.2.15/cross_rootfs/lib -L/export/home/git/minerva-5.x/cs_rootfs_1.2.15/cross_rootfs/lib -o mfcln md5.o bitmapfs.o mfcln.o mulfiles.h mulfiles_msg.h md5.h bitmapfs.h gcc -O -Wall -m32 -c -o md5_x86_32.o md5.c gcc -O -Wall -m32 -c -o mfsrv_x86_32.o mfsrv.c gcc -O -m32 -o mfsrv32 md5_x86_32.o mfsrv_x86_32.o gcc -O -m32 -static -o mfsrv32-static md5_x86_32.o mfsrv_x86_32.o gcc -O -Wall -c -o md5_x86_64.o md5.c gcc -O -Wall -c -o mfsrv_x86_64.o mfsrv.c gcc -O -o mfsrv64 md5_x86_64.o mfsrv_x86_64.o gcc -O -static -o mfsrv64-static md5_x86_64.o mfsrv_x86_64.o /usr/bin/ld: skipping incompatible /usr/lib/gcc/x86_64-redhat-linux/4.6.3/../../../libc.a when searching for -lc /usr/bin/ld: skipping incompatible /usr/lib/libc.a when searching for -lc /usr/bin/ld: cannot find -lc collect2: ld returned 1 exit status make[3]: *** [mfsrv64-static] Error 1 I need to use an older version of make (make381) probably since the kernel is old and customized (2.6.22.19-39-sigma) and the target is MIPS. I have also installed ncurses-static, glibc-static.i686, and glibc-devel.i686 on my system. Do I need a compatible libc.a for make381? If so, Where can I find it? If not, where do I look next to fix this build? The full console output is here.
skipping incompatible /libSDL.a when searching for -lSDL
I am trying to «make» ioquake3 on IBM machine. But, I kept getting the «skipping incompatible /libSDL.a when searching for -lSDL» error. I am thee ultimate beginner at Linux, but not a quitter! I have no privileges to install any libraries, and our server admin is not responding for about a week now. So, I’ve been googling/testing for for a solution now. As the message said, the library that is on the system is incompatible. So, I went to the Ubuntu site, and downloaded SDL PPC library freshly. I uploaded, unpacked it into a designated folder. However, GCC doesn’t know where those libraries are. So, I found something called «LD_LIBRARY_PATH=»~/minoru/cfe2/yasirTemp/ioquake3dev/zzz/pkgs/usr/lib» to tell GCC where my libraries are. However, everytime I do a «make», I do not my «export» folder in the list. Please help, even with a different way, just to fix my incompatible SDL library problem. below is the output:
ld error «/opt/bin/ld: skipping incompatible /lib/libm.so.6 when searching for /lib/libm.so.6» when using g++
#ifdef __cplusplus extern "C" #endif int main ()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.1gcc -o conftest -I/opt/include -L/opt/lib -Wl,--library-path=opt/lib testconftest.cppNote 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 warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE./usr/bin/ld: skipping incompatible foo.so when searching for foo
I am using Ubuntu 13.10 64bit and I am getting the following errors while compiling the python wrappers of vlfeat library.
g++ -o _vlfeat.so ../../vl/aib.o ../../vl/generic.o ../../vl/hikmeans.o ../../vl/ikmeans.o ../../vl/imopv.o ../../vl/mathop.o ../../vl/pgm.o ../../vl/rodrigues.o ../../vl/stringop.o ../../vl/getopt_long.o ../../vl/host.o ../../vl/imop.o ../../vl/imopv_sse2.o ../../vl/mser.o ../../vl/random.o ../../vl/sift.o ../../vl/dsift.o mser/vl_erfill.o mser/vl_mser.o sift/vl_sift.o sift/vl_dsift.o sift/vl_siftdescriptor.o imop/vl_imsmooth.o misc/vl_binsum.o kmeans/vl_hikmeans.o kmeans/vl_ikmeans.o kmeans/vl_hikmeanspush.o kmeans/vl_ikmeanspush.o py_vlfeat.o -m64 -msse -m32 -msse -shared -lboost_python-mt-py27 /usr/bin/ld: skipping incompatible /usr/lib/gcc/x86_64-linux-gnu/4.7/../../../libboost_python-mt-py27.so when searching for -lboost_python-mt-py27 /usr/bin/ld: skipping incompatible /usr/lib/gcc/x86_64-linux-gnu/4.7/../../../libboost_python-mt-py27.a when searching for -lboost_python-mt-py27 /usr/bin/ld: skipping incompatible /usr/lib/libboost_python-mt-py27.so when searching for -lboost_python-mt-py27 /usr/bin/ld: skipping incompatible /usr/lib/libboost_python-mt-py27.a when searching for -lboost_python-mt-py27 /usr/bin/ld: cannot find -lboost_python-mt-py27 /usr/bin/ld: skipping incompatible /usr/lib/gcc/x86_64-linux-gnu/4.7/libstdc++.so when searching for -lstdc++ /usr/bin/ld: skipping incompatible /usr/lib/gcc/x86_64-linux-gnu/4.7/libstdc++.a when searching for -lstdc++ /usr/bin/ld: cannot find -lstdc++ /usr/bin/ld: skipping incompatible /usr/lib/x86_64-linux-gnu/libm.so when searching for -lm /usr/bin/ld: skipping incompatible /usr/lib/x86_64-linux-gnu/libm.a when searching for -lm /usr/bin/ld: cannot find -lm /usr/bin/ld: skipping incompatible /usr/lib/gcc/x86_64-linux-gnu/4.7/libgcc_s.so when searching for -lgcc_s /usr/bin/ld: cannot find -lgcc_s /usr/bin/ld: skipping incompatible /usr/lib/x86_64-linux-gnu/libc.so when searching for -lc /usr/bin/ld: skipping incompatible /usr/lib/x86_64-linux-gnu/libc.a when searching for -lc /usr/bin/ld: cannot find -lc /usr/bin/ld: skipping incompatible /usr/lib/gcc/x86_64-linux-gnu/4.7/libgcc_s.so when searching for -lgcc_s /usr/bin/ld: cannot find -lgcc_s collect2: error: ld returned 1 exit status make: *** [_vlfeat.so] Error 1Skipping Incompatible Libraries at compile
When I try to compile a copy of my project on my local machine, I get an error stating that it ‘s skipping over incompatible libraries. This isn’t the case when I’m messing around with the live version hosted on the server at work [it makes perfectly there]. Various other sites have lead me to believe that this might be an environment issue, as I’m developing on a 64-bit distro of Ubuntu and I assume the server version is running on 32-bit. Nevertheless, after setting my environment variables to:
/usr/bin/ld: skipping incompatible /dvlpmnt/libPI-Http.a when searching for -lPI-HttpCan haz tutorial? ==Edit== This was the output I recieved when I followed Jonathan’s advice:
http.o: ELF 32-bit LSB relocatable, Intel 80386, version 1 (SYSV), not stripped@Rup: that’s likely to say ‘current ar archive’, which is not dreadfully helpful. You have to get at a file inside the archive, as shown in my answer.
2 Answers 2
That message isn’t actually an error — it’s just a warning that the file in question isn’t of the right architecture (e.g. 32-bit vs 64-bit, wrong CPU architecture). The linker will keep looking for a library of the right type.
Of course, if you’re also getting an error along the lines of can’t find lPI-Http then you have a problem 🙂
It’s hard to suggest what the exact remedy will be without knowing the details of your build system and makefiles, but here are a couple of shots in the dark:
- Just to check: usually you would add flags to CFLAGS rather than CTAGS — are you sure this is correct? (What you have may be correct — this will depend on your build system!)
- Often the flag needs to be passed to the linker too — so you may also need to modify LDFLAGS
If that doesn’t help — can you post the full error output, plus the actual command (e.g. gcc foo.c -m32 -Dxxx etc) that was being executed?
In addition to this solution, you can add -Wl,—no-warn-search-mismatch to your CFLAGS , thus these warnings get suppressed.
Normally, that is not an error per se; it is a warning that the first file it found that matches the -lPI-Http argument to the compiler/linker is not valid. The error occurs when no other library can be found with the right content.
So, you need to look to see whether /dvlpmnt/libPI-Http.a is a library of 32-bit object files or of 64-bit object files — it will likely be 64-bit if you are compiling with the -m32 option. Then you need to establish whether there is an alternative libPI-Http.a or libPI-Http.so file somewhere else that is 32-bit. If so, ensure that the directory that contains it is listed in a -L/some/where argument to the linker. If not, then you will need to obtain or build a 32-bit version of the library from somewhere.
To establish what is in that library, you may need to do:
mkdir junk cd junk ar x /dvlpmnt/libPI-Http.a file *.o cd .. rm -fr junkThe ‘ file ‘ step tells you what type of object files are in the archive. The rest just makes sure you don’t make a mess that can’t be easily cleaned up.