Re: Libtool doesn't set -rpath automatically when needed?
Hello Benoit,
* Benoit SIGOURE wrote on Fri, Nov 02, 2007 at 10:34:13PM CET:
On GNU/Linux Debian with GCC 4.1 / Debian's libtool 1.5.22-4
(1.1220.2.365 2005/12/18 22:14:06), I have Boost installed under /usr/
local/lib (pre-built binaries: http://www.tsunanet.net/~tsuna/
boost_1_34_1-i486-linux-gcc41.tar.gz) and when I link with `-
lboost_thread-gcc41-mt-1_34_1 -pthread' I can't run the executable
without manually setting LD_LIBRARY_PATH. Shouldn't libtool do
something about this? I know that Boost doesn't come with .la files
[...]
Libtool doesn't add run paths to installed libraries without .la files.
(How should it know that it should not only add /usr/local/lib, but also
/opt/foo/lib because that is needed as well? OK, this question is moot
on GNU/Linux, but not on other systems.)
You can use -R/usr/local/lib to make libtool add one.
but since /usr/local/lib isn't in sys_lib_search_path_spec, shouldn't
it use -rpath and friends when available/required?
What would be the best solution to handle this issue? Write my own
check to see how to set the rpath (-rpath/-Wl,-rpath/-R/etc.) and
check if linking against -lboost_thread* requires a -rpath or not,
and if it does, automagically add it to BOOST_THREADS_LDFLAGS? That
sounds tedious. And how is it going to work on, say, OSX, where
there is no -rpath/-R?
OS X is not so much a problem because it remembers the location of the
library that was linked against at link edit time.
Moreover, I don't see how to do such a check
while preserving cross-compilation capabilities (since checking
whether -rpath works or not requires to run the binary somehow,
doesn't it?
You don't need to, AC_PROG_LIBTOOL does that for you.
Or maybe analyzing the output of `ldd'?
AC_PROG_LIBTOOL does that for you, too, on GNU/Linux. Query by
eval `${LIBTOOL} --config | grep ^sys_lib_search_path_spec=`
But it surely isn't something standard, for instance on OSX it's
`otool -L' and it requires the package odcctools...).
Hmm, I don't think we do that, but what would it be good for?
Cheers,
Ralf
___
http://lists.gnu.org/mailman/listinfo/libtool
Re: Libtool doesn't set -rpath automatically when needed?
On Nov 3, 2007, at 9:53 AM, Ralf Wildenhues wrote: Hello Benoit, * Benoit SIGOURE wrote on Fri, Nov 02, 2007 at 10:34:13PM CET: On GNU/Linux Debian with GCC 4.1 / Debian's libtool 1.5.22-4 (1.1220.2.365 2005/12/18 22:14:06), I have Boost installed under / usr/ local/lib (pre-built binaries: http://www.tsunanet.net/~tsuna/ boost_1_34_1-i486-linux-gcc41.tar.gz) and when I link with `- lboost_thread-gcc41-mt-1_34_1 -pthread' I can't run the executable without manually setting LD_LIBRARY_PATH. Shouldn't libtool do something about this? I know that Boost doesn't come with .la files [...] Libtool doesn't add run paths to installed libraries without .la files. (How should it know that it should not only add /usr/local/lib, but also /opt/foo/lib because that is needed as well? OK, this question is moot on GNU/Linux, but not on other systems.) You can use -R/usr/local/lib to make libtool add one. I don't want libtool to add run paths to already installed libraries (this is obviously impossible, simply because it would require root privileges to change /usr/local/lib/libboost_*), I'd like libtool to add a run path to my own library/program so that I can run them without having to deal with LD_LIBRARY_PATH issues. Moreover, I don't see how to do such a check while preserving cross-compilation capabilities (since checking whether -rpath works or not requires to run the binary somehow, doesn't it? You don't need to, AC_PROG_LIBTOOL does that for you. OK great so maybe I can copy/paste the part of AC_PROG_LIBTOOL that does this in my own macro so I can portably figure out the -rpath/-R/ etc. options needed and then add them to BOOST_THREADS_LDFLAGS, right? I don't think it'd be a good idea to add AC_REQUIRE ([AC_PROG_LIBTOOL]) to my BOOST_THREADS macros... How does that sound? -- Benoit Sigoure aka Tsuna EPITA Research and Development Laboratory PGP.sig Description: This is a digitally signed message part ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Libtool doesn't set -rpath automatically when needed?
* Benoit SIGOURE wrote on Sat, Nov 03, 2007 at 11:44:15AM CET: On Nov 3, 2007, at 9:53 AM, Ralf Wildenhues wrote: Libtool doesn't add run paths to installed libraries without .la files. (How should it know that it should not only add /usr/local/lib, but also /opt/foo/lib because that is needed as well? OK, this question is moot on GNU/Linux, but not on other systems.) You can use -R/usr/local/lib to make libtool add one. I don't want libtool to add run paths to already installed libraries (this is obviously impossible, simply because it would require root privileges to change /usr/local/lib/libboost_*), That's a misunderstanding (and upon rereading my previous post, I see why I was unclear), so again: If you link a library or program against an installed non-libtool library, then libtool will not add a run path entry pointing to that library's directory. You can do so yourself however by passing -R... to libtool. I'd like libtool to add a run path to my own library/program so that I can run them without having to deal with LD_LIBRARY_PATH issues. Yes. Moreover, I don't see how to do such a check while preserving cross-compilation capabilities (since checking whether -rpath works or not requires to run the binary somehow, doesn't it? You don't need to, AC_PROG_LIBTOOL does that for you. OK great so maybe I can copy/paste the part of AC_PROG_LIBTOOL that does this in my own macro so I can portably figure out the -rpath/-R/ etc. options needed and then add them to BOOST_THREADS_LDFLAGS, right? I don't think it'd be a good idea to add AC_REQUIRE ([AC_PROG_LIBTOOL]) to my BOOST_THREADS macros... How does that sound? You don't *need* to find out how -rpath/-R works. Just pass -R to libtool, it will translate that into -Wl,-rpath or whatever else. You *only* need to find out how -rpath/-R works in case the users of your macro may not want to use Libtool at all. In that case, be advised to use the gnulib module havelib, because it does exactly what you need. Cheers, Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Libtool doesn't set -rpath automatically when needed?
On Nov 3, 2007, at 12:57 PM, Ralf Wildenhues wrote: * Benoit SIGOURE wrote on Sat, Nov 03, 2007 at 11:44:15AM CET: OK great so maybe I can copy/paste the part of AC_PROG_LIBTOOL that does this in my own macro so I can portably figure out the -rpath/-R/ etc. options needed and then add them to BOOST_THREADS_LDFLAGS, right? I don't think it'd be a good idea to add AC_REQUIRE ([AC_PROG_LIBTOOL]) to my BOOST_THREADS macros... How does that sound? You don't *need* to find out how -rpath/-R works. Just pass -R to libtool, it will translate that into -Wl,-rpath or whatever else. You *only* need to find out how -rpath/-R works in case the users of your macro may not want to use Libtool at all. In that case, be advised to use the gnulib module havelib, because it does exactly what you need. Oh I see. Great. All in all, I think I do better document that libtool is required because it does solve all sorts of problems. What's the recommended way of doing this? Simply stating the dependency in the documentation and trust the users to Do The Right Thing? AC_REQUIRE([AC_PROG_LIBTOOL])? Doing some m4-check to ensure that something m4_define'd by AC_PROG_LIBTOOL is indeed defined when my macro is invoked? Or doing a runtime check to check that one of libtool's variables is properly set and bailing out with an AC_MSG_ERROR if not? -- Benoit Sigoure aka Tsuna EPITA Research and Development Laboratory PGP.sig Description: This is a digitally signed message part ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Libtool doesn't set -rpath automatically when needed?
* Benoit SIGOURE wrote on Sat, Nov 03, 2007 at 02:52:25PM CET: Oh I see. Great. All in all, I think I do better document that libtool is required because it does solve all sorts of problems. What's the recommended way of doing this? Simply stating the dependency in the documentation and trust the users to Do The Right Thing? I'd do the first rather than this: AC_REQUIRE([AC_PROG_LIBTOOL])? Rationale: the user may want to invoke some other Libtool-related macros right before and after AC_PROG_LIBTOOL, or use the new LT_INIT notation. Doing some m4-check to ensure that something m4_define'd by AC_PROG_LIBTOOL is indeed defined when my macro is invoked? Or doing a runtime check to check that one of libtool's variables is properly set and bailing out with an AC_MSG_ERROR if not? No, that sounds rather awful. FYI, if you're out to use the libtool script from within configure, then for CVS HEAD Libtool you need to put the LT_OUTPUT macro. It isn't defined nor necessary with 1.5.x. I think you should be able to m4_ifdef([LT_OUTPUT], [AC_REQUIRE([LT_OUTPUT])]) Cheers, Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool
Libtool doesn't set -rpath automatically when needed?
Hi list, On GNU/Linux Debian with GCC 4.1 / Debian's libtool 1.5.22-4 (1.1220.2.365 2005/12/18 22:14:06), I have Boost installed under /usr/ local/lib (pre-built binaries: http://www.tsunanet.net/~tsuna/ boost_1_34_1-i486-linux-gcc41.tar.gz) and when I link with `- lboost_thread-gcc41-mt-1_34_1 -pthread' I can't run the executable without manually setting LD_LIBRARY_PATH. Shouldn't libtool do something about this? I know that Boost doesn't come with .la files but since /usr/local/lib isn't in sys_lib_search_path_spec, shouldn't it use -rpath and friends when available/required? What would be the best solution to handle this issue? Write my own check to see how to set the rpath (-rpath/-Wl,-rpath/-R/etc.) and check if linking against -lboost_thread* requires a -rpath or not, and if it does, automagically add it to BOOST_THREADS_LDFLAGS? That sounds tedious. And how is it going to work on, say, OSX, where there is no -rpath/-R? Moreover, I don't see how to do such a check while preserving cross-compilation capabilities (since checking whether -rpath works or not requires to run the binary somehow, doesn't it? Or maybe analyzing the output of `ldd'? But it surely isn't something standard, for instance on OSX it's `otool -L' and it requires the package odcctools...). Any suggestion would be appreciated. Thanks. -- Benoit Sigoure aka Tsuna EPITA Research and Development Laboratory PGP.sig Description: This is a digitally signed message part ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Libtool doesn't set -rpath automatically when needed?
On Nov 2, 2007, at 11:00 PM, Roumen Petrov wrote: Usually /etc/ld.so.conf contain /usr/local/lib. Dunno why this path is not set on you host. Benoit SIGOURE wrote: Hi list, On GNU/Linux Debian with GCC 4.1 / Debian's libtool 1.5.22-4 (1.1220.2.365 2005/12/18 22:14:06), I have Boost installed under / usr/local/lib (pre-built binaries: http://www.tsunanet.net/~tsuna/ boost_1_34_1-i486-linux-gcc41.tar.gz) and when I link with `- lboost_thread-gcc41-mt-1_34_1 -pthread' I can't run the executable without manually setting LD_LIBRARY_PATH. Shouldn't libtool do something about this? I know that Boost doesn't come with .la files but since /usr/local/lib isn't in sys_lib_search_path_spec, shouldn't it use -rpath and friends when available/required? What would be the best solution to handle this issue? Write my own check to see how to set the rpath (-rpath/-Wl,-rpath/-R/etc.) and check if linking against -lboost_thread* requires a -rpath or not, and if it does, automagically add it to BOOST_THREADS_LDFLAGS? That sounds tedious. And how is it going to work on, say, OSX, where there is no -rpath/-R? Moreover, I don't see how to do such a check while preserving cross- compilation capabilities (since checking whether -rpath works or not requires to run the binary somehow, doesn't it? Or maybe analyzing the output of `ldd'? But it surely isn't something standard, for instance on OSX it's `otool -L' and it requires the package odcctools...). Hi, please avoid top-posting (http://en.wikipedia.org/wiki/Top-posting) [EMAIL PROTECTED] ~ $ cat /etc/ld.so.conf include /etc/ld.so.conf.d/*.conf [EMAIL PROTECTED] ~ $ cat /etc/ld.so.conf.d/*.conf # Multiarch support /lib/i486-linux-gnu /usr/lib/i486-linux-gnu [EMAIL PROTECTED] ~ $ uname -a Linux bf-debian 2.6.18-3-686 #1 SMP Mon Dec 4 16:41:14 UTC 2006 i686 GNU/Linux [EMAIL PROTECTED] ~ $ cat /etc/debian_version 4.0 Cheers, -- Benoit Sigoure aka Tsuna EPITA Research and Development Laboratory PGP.sig Description: This is a digitally signed message part ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Libtool doesn't set -rpath automatically when needed?
Usually /etc/ld.so.conf contain /usr/local/lib. Dunno why this path is not set on you host. Benoit SIGOURE wrote: Hi list, On GNU/Linux Debian with GCC 4.1 / Debian's libtool 1.5.22-4 (1.1220.2.365 2005/12/18 22:14:06), I have Boost installed under /usr/local/lib (pre-built binaries: http://www.tsunanet.net/~tsuna/boost_1_34_1-i486-linux-gcc41.tar.gz) and when I link with `-lboost_thread-gcc41-mt-1_34_1 -pthread' I can't run the executable without manually setting LD_LIBRARY_PATH. Shouldn't libtool do something about this? I know that Boost doesn't come with .la files but since /usr/local/lib isn't in sys_lib_search_path_spec, shouldn't it use -rpath and friends when available/required? What would be the best solution to handle this issue? Write my own check to see how to set the rpath (-rpath/-Wl,-rpath/-R/etc.) and check if linking against -lboost_thread* requires a -rpath or not, and if it does, automagically add it to BOOST_THREADS_LDFLAGS? That sounds tedious. And how is it going to work on, say, OSX, where there is no -rpath/-R? Moreover, I don't see how to do such a check while preserving cross-compilation capabilities (since checking whether -rpath works or not requires to run the binary somehow, doesn't it? Or maybe analyzing the output of `ldd'? But it surely isn't something standard, for instance on OSX it's `otool -L' and it requires the package odcctools...). Any suggestion would be appreciated. Thanks. ___ http://lists.gnu.org/mailman/listinfo/libtool ___ http://lists.gnu.org/mailman/listinfo/libtool
