[Pdfedit-support] configure choose the wrong lib directory on x86_64 multilib

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 454-5900

With thanks to you kind souls around here, I successfully built PDFedit 0.4.5 on CentOS 5 / i386.  It was quite smooth compared to some other packages I have built, so kudos on that.

I am now turning to building an x86_64 version (still on Cent5), and I have run into trouble with the configure script choosing the wrong directory for some of the needed libraries.  I have a workaround, so this is more a bug report than support request, but I am unable to access your bug tracker via the web site to report it that way.

RedHat-family x86_64 systems use the multilib approach, so /lib and /usr/lib contain 32-bit libraries (for the most part), whereas the 64-bit libraries are in /lib64 and /usr/lib64.  When building software on such a system, one generally wants to link against the libraries in /lib64 and /usr/lib64 in preference to anything in /lib or /usr/lib, and the linker generally does the right thing by default.  I have rarely, if ever, had any trouble related to this -- until now.

64-bit versions of all the libraries needed for PDFedit are installed on my build system, in /usr/lib64 as is standard for this distro.  I initially also had 32-bit boost and zlib installed, and in that configuration the PDFedit build proceeded fine all the way to the final link of the pdfedit binary, then failed on not finding compatible versions of some of the needed 3rd-party libraries:

g++  -o pdfedit  [... many object files ...]   -L/usr/lib64/qt-3.3/lib -lqsa_pdfedit -L/home/jbolling/rpm/BUILD/pdfedit-0.4.5/src/qsa/lib/ -lqoutputdevices -L/home/jbolling/rpm/BUILD/pdfedit-0.4.5/src/kpdf-kde-3.3.2/ -L/usr/lib -lkernel -L/home/jbolling/rpm/BUILD/pdfedit-0.4.5/src/kernel -lutils -L/home/jbolling/rpm/BUILD/pdfedit-0.4.5/src/utils -lxpdf -L/home/jbolling/rpm/BUILD/pdfedit-0.4.5/src/xpdf/xpdf -lfofi -L/home/jbolling/rpm/BUILD/pdfedit-0.4.5/src/xpdf/fofi -lGoo -L/home/jbolling/rpm/BUILD/pdfedit-0.4.5/src/xpdf/goo -lsplash -L/home/jbolling/rpm/BUILD/pdfedit-0.4.5/src/xpdf/splash  -lfreetype -lt1 -L/usr/lib -lz -lqt-mt -lXext -lX11 -lm
/usr/bin/ld: skipping incompatible /usr/lib/libt1.so when searching for -lt1
/usr/bin/ld: skipping incompatible /usr/lib/libt1.so when searching for -lt1
/usr/bin/ld: skipping incompatible /usr/lib/libz.so when searching for -lz
/usr/bin/ld: skipping incompatible /usr/lib/libz.a when searching for -lz
/usr/bin/ld: skipping incompatible /usr/lib/libz.so when searching for -lz
/usr/bin/ld: skipping incompatible /usr/lib/libz.a when searching for -lz
/usr/bin/ld: skipping incompatible /usr/lib/libXext.so when searching for -lXext
/usr/bin/ld: skipping incompatible /usr/lib/libXext.so when searching for -lXext

I reiterate that the needed 64-bit development libs are present on the system, but I suppose the specified link options cause the linker to overlook them.  Perhaps that is related to the two spurious appearances of the "-L/usr/lib" option.  For what it's worth, those appear to come from configure's choices for 'BOOST_LDFLAGS' and 'ZLIB_LIBS' options, which configure is getting wrong.

I attempted to fix the problem by exporting LDFLAGS=-L/usr/lib64 to configure, but that had no effect whatever on the link command that was ultimately issued.  I also tried removing the 32-bit boost libraries, but in that case configure fails with:

checking for boost-program-options library... checking whether the Boost::Program_Options library is available... yes
configure: error: Could not link against  !

The log appears to shows configure assuming that the boost (and zlib) libs will be in /usr/lib, whereas it should be looking instead to /usr/lib64.  Ultimately, I was able to work around the problem via configure's --with-boost-libdir option.  Configure still chooses the wrong link options for zlib, but having it right for boost allows the linker to find the right zlib (and other) libraries as well, since -L options are global to the whole link.

Overall, none of that hassle should be necessary for a system, such as mine, having the needed libraries in standard LSB-specified locations.

Thanks,

John Bollinger

Email Disclaimer:  www.stjude.org/emaildisclaimer