Re: Libtool uses obsolete Autoconf macros
Hello Benoit, * Benoit SIGOURE wrote on Sat, Nov 03, 2007 at 10:52:31PM CET: > I don't know whether this is intended (for, say, backward > compatibility with older Autoconf) but Libtool uses obsolete macros > which generates "spurious" warning in my testsuite. Yes, exactly for backward compatibility. A patch that rewrites the uses that also provides this same compatibility would probably be good in order to avoid the warnings. It could define AS_HELP_STRING suitably if it were not defined yet, and contain a comment to remove the define once we assume new enough Autoconf. Cheers, Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool
Libtool uses obsolete Autoconf macros
Hello list, I don't know whether this is intended (for, say, backward compatibility with older Autoconf) but Libtool uses obsolete macros which generates "spurious" warning in my testsuite. Background info: I'm writing a set of M4 macros to properly use Boost with the Autotools, I had a problem with the fact that Boost doesn't come with .la files, so I had to require my users to use Libtool so I could use -R and let Libtool do the magic with run paths. My testsuite is made with Autotest and most of it comes from Autoconf's own testsuite. I'd like to keep the -W obsolete flag if possible, to make sure that I don't use obsolete macros. 1. testsuite.at:243: testing ... ../../tests/testsuite.at:243: autoconf --force -W obsolete --- /dev/null 2007-11-03 22:43:11.0 +0100 +++ /Users/tsuna/svn/git/boost.m4/_build/tests/testsuite.dir/at- stderr 2007-11-03 22:43:12.0 +0100 @@ -0,0 +1,36 @@ +configure.ac:3: warning: The macro `AC_HELP_STRING' is obsolete. +configure.ac:3: You should run autoupdate. +autoconf/general.m4:209: AC_HELP_STRING is expanded from... +autoconf/general.m4:1373: AC_ARG_ENABLE is expanded from... +aclocal.m4:1943: AC_ENABLE_SHARED is expanded from... +aclocal.m4:231: AC_LIBTOOL_SETUP is expanded from... +aclocal.m4:86: _AC_PROG_LIBTOOL is expanded from... +aclocal.m4:66: AC_PROG_LIBTOOL is expanded from... +configure.ac:3: the top level +aclocal.m4:1982: AC_ENABLE_STATIC is expanded from... +aclocal.m4:2021: AC_ENABLE_FAST_INSTALL is expanded from... +autoconf/general.m4:1391: AC_ARG_WITH is expanded from... +aclocal.m4:2218: AC_PROG_LD is expanded from... +configure.ac:3: warning: The macro `AC_TRY_LINK' is obsolete. +configure.ac:3: You should run autoupdate. +autoconf/general.m4:2415: AC_TRY_LINK is expanded from... +../../lib/m4sugar/m4sh.m4:523: AS_IF is expanded from... +autoconf/general.m4:1905: AC_CACHE_VAL is expanded from... +autoconf/general.m4:1918: AC_CACHE_CHECK is expanded from... +aclocal.m4:619: _LT_AC_LOCK is expanded from... +aclocal.m4:1105: AC_LIBTOOL_SYS_HARD_LINK_LOCKS is expanded from... +aclocal.m4:2730: _LT_AC_LANG_C_CONFIG is expanded from... +aclocal.m4:2661: AC_LIBTOOL_LANG_C_CONFIG is expanded from... +aclocal.m4:1897: _LT_AC_TAGCONFIG is expanded from... +configure.ac:3: warning: back quotes and double quotes must not be escaped in: $as_me:$LINENO: error: tag name \"$tagname\" already exists +configure.ac:3: warning: back quotes and double quotes must not be escaped in: $as_me: error: tag name \"$tagname\" already exists +configure.ac:3: warning: The macro `AC_LANG_SAVE' is obsolete. +configure.ac:3: You should run autoupdate. +autoconf/lang.m4:170: AC_LANG_SAVE is expanded from... +aclocal.m4:4051: _LT_AC_LANG_GCJ_CONFIG is expanded from... +aclocal.m4:4003: AC_LIBTOOL_LANG_GCJ_CONFIG is expanded from... +configure.ac:3: warning: The macro `AC_LANG_RESTORE' is obsolete. +configure.ac:3: You should run autoupdate. +autoconf/lang.m4:176: AC_LANG_RESTORE is expanded from... +aclocal.m4:4095: _LT_AC_LANG_RC_CONFIG is expanded from... +aclocal.m4:4059: AC_LIBTOOL_LANG_RC_CONFIG is expanded from... 1. testsuite.at:243: 1. BOOST_REQUIRE (testsuite.at:243): FAILED (testsuite.at:243) Just in case, the sources of this package can be found at http:// repo.or.cz/w/boost.m4.git 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?
* 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
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 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 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?
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
