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