libtool
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: wrapper argv[0]


From: Ralf Wildenhues
Subject: Re: wrapper argv[0]
Date: Fri, 15 Sep 2006 18:11:57 +0200
User-agent: Mutt/1.5.13 (2006-09-01)

Hello Eric,

* Eric Blake wrote on Thu, Sep 14, 2006 at 01:28:16PM CEST:
> According to Ralf Wildenhues on 9/14/2006 5:08 AM:
> > * Eric Blake wrote on Thu, Sep 14, 2006 at 12:26:53PM CEST:
[ exec -a ]
> > 
> > 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'.

AFAIK those are more or less the only shells to provide this
functionality.  Neither dash (Debian ash), Solaris sh, HP-UX sh, AIX sh
(IIRC), or other traditional shells do.  So no, I don't see much benefit
a spy would have.

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

Currently the wrapper is used not only for adjusting the environment a
bit, but also to provide information for other libtool queries, relink
and such.  An executable wrapper would
- have to provide all of this functionality,
- be portable (not only to mingw and cygwin),
- somehow offer a way to show transparently what is being done
  (nothing beats looking at the shell script in case you're trying to
  find out why something broke, or running it with `sh -x').

I'm not saying it cannot be done; but it's a bit of work.

One could also ponder the double route: a shell plus a binary wrapper,
similarly to the w32 case.  May be much less work (and would provide for
a smoother upgrade path towards a fully binary wrapper). 

Cheers,
Ralf




reply via email to

[Prev in Thread] Current Thread [Next in Thread]