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