Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=731898 Todd Lyons <tlyons@xxxxxxxxxx> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |tlyons@xxxxxxxxxx --- Comment #22 from Todd Lyons <tlyons@xxxxxxxxxx> 2011-08-23 11:21:51 EDT --- Matt, the OpenDKIM package builds its own libtool (./libtool built from m4/libtool.m4) and uses it by default. This package-provided libtool attempts to auto-detect system library paths and ends up deciding it's /lib and /usr/lib. Thus anything that links to /lib64 and /usr/lib64 (which opendkim does) will end up using rpath to add to the dynamic loader search path. In testing we found that this was only an issue on x86_64. That was the reason for the %ifarch logic around the %define LIBTOOL macro (because it works properly on i386 arch). Since we added "BuildRequires: libtool" to the spec file and know that libtool will always be present for the build for all arches, the %ifarch then could be dropped and a simple: %define LIBTOOL="LIBTOOL=`which libtool`" will take care of finding /usr/bin/libtool, which has the rpaths hard coded to /lib64 and /usr/lib64 on x86_64. Then pass that to the Makefile by appending %LIBTOOL to %make and make install commands. If you do not pass that LIBTOOL override, it will use the ./libtool and screw up the rpaths. Without doing it this way, you get the rpath errors as above. Regards... Todd Lyons -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. _______________________________________________ package-review mailing list package-review@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/package-review