Re: Feature request: setting env vars for binary wrappers
On Tue, 2008-04-22 at 16:32 +0200, Paolo Bonzini wrote: Behdad Esfahbod wrote: On Fri, 2008-04-18 at 22:27 +0300, Roumen Petrov wrote: I perfectly know that user cannot go in build-dir and just to run secure shell daemon/client. And if you are happy with that, good for you. In GNOME though, we want our users to be able to run uninstalled programs. If this feature is not interesting to you, fine. I don't understand why you are so opposing it. In GNU Smalltalk, ./gst is used if you don't need to load any plugin, while tests/gst is used if you need plugins; tests/gst is created by config.status. Most of the time launching ./gst is enough; and since its startup time is much faster than tests/gst, I didn't feel the need to use the more user-friendly executable as the default. Sure, you have updated for the separate-wrapper option. Now what percentage of your users know the difference between ./gst and tests/gst? How many read the doc explaining the difference? I see how you might consider this a poor choice if you have a lot of executables; OTOH autoconf does the same and has 6-7 executables. We're talking about every application using GNOME technology... I don't understand why something as simple as running uninstalled binaries should become so painful on the application developer. Paolo -- 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
Re: Feature request: setting env vars for binary wrappers
On Fri, 2008-04-18 at 21:53 +0300, Roumen Petrov wrote: In some cases application depend from other services. In this case a specific to project wrapper script has to run services, to check if service is run, to run project application and when application finish to stop service. The test can be run from makefile. Now I'm getting the impression that you selectively read the responses in this thread and ignore the rest. Please tell me *how*, from makefile or otherwise, the problem can be solved such that when my user goes into his build directory and runs the command: $ ./pango-view how as the developer, I can make that command run in a modified environment? -- 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
Re: Feature request: setting env vars for binary wrappers
On Fri, 2008-04-18 at 21:32 +0300, Roumen Petrov wrote: About no way to fix this problem with autotools. Why ? As example libxml can run binaries from build dir. In one of the tests is created specific xml catalog and application is run with this catalog instead with system. Stop talking about tests. This is not about tests. This is not about your-favorite-project running binaries. It's about *user*, a human, luser, whatever you call it, running the binary, in its uninstalled form. -- 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
Re: Feature request: setting env vars for binary wrappers
On Fri, 2008-04-18 at 22:27 +0300, Roumen Petrov wrote: I perfectly know that user cannot go in build-dir and just to run secure shell daemon/client. And if you are happy with that, good for you. In GNOME though, we want our users to be able to run uninstalled programs. If this feature is not interesting to you, fine. I don't understand why you are so opposing it. Apparently not on any technical reasoning. -- 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
Re: Feature request: setting env vars for binary wrappers
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
Re: Feature request: setting env vars for binary wrappers
On Thu, 2008-04-17 at 23:38 +0300, Roumen Petrov wrote: I think that all above is out of libtool scope. It's is exceptional project specific (lets skip cross-compilation environment) and is subject of project regression test suite. The project is responsible to set appropriate test environment before to run regression test. Please let me know when I don't understand request properly. It's not about regression testing at all. It's about making binaries in uninstalled builds work. For example, many GNOME applications need to load their UI from XML files. If you build and not install them and try to run from the build dir, not surprisingly, the XML file is not found at destination, and the program will fail to start. With my proposed additions, programs can for example check for an env var for an alternative prefix, and the Makefile.am can pass that information to libtool to put into the wrapper. Then running from uninstalled build will work. If running uninstalled build is not a goal, why bother about LD_LIBRARY_PATH'ing the uninstalled library path at all? Roumen 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
Re: Feature request: setting env vars for binary wrappers
On Thu, 2008-04-17 at 16:40 -0500, Bob Friesenhahn wrote: An unfortunate thing is that not all software is configured the same. For example, my own software supports independent configuration for the location of different types of files. A single top prefix environment variable would not directly work with my application while it might work for others. A single top prefix would require that the application know the structure of the build tree, which is likely a bad thing since it may not match the install tree. It doesn't matter whether your app works with one prefix or not. That's not being proposed here. What is proposed is adding feature that lets application developer pass any env-var or cmd-line arguments that they need to the uninstalled binary. You get to decide what to set. It seems to me that the proper place to fix this is at the Automake level since Automake's weak support for tests is the true cause of the problem. As I said, my use case is not running tests at all. For tests I use automake's TESTS_ENVIRONMENT variable and it works great. For example I have: TESTS_ENVIRONMENT = CAIRO_XFAIL_TESTS=$(XFAIL_TESTS:$(EXEEXT)=) CAIRO_TEST_TARGET=$(TARGETS) CAIRO_TEST_TARGET_EXCLUDE=$(TARGETS_EXCLUDE) My use case is when users (or myself) want to run the pango/pango-view/pango-view binary, by hand. I can put a pango-view.sh by its side, but users won't run it. We went through this all two years ago :). -- 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
Re: Feature request: setting env vars for binary wrappers
On Fri, 2008-04-18 at 00:45 +0300, Roumen Petrov wrote:
Behdad Esfahbod wrote:
On Thu, 2008-04-17 at 23:38 +0300, Roumen Petrov wrote:
I think that all above is out of libtool scope.
It's is exceptional project specific (lets skip cross-compilation
environment) and is subject of project regression test suite.
The project is responsible to set appropriate test environment
before
to run regression test.
Please let me know when I don't understand request properly.
It's not about regression testing at all. It's about making
binaries in
uninstalled builds work. For example, many GNOME applications need
to
load their UI from XML files. If you build and not install them and
try
to run from the build dir, not surprisingly, the XML file is not
found
at destination, and the program will fail to start. With my
proposed
additions, programs can for example check for an env var for an
alternative prefix, and the Makefile.am can pass that information to
libtool to put into the wrapper. Then running from uninstalled
build
will work.
If running uninstalled build is not a goal, why bother about
LD_LIBRARY_PATH'ing the uninstalled library path at all?
Roumen
Cheers,
Exactly, libtool do home work and set LD_LIBRARY_PATH
(DYLD_LIBRARY_PATH
, LIBRARY_PATH, PATH and etc. host/platform specific environment
library
search paths) but for application specific environment is
author/project
responsibility. I see that you understand case when a library isn't
installed at specified(system) location. This library will load
dependent libraries from default(system) library search path. So the
wrapper script help correct library to be loaded so the libtool home
work is done.
Sure. The request is: since libtool already has this machinery for a
wrapper in place, can you please expose it to application developers so
they can benefit from it too?.
But if user run directly an application installed in non-default
location the user is responsible to set environment.
I'm not talking about application installed in non-default location.
I'm talking about uninstalled application.
If its a regression/unit test the correct application environment has
to
be set in Makefile{|.in|.am} and the program/library will inherit it.
No, it's not a test suite. It's a real, legitimate application the user
has built. Now he wants to run it before doing make install.
Roumen
--
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
Re: Feature request: setting env vars for binary wrappers
On Fri, 2008-04-18 at 02:32 +0300, Roumen Petrov wrote:
Behdad Esfahbod wrote:
[SNIP]
But if user run directly an application installed in non-default
location the user is responsible to set environment.
I'm not talking about application installed in non-default location.
I'm talking about uninstalled application.
There is no significant difference !
I thought there is. The former is not supported, while I'm under the
impression that the latter is.
If its a regression/unit test the correct application environment has
to
be set in Makefile{|.in|.am} and the program/library will inherit it.
No, it's not a test suite. It's a real, legitimate application the user
has built. Now he wants to run it before doing make install.
And if application don't read environment, next request is libtool
wrapper script to pass arguments to application command line.
The argument passing is part of the patch too. But one or the other is
enough, because the application developer can use whatever is available
to them. Currently, there is no way to fix this problem with autotools.
With the proposed changes, there will be. That's all.
The whole idea is libtool overkill.
Fair enough. Just suggest an alternative please, instead of acting as
if the problem does not exist.
Roumen
--
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
