Re: Feature request: setting env vars for binary wrappers

2006-06-15 Thread Gary V. Vaughan
Ralf Wildenhues wrote:
 Hi Gary,

Hallo Ralf!

 * Gary V. Vaughan wrote on Wed, Jun 14, 2006 at 01:11:45PM CEST:
 Ralf Wildenhues wrote:
 [ this is: http://thread.gmane.org/gmane.comp.gnu.libtool.bugs/5319
 or http://lists.gnu.org/archive/html/bug-libtool/2006-03/msg00013.html ]
 
 What do you think?  OK for HEAD right now, or do you think this is too
 intrusive now?
 I have no problem with the principle, but as the patch stands there are
 idiosyncracies that need ironing out before it is complete.
 
 Care to list them, so this can be fixed?

The conceptual problems you listed yourself in the mail I replied to!

Cheers,
Gary.
-- 
Gary V. Vaughan  ())_.  [EMAIL PROTECTED],gnu.org}
Research Scientist   ( '/   http://blog.azazil.net
GNU Hacker   / )=   http://trac.azazil.net/projects/libtool
Technical Author   `(_~)_   http://sources.redhat.com/autobook



signature.asc
Description: OpenPGP digital signature
___
Bug-libtool mailing list
Bug-libtool@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-libtool


Re: Feature request: setting env vars for binary wrappers

2006-03-09 Thread 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


___
Bug-libtool mailing list
Bug-libtool@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-libtool