From Bugzilla Helper: User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; fr-FR; rv:1.7.12) Gecko/20050919 Firefox/1.0.7 Description of problem: When compiling OpenIPMI-1.4.14-1.4E.7 on x86_64 architecture, compilation fails with this message: gcc: /usr/lib/libnetsnmp.so: No such file or directory It is looking for libnetsnmp.so in /usr/lib instead of /usr/lib64. Version-Release number of selected component (if applicable): OpenIPMI-1.4.14-1.4E.7 How reproducible: Always Steps to Reproduce: 1. rpm -Uvh http://updates.redhat.com/enterprise/4AS/en/os/SRPMS/OpenIPMI-1.4.14-1.4E.7.src.rpm 2. cd /usr/src/redhat/SPECS 3. rpmbuild -ba OpenIPMI.spec Actual Results: Compilation fails with message: [...] gcc -Wall -I../include -DIPMI_CHECK_LOCKS -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -O2 -g -pipe -m64 -o .libs/ipmish ipmish.o ./.libs/libOpenIPMIcmdlang.so /usr/src/redhat/BUILD/OpenIPMI-1.4.14/lib/.libs/libOpenIPMI.so ../utils/.libs/libOpenIPMIutils.so ../lib/.libs/libOpenIPMI.so -lm ../unix/.libs/libOpenIPMIposix.so /usr/src/redhat/BUILD/OpenIPMI-1.4.14/utils/.libs/libOpenIPMIutils.so /usr/lib/libnetsnmp.so -lcrypto ../glib/.libs/libOpenIPMIglib.so -lgdbm -pthread -lgthread-2.0 -lglib-2.0 -Wl,--rpath -Wl,/usr/lib64 gcc: /usr/lib/libnetsnmp.so: No such file or directory make[1]: *** [ipmish] Error 1 make[1]: Leaving directory `/usr/src/redhat/BUILD/OpenIPMI-1.4.14/cmdlang' make: *** [all-recursive] Error 1 Expected Results: Compilation should have completed without error. Additional info:
That is a problem with libtool picking up the 32bit development library if the net-snmp-devel i386 package has been installed. To resolve this problem remove the net-snmp-devel.i386 package using: rpm -e net-snmp-devel.i386 on a command line. Read ya, Phil
I'm quite sure this would work. However, my concern is why do I have to do this? Is there a way to fix libtool instead? Thanks, -- Patrice
The problem is that libtool never was really properly designed to be used for development on multilib platforms. So fixing it would probably require quite a bit of work how libtool selects and finds libraries for those cases. Additionally, most packages come with their own copy of libtool in order to have a know working one with that specific package, so fixing libtool itself might work for some packages that use the system libtool but not for quite a few others. Read ya, Phil
Thanks for the information. Maybe this will help someone running into the same problem.