On Thu, Sep 22, 2011 at 11:17:56AM -0500, Bollinger, John C wrote: > 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.
What kind of problems you have with our bug tracker? I can access http://pdfedit.petricek.net/bt/main_page.php just fine. > 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 OK, this seems that libt and xlib where taken from the bad path. > > 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. Most libraries have their parameters to specify compilation and link parameters. E.g. boost should be specified as --with-boost-libdir=PATH LibT1: --with-t1-library=PATH ./configure --help should show you all available parameters. zlib detection is really stupid and hardcoded. You can specify a root directory for zlib build by --with-zlib=PATH but there is no way to tell it that it should look into /lib64 rather than /lib. I thought I had some patch around to fix that but I cannot find it. Anyway you can workaround that by editing Makefile.flags which is generated by configure and it contains all the flags. So you can change all linking paths from lib to lib64. Sorry for the ugliness but I really hate to look into autoconf macros again ;) If you want to fix them it would be really welcome but "friends do not let friends edit autoconf macros" so I cannot ask you to do it. > > 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 > > > ------------------------------------------------------------------------------ > All the data continuously generated in your IT infrastructure contains a > definitive record of customers, application performance, security > threats, fraudulent activity and more. Splunk takes this data and makes > sense of it. Business sense. IT sense. Common sense. > http://p.sf.net/sfu/splunk-d2dcopy1 > _______________________________________________ > Pdfedit-support mailing list > Pdfedit-support@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/pdfedit-support -- Michal Hocko ------------------------------------------------------------------------------ All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1 _______________________________________________ Pdfedit-support mailing list Pdfedit-support@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/pdfedit-support
