Re: testsuite: distributed depending on non-distributed
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Ralf, According to Ralf Wildenhues on 9/13/2006 8:43 PM: > > Thanks, but now I get `make check' failures for tests 42-47: > > Cheers, > Ralf > > # -*- compilation -*- > 42. modules.at:112: testing ... > --- - 2006-09-14 04:25:19.179785000 +0200 > +++ /tmp/m4/build/tests/testsuite.dir/at-stderr 2006-09-14 > 04:25:19.0 +0200 > @@ -1,5 +1,5 @@ > Test module loaded. > test: > Test module unloaded. > -m4:input.m4:6: Warning: dumpdef: undefined macro `test' > +/tmp/m4/build/src/.libs/lt-m4:input.m4:6: Warning: dumpdef: undefined macro > `test' Would it be worth it if libtool were to check if the shell's exec supports the -a option, and if so, use that feature within the libtool wrapper so that the invoked program is given the same argv[0] as the libtool wrapper rather than an absolute path which exposes the different executable name for uninstalled binaries? - -- Life is short - so eat dessert first! Eric Blake [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.1 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFCS5t84KuGfSFAYARArFPAJ9MeZfMUwKdinmLh/E67VNDPEV8tQCgn+EJ wmzJ4IzqmRYWP923MgHrzF8= =/9/F -END PGP SIGNATURE- ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: testsuite: distributed depending on non-distributed
Hello Eric, * Eric Blake wrote on Thu, Sep 14, 2006 at 12:26:53PM CEST: > > > -m4:input.m4:6: Warning: dumpdef: undefined macro `test' > > +/tmp/m4/build/src/.libs/lt-m4:input.m4:6: Warning: dumpdef: undefined > > macro `test' > > Would it be worth it if libtool were to check if the shell's exec supports > the -a option, and if so, use that feature within the libtool wrapper so > that the invoked program is given the same argv[0] as the libtool wrapper > rather than an absolute path which exposes the different executable name > for uninstalled binaries? I've had that thought before. One downside is that many developers may not be exposed to the problem at all, so may not notice the issue and the need to work around it for systems with less capable shells. It's a close call. A portable solution would certainly be preferable. Cheers, Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool
wrapper argv[0] [was: testsuite: distributed depending on non-distributed]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi again, Ralf, According to Ralf Wildenhues on 9/14/2006 5:08 AM: > Hello Eric, > > * Eric Blake wrote on Thu, Sep 14, 2006 at 12:26:53PM CEST: >>> -m4:input.m4:6: Warning: dumpdef: undefined macro `test' >>> +/tmp/m4/build/src/.libs/lt-m4:input.m4:6: Warning: dumpdef: undefined >>> macro `test' >> Would it be worth it if libtool were to check if the shell's exec supports >> the -a option, and if so, use that feature within the libtool wrapper so >> that the invoked program is given the same argv[0] as the libtool wrapper >> rather than an absolute path which exposes the different executable name >> for uninstalled binaries? > > I've had that thought before. One downside is that many developers > may not be exposed to the problem at all, so may not notice the issue > and the need to work around it for systems with less capable shells. > > It's a close call. A portable solution would certainly be preferable. Could we at least add a spy in the configure script that sees what platforms out there in current use do not have a shell capable of changing argv[0]? bash has 'exec -a name command', zsh has 'ARGV0=name command', but I didn't find anything in my perusal of 'man pdksh'. Or we could always convert the libtool wrapper to a C program, and use execl ourselves rather than relying on shell scripting for the wrapper. - -- Life is short - so eat dessert first! Eric Blake [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.1 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFCTzQ84KuGfSFAYARAlukAKDIf6xf8sBR75wUqxTbz7lyH/Ma+gCgv7qO FyD5zcazmMbSFpQ10KyLUpc= =Jxf1 -END PGP SIGNATURE- ___ http://lists.gnu.org/mailman/listinfo/libtool
Move from handcrafted makefile to libtool
Hello, project newt currently uses handcrafted makefiles and installs libnewt like this: /usr/lib/libnewt.so.0.52.1 /usr/lib/libnewt.so.0.52 -> libnewt.so.0.52.1 where SONAME is libnewt.so.0.52 We would like use automake with the project, which means libtool should be used for shared libraries. Is there a way to get the above soname, so that current applications need not be recompiled? The option -version-number seems to generate sonames in form libname.so.n Or is there a way to modify the builddir/libtool script to get this? Please CC me, I'm not subscribed. Thanks for any help, Stepan Kasal ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: AC_LIBTOOL_SYS_DYNAMIC_LINKER "gcc -print-search-dirs" problem
On Sep 14, 2006, at 4:18 AM, Kate Minola wrote:
Ralf, Peter,
Why not use the output of "gcc -print-search-dirs"
and, for every directory that ends with "lib", append the
value returned by "gcc -print-multi-os-directory"? Naturally
one will have to "backup" directories such as
/usr/lib/gcc/x86_64-linux-gnu/4.0.3/../../..
to realize that it ends with "lib". (Other than writing
a program, I do not see an easy way to do this last bit.)
Well, because I would rather use the flags that the compiler actually
uses rather than the ones it says it uses, I'm still not sure that my
method is best though...
While looking into a patch for this, I notice that
sys_lib_search_path_spec is not a tagged var, so we run it for each
compiler for each tag, with the latest one it finds being the final
answer. Does not seem quite right to me.
I also came up with the awk expression from hell :-)
sys_lib_search_path_spec=`$CC $compilerFLAGS $CPPFLAGS $LDFLAGS -v -o
conftest /dev/null 2>&1 | $AWK 'BEGIN {RS=" "; FS="/"; } /^-L\// {sub
("-L",""); sub("//","/"); sub("/./","/");sub("/$","");foo="";for (i =
NF; i > 0; i--) if ($i == "..") count++;else if (count == 0) if (foo
== "")foo=$i; else foo=$i "/" foo; else count--;} { if (foo != "")
freq[foo]++; if (freq[foo] == 1)print foo;}'`
Peter
___
Bug-libtool mailing list
Bug-libtool@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-libtool
Re: AC_LIBTOOL_SYS_DYNAMIC_LINKER "gcc -print-search-dirs" problem
Hello Peter, * Peter O'Gorman wrote on Thu, Sep 14, 2006 at 05:22:30PM CEST: > On Sep 14, 2006, at 4:18 AM, Kate Minola wrote: > > >Why not use the output of "gcc -print-search-dirs" [...] > Well, because I would rather use the flags that the compiler actually > uses rather than the ones it says it uses, I'm still not sure that my > method is best though... You may want to read this: http://lists.gnu.org/archive/html/libtool-patches/2005-01/msg00181.html and then decide whether to ignore it or not. If yes, then that should be documented. (I think the reverse downside was that gcc would not list search dirs that don't exist at the time; but I haven't tested it either and can't find a reference to this now.) > While looking into a patch for this, I notice that > sys_lib_search_path_spec is not a tagged var, so we run it for each > compiler for each tag, with the latest one it finds being the final > answer. Does not seem quite right to me. Good catch. Probably doing this for the C compiler only should be enough. > I also came up with the awk expression from hell :-) You also came up with a writedown that was unreadable as hell. ;-) (There is no need to avoid newlines; in the single-quoted awk script you don't even have to backslash-quote them.) You definitely want to use a real and valid object file as input. You want to skip all user-provided paths in CFLAGS or LDFLAGS. And please try it with echo -L/foo/bar/./. as input. And please take a look at the Autoconf portability section about awk, this code is not gawk-only. Cheers, and thanks, Ralf ___ Bug-libtool mailing list Bug-libtool@gnu.org http://lists.gnu.org/mailman/listinfo/bug-libtool
