wrapper argv[0] [was: testsuite: distributed depending on non-distributed]

[Eric Blake]

-----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             address@hidden
-----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-----