Re: Feature request: setting env vars for binary wrappers

[Behdad Esfahbod]

On Wed, 1 Mar 2006, Ralf Wildenhues wrote:

> Hi Behdad,

Hello,

> * Behdad Esfahbod wrote on Wed, Mar 01, 2006 at 05:15:17AM CET:
> >
> > This is a feature request for libtool.  Let me describe the
> > problem as I face it, so you may have a workaround for it
> > already:  I'm using libtool in the Pango text rendering engine.
> > The Pango library accesses a file in $prefix/etc/pango/pangorc to
> > find its modules at run-time.  Now all I want to do is to be able
> > to run the examples in pango/example when Pango is not installed.
> >
> > The easiest way that can be done is to set the PANGO_RC_PATH
> > envvar to a special pangorc file.  Another is to pass the
> > --pangorc path-to-pango-rc to the examples if they understand it.
> > What I need from libtool is to let me do one of these things in
> > the wrapper it creates for uninstalled binaries.
> >
> > Do you think this can be done already?
>
> No, not generally.  Well, you could build a(nother) wrapper around it,
> or just call it with the command line option.

Well, the user is calling it, so the only option is another
wrapper (and of course I thought about it), but AFAIK, it's not
straightforward to have a binary called pango-view, and have my
own wrapper named pango-view too.  So I have to create something
like pango-view-uninstalled (for example), and like was already
mentioned, people will forget to use it.

> > Do you see adding support for something like this a useful feature?
>
> I'm tending towards a "yes" here.
>
> One thing you may not be aware of: libtool does not actually create a
> shell wrapper for the uninstalled program in any case; this depends on
> the system in question, on whether fast-install mode is desired or not,
> also there is a TODO item to make no-fast-install mode work right on
> more systems.

I kinda knew this.  I even figured out that it creates a C
wrapper in certain situations.

> What should libtool do if it would not by default create a wrapper?
> Note many users don't like the wrapper: it makes debugging more
> cumbersome, adds runtime overhead, and potentially changes argv[0]
> (for which, again, there is a TODO item to fix this).

Yes, and people have been dealing with these for years (myself
included.)

> If we can find an answer to this question to define coherent semantics,
> I'm all for it.

Ok, this is my view of the problem:  Running uninstalled programs
requires some modifications to the environment.  One is to make
sure that the uninstalled libraries are linked.  Other changes
may be needed, on a per application basis.  Libtool is free to
choose how to implement these.  So far it has only supported the
library path modification, and implemented that using a wrapper
script on some platforms, or using rpath on others (right?)  The
same goes with the other modifications.  They can be easily
implemented using a wrapper.  So if there are such modifications
requested, a wrapper should be used.

There are possible other implementations too.  For example, a C
wrapper is almost as easy to implement.  It will do a bunch of
putenv's, and insert some stuff in argv after argv[0], and exec
the actuall program.  So, this doesn't look much different from
the current issue...

As for the implementation, I suggest something like

my_lib_so_ENV="var1=value1 var2=value2"
my_lib_so_ARGS="--var1 value -v2=value2"

or something like that..

My current workaround has been making pango-view accept a
--pangorc path-to-pangorc parameter and defaulting to ./pangorc.
But that opens up a known security problem...  So I really want
to "fix" it the right way.


> Cheers,
> Ralf

Cheers,
--behdad
http://behdad.org/

"Commandment Three says Do Not Kill, Amendment Two says Blood Will Spill"
        -- Dan Bern, "New American Language"