From: Bollinger, J. C <John.Bollinger@STJUDE.ORG> - 2011-09-22 16:18:13
|
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 |
From: Michal H. <ms...@gm...> - 2011-09-22 17:40:08
|
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 > Pdf...@li... > https://lists.sourceforge.net/lists/listinfo/pdfedit-support -- Michal Hocko |
From: Bollinger, J. C <John.Bollinger@STJUDE.ORG> - 2011-09-22 19:15:29
|
On Thursday, September 22, 2011 12:40 PM, Michal Hocko [mailto:ms...@gm...] wrote: > What kind of problems you have with our bug tracker? I can access > http://pdfedit.petricek.net/bt/main_page.php just fine. I don't have any trouble with that URL, thanks. The problem is that I didn't have it in the first place, because that's not where the "Bugtracker" hyperlink on http://pdfedit.cz/en/index.html takes me. The hyperlink is directed instead at http://pdfedit.petricek.net/bt/, which is redirected to http://pdfedit.petricek.net/bt/index.html (apparently an alternative URL for the PDFedit home page). > OK, this seems that libt and xlib where taken from the bad path. > 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 Ok. The boost and t1 options are documented, and that's how I worked around the problem. > ./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. Thanks Michal. I have more than a passing familiarity with Autoconf, so I may just take a stab at this. No promises, though. Cheers, John Email Disclaimer: www.stjude.org/emaildisclaimer |
From: Michal H. <ms...@gm...> - 2011-09-22 19:54:42
|
On Thu, Sep 22, 2011 at 02:15:14PM -0500, Bollinger, John C wrote: > On Thursday, September 22, 2011 12:40 PM, Michal Hocko [mailto:ms...@gm...] wrote: > > > What kind of problems you have with our bug tracker? I can access > > http://pdfedit.petricek.net/bt/main_page.php just fine. > > > I don't have any trouble with that URL, thanks. The problem is that > I didn't have it in the first place, because that's not where the > "Bugtracker" hyperlink on http://pdfedit.cz/en/index.html takes me. > The hyperlink is directed instead at http://pdfedit.petricek.net/bt/, > which is redirected to http://pdfedit.petricek.net/bt/index.html > (apparently an alternative URL for the PDFedit home page). Martin? -- Michal Hocko |
From: Jozef <mis...@ho...> - 2011-09-23 05:16:50
|
Dne 22.9.2011 21:54, Michal Hocko napsal(a): > On Thu, Sep 22, 2011 at 02:15:14PM -0500, Bollinger, John C wrote: >> On Thursday, September 22, 2011 12:40 PM, Michal Hocko [mailto:ms...@gm...] wrote: >> >>> What kind of problems you have with our bug tracker? I can access >>> http://pdfedit.petricek.net/bt/main_page.php just fine. >> >> I don't have any trouble with that URL, thanks. The problem is that >> I didn't have it in the first place, because that's not where the >> "Bugtracker" hyperlink on http://pdfedit.cz/en/index.html takes me. >> The hyperlink is directed instead at http://pdfedit.petricek.net/bt/, >> which is redirected to http://pdfedit.petricek.net/bt/index.html >> (apparently an alternative URL for the PDFedit home page). Fixed that, thx. jm > Martin? > |
From: Michal H. <ms...@gm...> - 2011-09-22 19:56:06
|
On Thu, Sep 22, 2011 at 02:15:14PM -0500, Bollinger, John C wrote: > On Thursday, September 22, 2011 12:40 PM, Michal Hocko [mailto:ms...@gm...] wrote: [...] > > > 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 > > > Ok. The boost and t1 options are documented, and that's how I worked > around the problem. So is the problem still present with those 2 parameters? > > > > ./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. > > > Thanks Michal. I have more than a passing familiarity with Autoconf, > so I may just take a stab at this. No promises, though. Would be appreciated, indeed. > > > Cheers, > > John > > 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 > Pdf...@li... > https://lists.sourceforge.net/lists/listinfo/pdfedit-support -- Michal Hocko |
From: Bollinger, J. C <John.Bollinger@STJUDE.ORG> - 2011-09-22 21:55:25
|
On Thursday, September 22, 2011 2:56 PM, Michal Hocko [mailto:ms...@gm...] wrote: > On Thu, Sep 22, 2011 at 02:15:14PM -0500, Bollinger, John C wrote: > > On Thursday, September 22, 2011 12:40 PM, Michal Hocko > [mailto:ms...@gm...] wrote: > [...] > > > > > 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 > > > > > > Ok. The boost and t1 options are documented, and that's how I > worked > > around the problem. > > So is the problem still present with those 2 parameters? If I specify the correct library locations via those parameters then the program links successfully, even zlib. In fact, I only need to specify the correct location for one library, since all the needed ones are in the same place, and the linker processes all -L options before any -l option. My complaint is that I shouldn't need to specify library locations when the libaries are in an LSB-approved and distro-standard place to begin with. Obviously, that is much less significant problem than not being able at all to build the program. If I can find the time to improve the autoconf macros in this area then I will be helping myself. Thanks, John Email Disclaimer: www.stjude.org/emaildisclaimer |