From: Martin P. <ma...@pe...> - 2008-03-07 17:08:38
|
Michael Shigorin <mi...@os...> wrote: > Another "patch" to fix build on x86_64: > > sed -i 's,BOOSTLIBDIR=.*$,BOOSTLIBDIR=%_libdir,' configure > > (%_libdir would expand into /usr/lib64 on x86_64 RPM in ALT > at least) Well, configure is generated from configure.in and bunch of macros in "config" directory. The file that contain this to fix is config/boost_iostreams.m4 - but I am not sure if it won't break other things (what if BOOST_LDFLAGS contains already some unusual location of boost library, for example if someone compiles it in their $HOME and then passes the path to configure?), so I'm sending this idea to other developers for review and testing (I think the boost_iostreams.m4 file is somewhere from boost, so perhaps we may fix it by retrieving newer version which may have this bug fixed already). Wait - isn't %_libdir only available when building RPM's? Martin Petricek |
From: Michal H. <ms...@gm...> - 2008-03-07 18:20:55
|
On Fri, Mar 07, 2008 at 06:08:41PM +0100, Martin Petricek wrote: > Michael Shigorin <mi...@os...> wrote: > > Another "patch" to fix build on x86_64: > > > > sed -i 's,BOOSTLIBDIR=.*$,BOOSTLIBDIR=%_libdir,' configure > > > > (%_libdir would expand into /usr/lib64 on x86_64 RPM in ALT > > at least) > > Well, configure is generated from configure.in and bunch of macros in > "config" directory. The file that contain this to fix is > config/boost_iostreams.m4 - but I am not sure if it won't break other > things (what if BOOST_LDFLAGS contains already some unusual location > of boost library, for example if someone compiles it in their $HOME > and then passes the path to configure?), so I'm sending this idea to > other developers for review and testing (I think the > boost_iostreams.m4 file is somewhere from boost, so perhaps we may fix > it by retrieving newer version which may have this bug fixed already). config/boost_*.m4 are the latest (AFAIK) version from boost upstream. If you need to force some other location of libraries and/or headers you can use --with-boost and --with-boost-iostreams parameters to configure. However I would strongly discourage changing boost m4 files unless you know *exactly* what you are doing. > > Wait - isn't %_libdir only available when building RPM's? Looks like spec file variable (but not sure) > > Martin Petricek > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2008. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > Pdfedit-devel mailing list > Pdf...@li... > https://lists.sourceforge.net/lists/listinfo/pdfedit-devel -- Michal Hocko |
From: Michael S. <mi...@os...> - 2008-03-08 21:49:16
|
On Fri, Mar 07, 2008 at 07:20:52PM +0100, Michal Hocko wrote: > > > Another "patch" to fix build on x86_64: > > > sed -i 's,BOOSTLIBDIR=.*$,BOOSTLIBDIR=%_libdir,' > > > configure (%_libdir would expand into /usr/lib64 > > > on x86_64 RPM in ALT at least) > > Well, configure is generated from configure.in and bunch of > > macros in "config" directory. The file that contain this to > > fix is config/boost_iostreams.m4 - but I am not sure if it > > won't break other things Sorry, I only sort of know that boost exists. :) > config/boost_*.m4 are the latest (AFAIK) version from boost > upstream. If you need to force some other location of > libraries and/or headers you can use --with-boost and > --with-boost-iostreams parameters to configure. However I > would strongly discourage changing boost m4 files unless you > know *exactly* what you are doing. Should I ask folks with C++ _and_ x86_64 experience for advice? Actually, Damir has helped; probably he could explain the fix better to you. > > Wait - isn't %_libdir only available when building RPM's? > Looks like spec file variable (but not sure) RPM macro, in fact. -- ---- WBR, Michael Shigorin <mi...@al...> ------ Linux.Kiev http://www.linux.kiev.ua/ |
From: Damir S. <da...@al...> - 2008-03-09 16:04:33
|
> > > > Another "patch" to fix build on x86_64: > > > > sed -i 's,BOOSTLIBDIR=.*$,BOOSTLIBDIR=%_libdir,' > > > > configure (%_libdir would expand into /usr/lib64 > > > > on x86_64 RPM in ALT at least) > > > Well, configure is generated from configure.in and bunch of > > > macros in "config" directory. The file that contain this to > > > fix is config/boost_iostreams.m4 - but I am not sure if it > > > won't break other things The problem with boost on ALT Linux x86_64 is simple: configure scans for Boost IoStreams libraries in BOOSTLIBDIR. BOOSTLIBDIR is deduced from BOOST_LDFLAGS by sed script: BOOSTLIBDIR=`echo $BOOST_LDFLAGS | sed -e 's/[^\/]*//'` (config/boost_iostreams.m4) That is, if BOOST_LDFLAGS is "-L/usr/lib", BOOSTLIBDIR is /usr/lib. But on ALT Linux x86_64, boost libraries are in /usr/lib64. In theory, if BOOST_LDFLAGS is "-L/usr/lib64", BOOSTLIBDIR will be /usr/lib64, and this would lead to successful ./configure run. Actually, BOOST_LDFLAGS can never be set to /usr/lib64. In config/boost_base.m4, BOOST_LDFLAGS is set to one of these: fgrep BOOST_LDFLAGS= pdfedit-0.4.1/config/boost_base.m4 BOOST_LDFLAGS="-L$ac_boost_path/lib" BOOST_LDFLAGS="-L$ac_boost_path_tmp/lib" BOOST_LDFLAGS="-L$ac_boost_path/lib" BOOST_LDFLAGS="-L$best_path/lib" BOOST_LDFLAGS="-L$BOOST_ROOT/stage/lib" So, no /lib64 for BOOST_LDFLAGS, only /lib. This is hardcoded, is set in multiple places and I was lazy enough to find which one to fix. Overriding BOOSTLIBDIR with correct value is quick and dirty hack. The correct solution might include setting BOOST_LDFLAGS to -L$ac_boost_path/lib64 on x86_64, figuring that at runtime somehow. Or there must be a way to explicitly set BOOSTLIBDIR from configure arguments, something like --with-boost-lib=/usr/lib64. > Sorry, I only sort of know that boost exists. :) > > > config/boost_*.m4 are the latest (AFAIK) version from boost > > upstream. If you need to force some other location of > > libraries and/or headers you can use --with-boost and > > --with-boost-iostreams parameters to configure. However I > > would strongly discourage changing boost m4 files unless you > > know *exactly* what you are doing. --with-boost-iostreams can't help, it is for choosing "flavor" of boost-iostreams, not for setting path to it. --with-boost defines a root directory for boost. BOOSTLIBDIR then is set to <directory passed to --with-boost>/lib. There is no way to set BOOSTLIBDIR=/usr/lib64 without patching configure. |
From: Michal H. <ms...@gm...> - 2008-03-09 18:26:29
Attachments:
boost-lib-param.patch
|
On Sun, Mar 09, 2008 at 02:11:05PM +0300, Damir Shayhutdinov wrote: > > > > > Another "patch" to fix build on x86_64: > > > > > sed -i 's,BOOSTLIBDIR=.*$,BOOSTLIBDIR=%_libdir,' > > > > > configure (%_libdir would expand into /usr/lib64 > > > > > on x86_64 RPM in ALT at least) > > > > Well, configure is generated from configure.in and bunch of > > > > macros in "config" directory. The file that contain this to > > > > fix is config/boost_iostreams.m4 - but I am not sure if it > > > > won't break other things > > The problem with boost on ALT Linux x86_64 is simple: > configure scans for Boost IoStreams libraries in BOOSTLIBDIR. > > BOOSTLIBDIR is deduced from BOOST_LDFLAGS by sed script: > > BOOSTLIBDIR=`echo $BOOST_LDFLAGS | sed -e 's/[^\/]*//'` > (config/boost_iostreams.m4) > > That is, if BOOST_LDFLAGS is "-L/usr/lib", BOOSTLIBDIR is /usr/lib. > > But on ALT Linux x86_64, boost libraries are in /usr/lib64. > > In theory, if BOOST_LDFLAGS is "-L/usr/lib64", BOOSTLIBDIR will be > /usr/lib64, and this would lead to successful ./configure run. > > Actually, BOOST_LDFLAGS can never be set to /usr/lib64. In > config/boost_base.m4, BOOST_LDFLAGS is set to one of these: > > fgrep BOOST_LDFLAGS= pdfedit-0.4.1/config/boost_base.m4 > BOOST_LDFLAGS="-L$ac_boost_path/lib" > BOOST_LDFLAGS="-L$ac_boost_path_tmp/lib" > BOOST_LDFLAGS="-L$ac_boost_path/lib" > BOOST_LDFLAGS="-L$best_path/lib" > > BOOST_LDFLAGS="-L$BOOST_ROOT/stage/lib" > > So, no /lib64 for BOOST_LDFLAGS, only /lib. This is hardcoded, is set > in multiple places and I was lazy enough to find which one to fix. You are absolutely right. I have reused these macros from http://randspringer.de/boost/index.html beleaving that they are fine tuned for almost all platforms which ships boost packages. Obviously, this is not a case. > > Overriding BOOSTLIBDIR with correct value is quick and dirty hack. The > correct solution might include setting BOOST_LDFLAGS to > -L$ac_boost_path/lib64 on x86_64, figuring that at runtime somehow. Or > there must be a way to explicitly set BOOSTLIBDIR from configure > argument > > > would strongly discourage changing boost m4 files unless you > > > know *exactly* what you are doing. > --with-boost-iostreams can't help, it is for choosing "flavor" of > boost-iostreams, not for setting path to it. > > --with-boost defines a root directory for boost. BOOSTLIBDIR then is > set to <directory passed to --with-boost>/lib. There is no way to set > BOOSTLIBDIR=/usr/lib64 without patching configure. Attached patch adds the new configure parameter --with-boost-lib which takes directory for boost libraries as the value. I didn't want to brake anything, so LDFLAGS are set as usual unless --with-boost-lib is specified when given value is forced. I have tested it on my machines (Debian, OpenSuse both 32b and Gentoo 64b) and it seems to be working. I have simply created link from /usr/lib to ~/lib and used the later one during configure and everything compiled and linked correctly. Could you try it (you have to generate configure by autoconf) and report back? I will contact author and offer the patch to him later. Thanks for analysis. -- Michal Hocko |
From: Damir S. <da...@al...> - 2008-03-09 18:55:04
|
> Attached patch adds the new configure parameter --with-boost-lib which > takes directory for boost libraries as the value. I didn't want to brake > anything, so LDFLAGS are set as usual unless --with-boost-lib is > specified when given value is forced. > I have tested it on my machines (Debian, OpenSuse both 32b and Gentoo 64b) > and it seems to be working. I have simply created link from /usr/lib to > ~/lib and used the later one during configure and everything compiled and > linked correctly. > Could you try it (you have to generate configure by autoconf) and report > back? I will contact author and offer the patch to him later. Yep, it works as advertised, at least on ALT x86_64. I just applied the patch, run autoconf and then added --with-boost-lib=%_libdir param to configure. Thanks! |
From: Michael S. <mi...@os...> - 2008-03-11 18:32:10
|
On Sun, Mar 09, 2008 at 09:55:10PM +0300, Damir Shayhutdinov wrote: > > Could you try it (you have to generate configure by autoconf) > > and report back? I will contact author and offer the patch to > > him later. > Yep, it works as advertised, at least on ALT x86_64. > I just applied the patch, ran autoconf and then added > --with-boost-lib=%_libdir param to configure. Thanks! Me too (package already updated). -- ---- WBR, Michael Shigorin <mi...@al...> ------ Linux.Kiev http://www.linux.kiev.ua/ |
From: Michal H. <ms...@gm...> - 2008-04-01 18:26:07
Attachments:
boost_base_update.patch
|
On Sun, Mar 09, 2008 at 09:55:10PM +0300, Damir Shayhutdinov wrote: > > Attached patch adds the new configure parameter --with-boost-lib which > > takes directory for boost libraries as the value. I didn't want to brake > > anything, so LDFLAGS are set as usual unless --with-boost-lib is > > specified when given value is forced. > > I have tested it on my machines (Debian, OpenSuse both 32b and Gentoo 64b) > > and it seems to be working. I have simply created link from /usr/lib to > > ~/lib and used the later one during configure and everything compiled and > > linked correctly. > > Could you try it (you have to generate configure by autoconf) and report > > back? I will contact author and offer the patch to him later. > Yep, it works as advertised, at least on ALT x86_64. I just applied > the patch, run autoconf and then added --with-boost-lib=%_libdir param > to configure. Thanks! I have recieved response from original author and he applied my patch upstream with parameter name changed to --with-boost-libdir. Attached patch (applies on top of previous one) synchronizes with upstream behavior and it will be used this way also for our future releases. -- Michal Hocko |
From: Michael S. <mi...@os...> - 2008-04-01 19:51:22
|
On Tue, Apr 01, 2008 at 08:25:26PM +0200, Michal Hocko wrote: > I have recieved response from original author and he applied my patch > upstream with parameter name changed to --with-boost-libdir. > Attached patch (applies on top of previous one) synchronizes with upstream > behavior and it will be used this way also for our future releases. Thanks, I'd probably wait for the next upstream release by now :-) -- ---- WBR, Michael Shigorin <mi...@al...> ------ Linux.Kiev http://www.linux.kiev.ua/ |
From: Michal H. <ms...@gm...> - 2008-03-09 11:57:32
|
On Fri, Mar 07, 2008 at 06:08:41PM +0100, Martin Petricek wrote: > Michael Shigorin <mi...@os...> wrote: > > Another "patch" to fix build on x86_64: > > > > sed -i 's,BOOSTLIBDIR=.*$,BOOSTLIBDIR=%_libdir,' configure > > > > (%_libdir would expand into /usr/lib64 on x86_64 RPM in ALT > > at least) Could you send whole error message on x86_64 you get during configuration (without your change)? Thx -- Michal Hocko |