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 [email protected] http://lists.gnu.org/mailman/listinfo/bug-libtool
