On Tue, 2006-06-13 at 17:00 -0400, 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 ]
Hi Behdad, everyone,
Hi again,
Sorry for the delay again.
So, yeah, replying after two years... I know. Hope you still remember
this issue and the patch is not too stale by now...
* Behdad Esfahbod wrote on Thu, Mar 09, 2006 at 04:59:38PM CET:
On Wed, 1 Mar 2006, Ralf Wildenhues wrote:
* 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.
[ my concerns were: we don't always build a wrapper ATM. ]
Sure, a wrapper is created if need be. And this feature can be just
another reason to create a wrapper.
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?)
More or less, yes.
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.
Yep. And that's really the easiest solution: as soon as extra arguments
or extra environment variables are passed, we always build a wrapper.
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.
I don't quite understand how this fixes any security problems...
but here you go with a suggestion (against current CVS HEAD).
The attached patch implements two new link flags, -wrapper-arg and
-wrapper-env, to prepend arguments to programs, and modify their
environment. They will force creating a (shell) wrapper.
Here's the hairy part about it: somebody may eventually want to extend
the C wrapper that is currently used on w32 to encompass all the
functionality that the shell wrapper currently has. And while I don't
have current plans about this, I still don't want to add any
unnecessary obstackles to it.
Fair enough.
So whatever we add to the shell wrapper should be doable easily in a C
wrapper as well. This led me to add these restrictions: the
-wrapper-env works like putenv: you pass an argument `var=value', the
variable will be exported, the value will _not_ be interpreted by the
shell any more. For now you cannot unset variables (this is to cater
for hosts with a shell that does not support `unset'), and, e.g.,
-wrapper-env 'foo=$bar'
will cause the environment variable `foo' to contain the four characters
$, b, a, and r, not the contents of the variable $bar.
But make variables are expanded, right?
Similarly, -wrapper-arg will add exactly one literal argument to the
exec. I've put suitable quoting in place for this to work with most
kinds of input, and of course a test to this end.
What do you think? OK for HEAD right now, or do you think this is too
intrusive now?
Sounds good to me. Can it finally go in?!
I think we should not backport this to 1.5.x, it is a new feature.
Cheers,
Ralf
Cheers,