-----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
