Hi Centos Users
I try to compile SNMPPD (SNMP Proxy Daemon) on Centos 5.1 x86_64 with latest patches. Dependencies (like libsplit, net-snmp-libs, net-snmp-devel, net-snmp-libs) are installed, both 32 and 64 Bit.
# rpmbuild -tb snmppd-0.5.2.tar.gz [...] Making all in snmppd make[2]: Entering directory `/tmp/snmppd-0.5.2/snmppd' gcc -Wall -Wno-uninitialized -Wchar-subscripts -Wmissing-declarations -Wmissing-prototypes -Wnested-externs -Wpointer-arith -Wno-sign-compare -Werror -L/usr/lib -o snmppd conf.o control.o log.o queue.o snmp.o snmppd.o threads.o utils.o -lnetsnmp -lcrypto -lpthread /usr/bin/ld: skipping incompatible /usr/lib/libnetsnmp.so when searching for -lnetsnmp /usr/bin/ld: skipping incompatible /usr/lib/libnetsnmp.a when searching for -lnetsnmp snmppd.o: In function `new_target': snmppd.c:(.text+0x371): undefined reference to `split' snmppd.c:(.text+0x3fb): undefined reference to `split_free' snmppd.c:(.text+0x619): undefined reference to `split_free' collect2: ld returned 1 exit status make[2]: *** [snmppd] Error 1 make[2]: Leaving directory `/tmp/snmppd-0.5.2/snmppd' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/tmp/snmppd-0.5.2' make: *** [all] Error 2 [...]
Can anyone explain me "/usr/bin/ld: skipping incompatible" in plain english ;) How to solve it?
cheers Simon
On Thu, Mar 06, 2008 at 03:48:04PM +0100, Simon Jolle alleged:
Hi Centos Users
I try to compile SNMPPD (SNMP Proxy Daemon) on Centos 5.1 x86_64 with latest patches. Dependencies (like libsplit, net-snmp-libs, net-snmp-devel, net-snmp-libs) are installed, both 32 and 64 Bit.
# rpmbuild -tb snmppd-0.5.2.tar.gz [...] Making all in snmppd make[2]: Entering directory `/tmp/snmppd-0.5.2/snmppd' gcc -Wall -Wno-uninitialized -Wchar-subscripts -Wmissing-declarations -Wmissing-prototypes -Wnested-externs -Wpointer-arith -Wno-sign-compare -Werror -L/usr/lib -o snmppd conf.o control.o log.o queue.o snmp.o snmppd.o threads.o utils.o -lnetsnmp -lcrypto -lpthread /usr/bin/ld: skipping incompatible /usr/lib/libnetsnmp.so when searching for -lnetsnmp /usr/bin/ld: skipping incompatible /usr/lib/libnetsnmp.a when searching for -lnetsnmp snmppd.o: In function `new_target': snmppd.c:(.text+0x371): undefined reference to `split' snmppd.c:(.text+0x3fb): undefined reference to `split_free' snmppd.c:(.text+0x619): undefined reference to `split_free' collect2: ld returned 1 exit status make[2]: *** [snmppd] Error 1 make[2]: Leaving directory `/tmp/snmppd-0.5.2/snmppd' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/tmp/snmppd-0.5.2' make: *** [all] Error 2 [...]
Can anyone explain me "/usr/bin/ld: skipping incompatible" in plain english ;) How to solve it?
"skipping incompatible" means that ld is skipping over libraries/archives that are the wrong architecture. In this case, ld is skipping 32bit archives while trying to link a 64bit binary. This is all well and good.
You can normally ignore these messages because ld is pretty good and eventually finding the correct libs.
Your problem is the "undefined reference" errors, not the "skipping" warnings. It looks like ld needs a -lsplit or something. I don't see a libsplit in my repo so I can't comment specifically. Make sure you have a x86_64 libsplit-devel (or whatever it is called) installed and watch the output of snmppd's configure carefully.
on 3-6-2008 6:48 AM Simon Jolle spake the following:
Hi Centos Users
I try to compile SNMPPD (SNMP Proxy Daemon) on Centos 5.1 x86_64 with latest patches. Dependencies (like libsplit, net-snmp-libs, net-snmp-devel, net-snmp-libs) are installed, both 32 and 64 Bit.
Try and remove the 32 bit libs if you are not running 32 bit apps.
# rpmbuild -tb snmppd-0.5.2.tar.gz [...] Making all in snmppd make[2]: Entering directory `/tmp/snmppd-0.5.2/snmppd' gcc -Wall -Wno-uninitialized -Wchar-subscripts -Wmissing-declarations -Wmissing-prototypes -Wnested-externs -Wpointer-arith -Wno-sign-compare -Werror -L/usr/lib -o snmppd conf.o control.o log.o queue.o snmp.o snmppd.o threads.o utils.o -lnetsnmp -lcrypto -lpthread /usr/bin/ld: skipping incompatible /usr/lib/libnetsnmp.so when
You are building 64 bit, but it is finding the 32 bit libs and bombing.
searching for -lnetsnmp /usr/bin/ld: skipping incompatible /usr/lib/libnetsnmp.a when
Same here. 64 bit libs are in /usr/lib64 .
searching for -lnetsnmp snmppd.o: In function `new_target': snmppd.c:(.text+0x371): undefined reference to `split' snmppd.c:(.text+0x3fb): undefined reference to `split_free' snmppd.c:(.text+0x619): undefined reference to `split_free' collect2: ld returned 1 exit status make[2]: *** [snmppd] Error 1 make[2]: Leaving directory `/tmp/snmppd-0.5.2/snmppd' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/tmp/snmppd-0.5.2' make: *** [all] Error 2 [...]
Can anyone explain me "/usr/bin/ld: skipping incompatible" in plain english ;) How to solve it?
It is very difficult to build 64 bit software when 32 bit libs are present because the 32 bit lib path gets searched first.
Scott Silva wrote: <snip>
Can anyone explain me "/usr/bin/ld: skipping incompatible" in plain english ;) How to solve it?
It is very difficult to build 64 bit software when 32 bit libs are present because the 32 bit lib path gets searched first.
this is not true by default on centos5. I just tested with both i386 and x86_64 expat and expat-devel packages installed, and compiled a program that includes expat: $ ldd ipoolValidation libm.so.6 => /lib64/libm.so.6 (0x0000003d4d600000) libexpat.so.0 => /lib64/libexpat.so.0 (0x0000003d4fa00000) libc.so.6 => /lib64/libc.so.6 (0x0000003d4d200000) /lib64/ld-linux-x86-64.so.2 (0x0000003d4c200000)
The problem is with the snmppd Makefile:
Making all in snmppd make[2]: Entering directory `/tmp/snmppd-0.5.2/snmppd' gcc -Wall -Wno-uninitialized -Wchar-subscripts -Wmissing-declarations -Wmissing-prototypes -Wnested-externs -Wpointer-arith -Wno-sign-compare -Werror -L/usr/lib -o snmppd conf.o control.o log.o queue.o snmp.o snmppd.o threads.o utils.o -lnetsnmp -lcrypto -lpthread
that -L/usr/lib is causing the problem and breaking the build on x86_64. Is there a really good reason it's there? This should be picked up with the upstream devs.