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, -- behdad http://behdad.org/ "Those who would give up Essential Liberty to purchase a little Temporary Safety, deserve neither Liberty nor Safety." -- Benjamin Franklin, 1759
