Re: Feature request: setting env vars for binary wrappers
Behdad Esfahbod wrote:
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.
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.
The whole idea is libtool overkill.
Fair enough. Just suggest an alternative please, instead of acting as
if the problem does not exist.
Roumen
Re: Feature request: setting env vars for binary wrappers
* Roumen Petrov wrote on Fri, Apr 18, 2008 at 08:32:23PM CEST: > > 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. OK, you bring an argument of the sort "this can also be done in a different way". But that's not a conclusive argument against the patch. The patch (once it's forward-ported) allows Behdad to achieve what he wants - very elegantly - with little work - and with relatively minor overhead in libtool. In what way do you think we are making Libtool worse with the patch? Thanks, Ralf
Re: Feature request: setting env vars for binary wrappers
Bob Friesenhahn wrote: On Fri, 18 Apr 2008, Roumen Petrov wrote: And if application don't read environment, next request is libtool wrapper script to pass arguments to application command line. The whole idea is libtool overkill. This statement is a little "over the top". Why are you so vehemently against extending libtool's wrapper for this? Because I think that modules/application/packages/etc should do their best work. I don't think that a particular package hast o support partially or to implement very basic functionality. The est example is microsoft software where application is feature reach but 99.9% of features are with partially or basic functionality. 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. Certainly it is a bit more work for the libtool project (particularly adding a wrapper for static binaries) but I can't think of any technical reason not to support it via environment variables only, as we already do with some other environment variables. It would help if an interested party were to submit a patch, along with signing the necessary paperwork with the FSF so it can be accepted. We should add it to the TODO list for libtool 2.3. Bob Roumen
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
* Roumen Petrov wrote on Fri, Apr 18, 2008 at 08:53:12PM CEST: > > 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. With all due respect, but I think you haven't understood the problem case Behdad is trying to solve. It's very simple: packages have a test suite, or developers merely want to run uninstalled programs, before they install them (in a new place, or overwriting earlier versions of the programs and libraries). In order to ensure the uninstalled program uses only other uninstalled stuff, one typically sets some variables, for example $PATH, $LD_LIBRARY_PATH (or equivalents on other systems), tst_aclocaldir (this is specific to the Libtool package itself), ... The LD_LIBRARY_PATH thing (but portable) is already handled by libtool. Why should it not also handle other variables, given that it would be *very easy to do*? Thanks, Ralf
Re: Feature request: setting env vars for binary wrappers
On Fri, 18 Apr 2008, Roumen Petrov wrote: Because I think that modules/application/packages/etc should do their best work. I don't think that a particular package hast o support partially or to implement very basic functionality. The est example is microsoft software where application is feature reach but 99.9% of features are with partially or basic functionality. The difference between libtool and Microsoft software is that libtool is developed by volunteers and Microsoft software is developed by well-paid employees of a many billion-dollar company. As a result, every feature in libtool is developed because someone wants it badly enough that they are willing to develop it themselves. Libtool is not over-featured at this time. As Ralf says, we are already passing environment variables to the wrapper so it is no big deal to pass more. The only substantial change is for static builds which currently don't have a wrapper. The static build is a more significant concern since static builds are often used for debugging purposes and if we hide the static binary in a subdirectory, it may be more difficult to debug. We need to make sure that it is both possible to obtain the necessary run-time environment, and to run the debugger on the correct binary. Proposals for the cleanest way to do that are appreciated. Bob == Bob Friesenhahn [EMAIL PROTECTED], http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Re: Feature request: setting env vars for binary wrappers
* Bob Friesenhahn wrote on Fri, Apr 18, 2008 at 09:15:55PM CEST: > The only substantial change is for static builds which currently > don't have a wrapper. Yes. > The static build is a more significant concern since static builds are > often used for debugging purposes and if we hide the static binary in a > subdirectory, it may be more difficult to debug. Good point, thanks. > We need to make sure > that it is both possible to obtain the necessary run-time environment, > and to run the debugger on the correct binary. Proposals for the > cleanest way to do that are appreciated. Well, did this cease to work (except for the bug which was fixed in 2.2.2)? ./libtool --mode=execute gdb ./prog --args ... Cheers, Ralf
Re: Feature request: setting env vars for binary wrappers
Behdad Esfahbod wrote: 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? I perfectly know this problem. Un-installed application cannot be run without to prepared suitable environment. About six years I maintain X.509 certificate support in OpenSSH and I perfectly know that user cannot go in build-dir and just to run secure shell daemon/client. Roumen
Re: Feature request: setting env vars for binary wrappers
On Fri, 18 Apr 2008, Ralf Wildenhues wrote: We need to make sure that it is both possible to obtain the necessary run-time environment, and to run the debugger on the correct binary. Proposals for the cleanest way to do that are appreciated. Well, did this cease to work (except for the bug which was fixed in 2.2.2)? ./libtool --mode=execute gdb ./prog --args ... 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. Bob == Bob Friesenhahn [EMAIL PROTECTED], http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Re: Feature request: setting env vars for binary wrappers
Ralf Wildenhues wrote: * Bob Friesenhahn wrote on Fri, Apr 18, 2008 at 09:15:55PM CEST: The only substantial change is for static builds which currently don't have a wrapper. Yes. The static build is a more significant concern since static builds are often used for debugging purposes and if we hide the static binary in a subdirectory, it may be more difficult to debug. Good point, thanks. We need to make sure that it is both possible to obtain the necessary run-time environment, and to run the debugger on the correct binary. Proposals for the cleanest way to do that are appreciated. Well, did this cease to work (except for the bug which was fixed in 2.2.2)? ./libtool --mode=execute gdb ./prog --args ... I think that existing "--mode=execute" is enough. Roumen
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
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 Ohh no 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. 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. Roumen
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: expr complaint on FreeBSD for MinGW cross
* Ralf Wildenhues wrote on Wed, Apr 16, 2008 at 09:53:22PM CEST: > * Bob Friesenhahn wrote on Wed, Apr 16, 2008 at 09:26:49PM CEST: > > With latest CVS HEAD and performing a cross-build to MinGW using FreeBSD > > as the build host, I am seeing an 'illegal option' error message from > > FreeBSD's expr. The only option that FreeBSD's expr supports is -e so I > > must assume that some part of the expression is causing a problem. > > Confirmed. Will fix. > > > expr: > > illegal option -- l > > usage: expr [-e] expression OK to apply? I was first going to rewrite this to use func_stripname, but then I couldn't find any instance where we actually use $name later. So I figured this can all go. I'd appreciate somebody looking over this, thanks. I also checked other instances of expr for this bug. Cheers, Ralf 2008-04-18 Ralf Wildenhues <[EMAIL PROTECTED]> * libltdl/config/ltmain.m4sh (func_mode_link) : Fix expr portability issues, noted on FreeBSD. While at it, simplify and avoid forking. Report by Bob Friesenhahn. diff --git a/libltdl/config/ltmain.m4sh b/libltdl/config/ltmain.m4sh index 2802254..562bca2 100644 --- a/libltdl/config/ltmain.m4sh +++ b/libltdl/config/ltmain.m4sh @@ -5562,9 +5562,8 @@ EOF if $LTCC $LTCFLAGS -o conftest conftest.c $deplibs; then ldd_output=`ldd conftest` for i in $deplibs; do - name=`expr $i : '-l\(.*\)'` - # If $name is empty we are operating on a -L argument. - if test "$name" != "" && test "$name" != "0"; then + case $i in + -l*) if test "X$allow_libtool_libs_with_static_runtimes" = "Xyes" ; then case " $predeps $postdeps " in *" $i "*) @@ -5591,17 +5590,18 @@ EOF $ECHO "*** its dynamic dependency list that programs get resolved with at runtime." fi fi - else + ;; + *) newdeplibs="$newdeplibs $i" - fi + ;; + esac done else # Error occurred in the first compile. Let's try to salvage # the situation: Compile a separate program for each library. for i in $deplibs; do - name=`expr $i : '-l\(.*\)'` - # If $name is empty we are operating on a -L argument. - if test "$name" != "" && test "$name" != "0"; then + case $i in + -l*) $opt_dry_run || $RM conftest if $LTCC $LTCFLAGS -o conftest conftest.c $i; then ldd_output=`ldd conftest` @@ -5639,9 +5639,11 @@ EOF $ECHO "*** library that it depends on before this library will be fully" $ECHO "*** functional. Installing it before continuing would be even better." fi - else + ;; + *) newdeplibs="$newdeplibs $i" - fi + ;; + esac done fi ;; @@ -5649,9 +5651,8 @@ EOF set dummy $deplibs_check_method; shift file_magic_regex=`expr "$deplibs_check_method" : "$1 \(.*\)"` for a_deplib in $deplibs; do - name=`expr $a_deplib : '-l\(.*\)'` - # If $name is empty we are operating on a -L argument. - if test "$name" != "" && test "$name" != "0"; then + case $a_deplib in + -l*) if test "X$allow_libtool_libs_with_static_runtimes" = "Xyes" ; then case " $predeps $postdeps " in *" $a_deplib "*) @@ -5708,19 +5709,20 @@ EOF $ECHO "*** using a file magic. Last file checked: $potlib" fi fi - else + ;; + *) # Add a -L argument. newdeplibs="$newdeplibs $a_deplib" - fi + ;; + esac done # Gone through all deplibs. ;; match_pattern*) set dummy $deplibs_check_method; shift match_pattern_regex=`expr "$deplibs_check_method" : "$1 \(.*\)"` for a_deplib in $deplibs; do - name=`expr $a_deplib : '-l\(.*\)'` - # If $name is empty we are operating on a -L argument. - if test -n "$name" && test "$name" != "0"; then + case $a_deplib in + -l*) if test "X$allow_libtool_libs_with_static_runtimes" = "Xyes" ; then case " $predeps $postdeps " in *" $a_deplib "*) @@ -5759,10 +5761,12 @@ EOF $ECHO "*** using a regex pattern. Last file checked: $potlib" fi fi - else + ;; + *) # Add a -L argument. newdeplibs="$newdeplibs $a_deplib" - fi + ;; + esac done # Gone
Re: No need for object file removal before compilation
* Bob Friesenhahn wrote on Sat, Apr 12, 2008 at 05:51:28PM CEST: > > The patch looks ok to me. We shall see about the actual performance > improvement. Thanks, applied. Cheers, Ralf >> 2008-04-12 Ralf Wildenhues <[EMAIL PROTECTED]> >> >> * libltdl/config/ltmain.m4sh (func_mode_compile): Avoid >> redundant removal of old output files before compilation. >> Do not remove $obj until we have successfully grabbed the >> lockfile (in case the compiler doesn't grok `-c -o'), because >> it might be identical to $output_obj. >> At the end of the function, before we remove the lockfile, >> update $removelist so that if the trap hits after the lockfile >> has been removed, we do not accidentally remove $output_obj that >> does not belong to us. >> (func_write_libtool_object): Use $MV instead of mv.
Re: expr complaint on FreeBSD for MinGW cross
[ dropping bug-libtool ] * Ralf Wildenhues wrote on Fri, Apr 18, 2008 at 11:40:29PM CEST: > > OK to apply? I was first going to rewrite this to use func_stripname, > but then I couldn't find any instance where we actually use $name later. > So I figured this can all go. I'd appreciate somebody looking over > this, thanks. Ouch. ETOOLATE. Of course $name is used, in libname_spec for example. Please ignore this, I'll post an updated patch.
