Re: FYI: Ignoring SIGPIPE in libtoolize
On Thu, 18 May 2006, Ralf Wildenhues wrote: > Hi Behdad, > > * Behdad Esfahbod wrote on Wed, Apr 05, 2006 at 10:39:30AM CEST: > > On Wed, 5 Apr 2006, Ralf Wildenhues wrote: > > > * Behdad Esfahbod wrote on Wed, Apr 05, 2006 at 08:25:41AM CEST: > > > > > > > > In GNOME project, we have severl machines running as tinderboxes, > > > > continuously building all our modules from CVS. In a lot of logs > > > > from these builds I'm seeing these lines: > > > > > > > > /usr/bin/libtoolize: line 93: echo: write error: Broken pipe > > > > /usr/bin/libtoolize: line 94: echo: write error: Broken pipe > > > > Well, I guess the simplest way around it would be to not trigger several > > > writes. How about this instead? > > > Yes, that should fix it, but as I said I cannot test it. > > I've applied this to branch-1-5. HEAD should be fine already. > Sorry for the huge delay. Thanks Ralf, Now if you could look into the env-var issue :) Cheers, behdad > Cheers, > Ralf > > * libtoolize.in: Use just one `echo' for `--version' output > instead of several `echo', to avoid `Broken pipe' errors. > Reported by Behdad Esfahbod <[EMAIL PROTECTED]>. > > Index: ltmain.in > === > RCS file: /cvsroot/libtool/libtool/Attic/ltmain.in,v > retrieving revision 1.334.2.127 > diff -u -r1.334.2.127 ltmain.in > --- ltmain.in 18 May 2006 06:52:54 - 1.334.2.127 > +++ ltmain.in 18 May 2006 16:30:29 - > @@ -482,11 +482,13 @@ > ;; > >--version) > -$echo "$PROGRAM (GNU $PACKAGE) $VERSION$TIMESTAMP" > -$echo > -$echo "Copyright (C) 2006 Free Software Foundation, Inc." > -$echo "This is free software; see the source for copying conditions. > There is NO" > -$echo "warranty; not even for MERCHANTABILITY or FITNESS FOR A > PARTICULAR PURPOSE." > +echo "\ > + > +$PROGRAM (GNU $PACKAGE) $VERSION$TIMESTAMP > + > +Copyright (C) 2006 Free Software Foundation, Inc. > +This is free software; see the source for copying conditions. There is NO > +warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE." > exit $? > ;; > > > --behdad http://behdad.org/ "Commandment Three says Do Not Kill, Amendment Two says Blood Will Spill" -- Dan Bern, "New American Language"
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
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 14:36 -0500, Bob Friesenhahn wrote: > > I assume that it works. Of course it does not work with some > IDE-based debuggers. It can be made to work with programs like 'ddd' > and 'emacs' which talk to a traditional debugger over a pseudo-tty or > pipe. autotool-aware IDEs like Anjuta can do: $(top_builddir)/libtool --mode=execute echo binary-name to get to the actual binary, then run it. -- 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 Fri, 2008-04-18 at 23:16 +0300, Roumen Petrov wrote: > For my users, from make and some wrapper script, I setup environment, > run some servers (as example openldap with preloaded data) run > un-installed programs so my users see that things work before to > install. Ok, then this feature will be added, you won't use it, and everyone's users will be happy. > 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 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
