Re: Problems with libtool 2.2.2 and /bin/sh pointing to dash
Ralf, Ralf Wildenhues Ralf.Wildenhues at gmx.de writes: I've had reports of Poky breaking with libtool 2.2.2 and have isolated this to people using dash as their /bin/sh provider (Poky runs the configure script with /bin/sh). When used in this combination, the global_symbol_pipe expression becomes corrupted in the generated libtool file amongst other things and I've included a diff of the corruption below. I noticed this with gtk+ 2.12.7. That typically means that the configure script is run with a different shell than the libtool script. Beware: the configure script might restart itself under a different shell, exporting CONFIG_SHELL. I can successfully configure and use libtool with CONFIG_SHELL=/bin/dash /bin/dash ./configure -C make but for example if you configure with /bin/sh pointing to bash, then later switch the /bin/sh symlink to dash, you're giving libtool a hard time. If that wasn't the case, then please show how to reproduce this situation. For that, your $PATH, the /bin/sh symlink, your $SHELL, and eventual $CONFIG_SHELL values are important to see, as well as how exactly you configure and build the package. I can replicate this on my Debian Sid (up to date as of this morning) laptop, with the following configuration. /bin/sh - /bin/dash SHELL=/bin/bash PATH=/home/ross/BUILD/bin:/home/ross/bin:/usr/local/bin:/usr/bin:/bin:/usr/games Using libtool 2.2.2-1 from Debian Experimental The GTK+ autogen script demands libtool 1.5/automake 1.7, but autoreconf works. In a clean checkout of gtk+, I ran gtkdocize, autoreconf, ./configure (noting the failures due to ./libtool being missing) and then make. Then I got this: /usr/bin/ld:.libs/libgdk_pixbuf-2.0.ver:2: ignoring invalid character `\001' in script /usr/bin/ld:.libs/libgdk_pixbuf-2.0.ver:2: syntax error in VERSION script ./libtool starts with #!/bin/bash, and echoing CONFIG_SHELL at the end of configure reveals that it is set to /bin/bash aswell. Interestingly if I then re-run configure the build works fine... Ross ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Problems with libtool 2.2.2 and /bin/sh pointing to dash
Gary V. Vaughan gary at gnu.org writes: If you are upgrading projects that used this idiom to libtool 2.0 or newer, you should replace those calls with direct references to the equivalent Autoconf shell variables that are set by the configure time tests before being passed to `config.status' for inclusion in the generated libtool script. At the moment, GTK+ does this in configure: deplibs_check_method=`(./libtool --config; echo 'eval echo $deplibs_check_method') | sh` if test x$deplibs_check_method '!=' xpass_all || test x$enable_static = xyes ; then ... Am I right in thinking that the first line can be removed, as initialising libtool will have created and set the variable deplibs_check_method? Was this behaviour present in libtool 1.5? Cheers Ross ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Problems with libtool 2.2.2 and /bin/sh pointing to dash
Hi Ross, On 22 Apr 2008, at 05:39, Ross Burton wrote: Gary V. Vaughan gary at gnu.org writes: If you are upgrading projects that used this idiom to libtool 2.0 or newer, you should replace those calls with direct references to the equivalent Autoconf shell variables that are set by the configure time tests before being passed to `config.status' for inclusion in the generated libtool script. At the moment, GTK+ does this in configure: deplibs_check_method=`(./libtool --config; echo 'eval echo $deplibs_check_method') | sh` if test x$deplibs_check_method '!=' xpass_all || test x $enable_static = xyes ; then ... Am I right in thinking that the first line can be removed, as initialising libtool will have created and set the variable deplibs_check_method? Yes, exactly. Running the expansion of LT_INIT (or AC_PROG_LIBTOOL if you didn't run autoupdate yet) in configure includes a call to _LT_CHECK_MAGIC_METHOD, which does indeed set deplibs_check_method at configure time. Was this behaviour present in libtool 1.5? No it wasn't, because libtool was generated in a two stage process which required calling ./libtool --config directly. Cheers, Gary -- ())_. Email me: [EMAIL PROTECTED] ( '/ Read my blog: http://blog.azazil.net / )= ...and my book: http://sources.redhat.com/autobook `(_~)_ PGP.sig Description: This is a digitally signed message part ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Problems with libtool 2.2.2 and /bin/sh pointing to dash
On Tue, 22 Apr 2008, Ross Burton wrote: At the moment, GTK+ does this in configure: deplibs_check_method=`(./libtool --config; echo 'eval echo $deplibs_check_method') | sh` if test x$deplibs_check_method '!=' xpass_all || test x$enable_static = xyes ; then ... Am I right in thinking that the first line can be removed, as initialising libtool will have created and set the variable deplibs_check_method? Was this behaviour present in libtool 1.5? I have not checked if this variable is identical for libtool 1.5, but yes, you can access the libtool configuration via existing variables rather than needing to consult an external libtool script. That is how I am doing it. Bob == Bob Friesenhahn [EMAIL PROTECTED], http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Problems with libtool 2.2.2 and /bin/sh pointing to dash
On Tue, 22 Apr 2008, Ralf Wildenhues wrote: I can successfully configure and use libtool with CONFIG_SHELL=/bin/dash /bin/dash ./configure -C make Same here. The total success was astonishing to me since my copy of 'dash' is a rough port to Solaris 10. Dash is faster than bash so there is advantage to using it. Bob == Bob Friesenhahn [EMAIL PROTECTED], http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Problems with libtool 2.2.2 and /bin/sh pointing to dash
Gary V. Vaughan wrote: Was this behaviour present in libtool 1.5? No it wasn't, because libtool was generated in a two stage process which required calling ./libtool --config directly. Hi Gary, I think you may be wrong. You can check the value of libtool variables in configure for libtool 1.4. In 1.3 and earlier there was a separate ltconfig script which was run, so those variables were not available. With 1.4 libtool's checks became part of the configure script itself, so anything after AC_PROG_LIBTOOL can check the variables values. With 2.x, of course, it is preferred to use the vars directly, creating libtool just to check these is expensive and pointless. Peter -- Peter O'Gorman http://pogma.com ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Problems with libtool 2.2.2 and /bin/sh pointing to dash
On Tue, 2008-04-22 at 10:35 -0400, Gary V. Vaughan wrote:
Yes, exactly. Running the expansion of LT_INIT (or AC_PROG_LIBTOOL if
you didn't run autoupdate yet) in configure includes a call to
_LT_CHECK_MAGIC_METHOD, which does indeed set deplibs_check_method at
configure time.
Right.
Was this behaviour present in libtool 1.5?
No it wasn't, because libtool was generated in a two stage process
which required
calling ./libtool --config directly.
Interestingly I tried it with 1.5 and it did work, but if its not meant
to be exported then I won't use it.
GTK+ also does this:
# pkg-config --libs gmodule includes the export_dynamic flag,
# but this flag is only meaningful for executables. For libraries
# the effect is undefined; what it causes on Linux is that the
# export list from -export-symbols-regex is ignored and everything
# is exported
#
# We are using gmodule-no-export now, but I'm leaving the stripping
# code in place for now, since pango and atk still require gmodule.
export SED
export_dynamic=`(./libtool --config; echo eval echo
\\$export_dynamic_flag_spec) | sh`
if test -n $export_dynamic; then
GDK_PIXBUF_DEP_LIBS=`echo $GDK_PIXBUF_DEP_LIBS | sed -e s/$export_dynamic//`
GDK_PIXBUF_XLIB_DEP_LIBS=`echo $GDK_PIXBUF_XLIB_DEP_LIBS | sed -e
s/$export_dynamic//`
GDK_DEP_LIBS=`echo $GDK_DEP_LIBS | sed -e s/$export_dynamic//`
GTK_DEP_LIBS=`echo $GTK_DEP_LIBS | sed -e s/$export_dynamic//`
fi
I tried just using $export_dynamic_flag_spec in the configure.ac
directly, but that refers to ${wl} which isn't defined by libtool inside
the configure run. :/ Any cunning plans for how this could work with
libtool 2.2?
Ross
--
Ross Burton mail: [EMAIL PROTECTED]
jabber: [EMAIL PROTECTED]
www: http://www.burtonini.com./
PGP Fingerprint: 1A21 F5B0 D8D0 CFE3 81D4 E25A 2D09 E447 D0B4 33DF
signature.asc
Description: This is a digitally signed message part
___
http://lists.gnu.org/mailman/listinfo/libtool
Re: Problems with libtool 2.2.2 and /bin/sh pointing to dash
Hello, * Gary V. Vaughan wrote on Tue, Apr 22, 2008 at 04:35:56PM CEST: On 22 Apr 2008, at 05:39, Ross Burton wrote: Was this behaviour present in libtool 1.5? No it wasn't, because libtool was generated in a two stage process which required calling ./libtool --config directly. Charles posted a patch that would make AC_PROG_LIBTOOL do the equivalent of LT_INIT LT_OUTPUT We could consider doing that, to avoid these issues. Of course alongside an AU_DEFUN that recommends at autoupdate time that LT_OUTPUT be removed if packages don't need ./libtool inside configure. Yes, it would be slower. Thoughts on this? Cheers, Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Problems with libtool 2.2.2 and /bin/sh pointing to dash
* Ross Burton wrote on Tue, Apr 22, 2008 at 11:11:25AM CEST: I can replicate this on my Debian Sid (up to date as of this morning) laptop, with the following configuration. /bin/sh - /bin/dash SHELL=/bin/bash PATH=/home/ross/BUILD/bin:/home/ross/bin:/usr/local/bin:/usr/bin:/bin:/usr/games Using libtool 2.2.2-1 from Debian Experimental I'm having a deja vu feeling, there was a similar Debian bug a while ago which IIRC I could not reproduce either. FWIW, I can *not* replicate this with building the Libtool package; I have set /bin/sh - dash, SHELL=/bin/bash, and some Debian stable/testing mix. Which autoconf version do you use, and which dash and bash versions do you have installed? Can you put set -x as second line in the configure script, and run ./configure and post the output (either abridged, or bzip2'ed)? The shell selections parts are interesting (there may be several of them). /usr/bin/ld:.libs/libgdk_pixbuf-2.0.ver:2: ignoring invalid character `\001' in script /usr/bin/ld:.libs/libgdk_pixbuf-2.0.ver:2: syntax error in VERSION script ./libtool starts with #!/bin/bash, and echoing CONFIG_SHELL at the end of configure reveals that it is set to /bin/bash aswell. Interestingly if I then re-run configure the build works fine... Rerun as ./configure or as ./config.status --recheck ? Because the latter will ensure configure is launched using $CONFIG_SHELL, and with CONFIG_SHELL in the environment. Thanks, Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Problems with libtool 2.2.2 and /bin/sh pointing to dash
On Tue, Apr 22, 2008 at 08:00:08PM +0200, Ralf Wildenhues wrote: * Ross Burton wrote on Tue, Apr 22, 2008 at 11:11:25AM CEST: I can replicate this on my Debian Sid (up to date as of this morning) laptop, with the following configuration. /bin/sh - /bin/dash SHELL=/bin/bash PATH=/home/ross/BUILD/bin:/home/ross/bin:/usr/local/bin:/usr/bin:/bin:/usr/games Using libtool 2.2.2-1 from Debian Experimental I'm having a deja vu feeling, there was a similar Debian bug a while ago which IIRC I could not reproduce either. You could reproduce it, and you supplied a patch for configure.ac. See http://bugs.debia.org/447022 Kurt ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Problems with libtool 2.2.2 and /bin/sh pointing to dash
* Kurt Roeckx wrote on Tue, Apr 22, 2008 at 09:57:38PM CEST: On Tue, Apr 22, 2008 at 08:00:08PM +0200, Ralf Wildenhues wrote: * Ross Burton wrote on Tue, Apr 22, 2008 at 11:11:25AM CEST: I can replicate this on my Debian Sid (up to date as of this morning) laptop, with the following configuration. /bin/sh - /bin/dash SHELL=/bin/bash PATH=/home/ross/BUILD/bin:/home/ross/bin:/usr/local/bin:/usr/bin:/bin:/usr/games Using libtool 2.2.2-1 from Debian Experimental I'm having a deja vu feeling, there was a similar Debian bug a while ago which IIRC I could not reproduce either. You could reproduce it, and you supplied a patch for configure.ac. See http://bugs.debia.org/447022 Thanks! That's the bug I was thinking of, but apparently I need to get some better medication for my memory, messing up the details. Anyway, the issue here seems slightly different still. How do I download the exact source that you, Ross, are building, including build dependencies (assuming my apt preferences are not identical to yours)? Thanks, Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Problems with libtool 2.2.2 and /bin/sh pointing to dash
Hallo Ralf, On 22 Apr 2008, at 13:44, Ralf Wildenhues wrote: * Gary V. Vaughan wrote on Tue, Apr 22, 2008 at 04:35:56PM CEST: On 22 Apr 2008, at 05:39, Ross Burton wrote: Was this behaviour present in libtool 1.5? No it wasn't, because libtool was generated in a two stage process which required calling ./libtool --config directly. Charles posted a patch that would make AC_PROG_LIBTOOL do the equivalent of LT_INIT LT_OUTPUT We could consider doing that, to avoid these issues. Of course alongside an AU_DEFUN that recommends at autoupdate time that LT_OUTPUT be removed if packages don't need ./libtool inside configure. Yes, it would be slower. Much slower. And with more file droppings to feed and care for. Thoughts on this? -1 If someone really wants to upgrade from 1.5.x to 2.x, then I'd rather send them a canned response and paste something from the manual to the list until google can find the answer without effort, than I would deal with asking people to jump through more hoops in order to have libtool not be so slow. Cheers, Gary -- ())_. Email me: [EMAIL PROTECTED] ( '/ Read my blog: http://blog.azazil.net / )= ...and my book: http://sources.redhat.com/autobook `(_~)_ PGP.sig Description: This is a digitally signed message part ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Problems with libtool 2.2.2 and /bin/sh pointing to dash
Hi Richard, On 21 Apr 2008, at 19:07, Richard Purdie wrote: gtk+ also has the issues that it tries to run libtool before its been generated and I've had to patch this to run a previously generated version of libtool poky has around to solve cases like this. I'm not sure if there is a neater way to address that problem? Starting with libtool 2.0, the multipass generation of the libtool script has been consolidated into a single `config.status' pass, which happens after all the code in `configure.ac' has completed. The implication of this is that the libtool script does not exist during execution of code from `configure.ac', and so obviously it cannot be called for `--config' details anymore. If you are upgrading projects that used this idiom to libtool 2.0 or newer, you should replace those calls with direct references to the equivalent Autoconf shell variables that are set by the configure time tests before being passed to `config.status' for inclusion in the generated libtool script. -- Macro: LT_OUTPUT By default, the configured `libtool' script is generated by the call to `AC_OUTPUT' command, and there is rarely any need to use `libtool' from `configure'. However, sometimes it is necessary to run configure time compile and link tests using `libtool'. You can add `LT_OUTPUT' to your `configure.ac' any time after `LT_INIT' and any `LT_LANG' calls; that done, `libtool' will be created by a specially generated `config.lt' file, and available for use in later tests. Also, when `LT_OUTPUT' is used, for backwards compatibility with Automake regeneration rules, `config.status' will call `config.lt' to regenerate `libtool', rather than generating the file itself. Cheers, Gary -- ())_. Email me: [EMAIL PROTECTED] ( '/ Read my blog: http://blog.azazil.net / )= ...and my book: http://sources.redhat.com/autobook `(_~)_ PGP.sig Description: This is a digitally signed message part ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Problems with libtool 2.2.2 and /bin/sh pointing to dash
Hello Richard, * Richard Purdie wrote on Tue, Apr 22, 2008 at 01:07:48AM CEST: I've had reports of Poky breaking with libtool 2.2.2 and have isolated this to people using dash as their /bin/sh provider (Poky runs the configure script with /bin/sh). When used in this combination, the global_symbol_pipe expression becomes corrupted in the generated libtool file amongst other things and I've included a diff of the corruption below. I noticed this with gtk+ 2.12.7. That typically means that the configure script is run with a different shell than the libtool script. Beware: the configure script might restart itself under a different shell, exporting CONFIG_SHELL. I can successfully configure and use libtool with CONFIG_SHELL=/bin/dash /bin/dash ./configure -C make but for example if you configure with /bin/sh pointing to bash, then later switch the /bin/sh symlink to dash, you're giving libtool a hard time. If that wasn't the case, then please show how to reproduce this situation. For that, your $PATH, the /bin/sh symlink, your $SHELL, and eventual $CONFIG_SHELL values are important to see, as well as how exactly you configure and build the package. I haven't checked whether gtk+ 2.12.7 munges with the shell setting in its configure script. gtk+ also has the issues that it tries to run libtool before its been generated and I've had to patch this to run a previously generated version of libtool poky has around to solve cases like this. I'm not sure if there is a neater way to address that problem? Gary has already addressed this part. Cheers, Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool
