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
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
Problems with libtool 2.2.2 and /bin/sh pointing to dash
Hi,
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.
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?
Regards,
Richard
--- libtool-bash2008-04-21 17:57:40.0 +0100
+++ libtool-dash2008-04-21 23:36:38.0 +0100
@@ -1,4 +1,4 @@
-#! /bin/sh
+#! /bin/bash
# arm-poky-linux-gnueabi-libtool - Provide generalized library-building
support services.
# Generated automatically by config.status (gtk+) 2.12.7
@@ -107,10 +107,10 @@
lt_unset=unset
# turn spaces into newlines.
-SP2NL="tr \\040 \\012"
+SP2NL="tr \040 \012"
# turn newlines into spaces.
-NL2SP="tr \\015\\012 \\040\\040"
+NL2SP="tr \015\012 \040\040"
# How to create reloadable object files.
reload_flag=" -r"
@@ -141,22 +141,22 @@
LTCFLAGS="-fexpensive-optimizations -fomit-frame-pointer -frename-registers
-O2 -Wall"
# Take the output of nm and produce a listing of raw symbols and C names.
-global_symbol_pipe="sed -n -e 's/^.*[ ]\\([ABCDGIRSTW][ABCDGIRSTW]*\\)[
][ ]*\\([_A-Za-z][_A-Za-z0-9]*\\)\$/\\1 \\2 \\2/p'"
+global_symbol_pipe="sed -n -e 's/^.*[ ]\\([ABCDGIRSTW][ABCDGIRSTW]*\\)[
][ ]*\\([_A-Za-z][_A-Za-z0-9]*\\)\$/ /p'"
# Transform the output of nm in a proper C declaration.
-global_symbol_to_cdecl="sed -n -e 's/^T .* \\(.*\\)\$/extern int \\1();/p' -e
's/^[ABCDGIRSTW]* .* \\(.*\\)\$/extern char \\1;/p'"
+global_symbol_to_cdecl="sed -n -e 's/^T .* \\(.*\\)\$/extern int ();/p' -e
's/^[ABCDGIRSTW]* .* \\(.*\\)\$/extern char ;/p'"
# Transform the output of nm in a C name address pair.
-global_symbol_to_c_name_address="sed -n -e 's/^: \\([^ ]*\\) \$/
{\\\"\\1\\\", (void *) 0},/p' -e 's/^[ABCDGIRSTW]* \\([^ ]*\\) \\([^ ]*\\)\$/
{\"\\2\", (void *) \\&\\2},/p'"
+global_symbol_to_c_name_address="sed -n -e 's/^: \\([^ ]*\\) \$/ {\\\"\\\",
(void *) 0},/p' -e 's/^[ABCDGIRSTW]* \\([^ ]*\\) \\([^ ]*\\)\$/ {\"\", (void
*) \\&},/p'"
# Transform the output of nm in a C name address pair when lib prefix is
needed.
-global_symbol_to_c_name_address_lib_prefix="sed -n -e 's/^: \\([^ ]*\\) \$/
{\\\"\\1\\\", (void *) 0},/p' -e 's/^[ABCDGIRSTW]* \\([^ ]*\\) \\(lib[^
]*\\)\$/ {\"\\2\", (void *) \\&\\2},/p' -e 's/^[ABCDGIRSTW]* \\([^ ]*\\) \\([^
]*\\)\$/ {\"lib\\2\", (void *) \\&\\2},/p'"
+global_symbol_to_c_name_address_lib_prefix="sed -n -e 's/^: \\([^ ]*\\) \$/
{\\\"\\\", (void *) 0},/p' -e 's/^[ABCDGIRSTW]* \\([^ ]*\\) \\(lib[^ ]*\\)\$/
{\"\", (void *) \\&},/p' -e 's/^[ABCDGIRSTW]* \\([^ ]*\\) \\([^ ]*\\)\$/
{\"lib\", (void *) \\&},/p'"
# The name of the directory that contains temporary libtool files.
objdir=.libs
# Shell to use when invoking shell scripts.
-SHELL="/bin/sh"
+SHELL="/bin/bash"
# An echo program that does not interpret backslashes.
ECHO="echo"
@@ -301,7 +301,7 @@
# Commands used to build a shared archive.
archive_cmds="\$CC -shared \$libobjs \$deplibs \$compiler_flags \${wl}-soname
\$wl\$soname -o \$lib"
archive_expsym_cmds="echo \\\"{ global:\\\" > \$output_objdir/\$libname.ver~
- cat \$export_symbols | sed -e \\\"s/(.*)/1;/\\\" >>
\$output_objdir/\$libname.ver~
+ cat \$export_symbols | sed -e \\\"s/(.*)/;/\\\" >>
\$output_objdir/\$libname.ver~
echo \\\"local: *; };\\\" >> \$output_objdir/\$libname.ver~
\$CC -shared \$libobjs \$deplibs \$compiler_flags \${wl}-soname
\$wl\$soname \${wl}-version-script \${wl}\$output_objdir/\$libname.ver -o \$lib"
___
http://lists.gnu.org/mailman/listinfo/libtool
Re: silencing libtool and automake
On Mon, 21 Apr 2008, Joachim Worringen wrote: We use libtool/automake/configure for our builds, but autotools-builds are pretty verbose, which is not always desired. I checked that by adding the "@" silencer in the Makefiles and calling libtool with "--silent" we get what we want. Using current FSF released software and adding --silent to the libtool options, I obtain complete silence (other than compiler warnings/errors) via 'make -s'. Based on the above, it seems likely that you are not using the current releases of the software. 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: move to git
"Dan Nicholson" <[EMAIL PROTECTED]> wrote: > On Sat, Apr 19, 2008 at 2:53 AM, Jim Meyering <[EMAIL PROTECTED]> wrote: >> >> Ralf Wildenhues <[EMAIL PROTECTED]> wrote: >> >> > I don't quite understand what happened. With the repo converted from >> > CVS, the tag SHAs were all different, but they already pointed to the >> > same tree object. After the filter-branch rewrite, they now all have >> > the same SHA. I suspect the bug happens earlier. Jim, can you take >> > a look? >> >> Hi Ralf, >> I'm beginning to think that our time might be better spent >> investigating an alternate conversion method: cvs2git. >> Unfortunately, I might not have time for that right away. > > Just a thought, but nearly all of the freedesktop.org projects > (including all of X) were converted using Keith Packard's parsecvs > tool. I haven't heard of anyone complaining of incorrect history. > > http://gitweb.freedesktop.org/?p=users/keithp/parsecvs.git;a=summary That's exactly what I used. Note however, that parsecvs is not robust. With a slightly unusual ,v file, it's easy to make it segfault. I've encountered at least 3 repositories that it is unable to convert. I think cvs2git will be better. BTW, I suspect that parsecvs is unmaintained, since my recent patch to make it work with newer versions of git has evoked no reply, and the patch has not appeared in the repository. ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: move to git
On Sat, Apr 19, 2008 at 2:53 AM, Jim Meyering <[EMAIL PROTECTED]> wrote: > > Ralf Wildenhues <[EMAIL PROTECTED]> wrote: > > > I don't quite understand what happened. With the repo converted from > > CVS, the tag SHAs were all different, but they already pointed to the > > same tree object. After the filter-branch rewrite, they now all have > > the same SHA. I suspect the bug happens earlier. Jim, can you take > > a look? > > Hi Ralf, > I'm beginning to think that our time might be better spent > investigating an alternate conversion method: cvs2git. > Unfortunately, I might not have time for that right away. Just a thought, but nearly all of the freedesktop.org projects (including all of X) were converted using Keith Packard's parsecvs tool. I haven't heard of anyone complaining of incorrect history. http://gitweb.freedesktop.org/?p=users/keithp/parsecvs.git;a=summary -- Dan ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: silencing libtool and automake
Hello Joachim, * Joachim Worringen wrote on Mon, Apr 21, 2008 at 11:16:05AM CEST: > > We use libtool/automake/configure for our builds, but autotools-builds > are pretty verbose, which is not always desired. I checked that by > adding the "@" silencer in the Makefiles and calling libtool with > "--silent" we get what we want. make -s LIBTOOLFLAGS=--silent > How can I create such Makefiles via autoreconf && configure? Put this in configure.ac: AC_SUBST([AM_LIBTOOLFLAGS], [--silent]) Then you need only 'make -s'. Choosing additional '@' is currently not supported by Automake, though there exists at least one third-party patch to achieve similar functionality. Cheers, Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool
silencing libtool and automake
We use libtool/automake/configure for our builds, but autotools-builds are pretty verbose, which is not always desired. I checked that by adding the "@" silencer in the Makefiles and calling libtool with "--silent" we get what we want. How can I create such Makefiles via autoreconf && configure? - autoreconf honors LIBTOOLIZE env setting, but not LIBTOOL itself - slightly off-topic: how can I tell automake to add the @-silencer? Preferably, this would be a controllable setting by using an env-variable. thanks, Joachim -- Joachim Worringen, Software Architect, Dolphin Interconnect Solutions phone ++49/(0)228/324 08 17 - http://www.dolphinics.com ___ http://lists.gnu.org/mailman/listinfo/libtool
