http://permalink.gmane.org/gmane.comp.gnu.libtool.bugs hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://permalink.gmane.org/gmane.comp.gnu.libtool.bugs/8169 <pre>I am using libtool master (a4629ebf) configured with "--with-sysroot=/tmp/root". My build toolchain (gcc, binutils) has been configured with the same sysroot. I am trying to cross-compile linux-pam. All dependencies have been configured and built with --prefix=/usr, but ultimately been moved after installing to /tmp/root. Building fails with libtool: warning: library '/tmp/root/lib64/libpam.la' was moved. libtool: warning: library '/tmp/root/lib64/libpam_misc.la' was moved. libtool: error: cannot find the library '/lib64/libpam.la' or unhandled argument '/lib64/libpam.la' /tmp/root/lib64/libpam.la includes # Directory that this library needs to be installed in: libdir='/lib64' libtool should prepend its sysroot to libdir. </pre> markbrounce< at >lavabit.com 2013-05-20T22:50:13 http://permalink.gmane.org/gmane.comp.gnu.libtool.bugs/8168 <pre> That's util-linux of course. libtool should work just right if libraries were moved into a sysroot after building and installing! </pre> markbrounce< at >lavabit.com 2013-05-20T23:00:16 http://permalink.gmane.org/gmane.comp.gnu.libtool.bugs/8167 <pre> Another ping. Is there some obvious problem with the patch? Should I fix something? The 'dd' utility is checked during './configure' phase, and if not found - whole file is read as it is now. Can this somehow broke the cross compilation? If yes, could you give me an example (somehow reproducible). Honestly, I don't see much into cross compilation use-cases. Thanks, Pavel </pre> Pavel Raiskup 2013-05-13T12:03:51 http://permalink.gmane.org/gmane.comp.gnu.libtool.bugs/8166 <pre> I'm sure there are other places you can patch to make this work. Saying that this problem is caused by libtool is not really fair, when libtool uses a construct that is documented and presumably works for "everybody else". Have you even verified if your ld groks -soname libfoo.so.0 without the equal sign before pointing fingers at ld? Have you checked if it is some interaction with the g++ compiler driver stomping arguments? Trying to run the g++ command printed by libtool manually, but inserting a -v to see how g++ invokes the low level tools might be illuminating. Maybe, doesn't sound too exotic, but it's not my area of expertise. I'm not so sure the SLES ld is to blame, it even seems unlikely. Cheers, Peter </pre> Peter Rosin 2013-05-08T21:00:11 http://permalink.gmane.org/gmane.comp.gnu.libtool.bugs/8165 <pre> of course you can use a different GNU ld. build &amp; install a different binutils package yourself. and file a bug with the SUSE maintainers. -mike _______________________________________________ Bug-libtool mailing list Bug-libtool&lt; at &gt;gnu.org https://lists.gnu.org/mailman/listinfo/bug-libtool </pre> Mike Frysinger 2013-05-08T15:46:54 http://permalink.gmane.org/gmane.comp.gnu.libtool.bugs/8164 <pre> At the end of the day, things don't work. I run the following on my configure script, and then things do work: sed -i 's/-soname \$wl/-soname=/g' configure Thanks for digging up the stuff in the manuals. Unfortunately, manuals don't always match reality. This is not a stock GNU ld 2.20, but rather one that's been hacked by SLSE 11. GNU ld (GNU Binutils; SUSE Linux Enterprise 11) 2.20.0.20100122-0.7.9 That would make it technically a SUSE bug. But maybe they don't care. Or they've already fixed it Or they think it's a feature, not a bug. At the end of the day, scripts generated by libtool are broken. Upgrading libtool is much easier than upgrading ld. This is a shared system and I can't realistically use a different GNU ld; however, I can use a different libtool. Since the two forms are supposed to be equivalent, would it be possible to change libtool to use the '=' form? Or maybe make a change with smaller scope: use the '=' form for certain versions of GNU ld, maybe specific to SLES? I</pre> Bob Fischer 2013-05-08T11:13:41 http://permalink.gmane.org/gmane.comp.gnu.libtool.bugs/8163 <pre> Those two should be exactly equivalent, at least according to the GNU ld manual. Quoting from section 2.1 "Command line options": Arguments to multiple-letter options must either be separated from the option name by an equals sign, or be given as separate arguments immediately following the option that requires them. For example, `--trace-symbol foo' and `--trace-symbol=foo' are equivalent. Unique abbreviations of the names of multiple-letter options are accepted. AFAICT, that paragraph is the same in ld 2.20 and in current ld. So, the problem does not appear to be the command line libtool is generating. I.e., the problem appears to be elsewhere. Cheers, Peter </pre> Peter Rosin 2013-05-08T07:41:24 http://permalink.gmane.org/gmane.comp.gnu.libtool.bugs/8162 <pre>The problem: libtool is generating a command line like -Wl,-soname -Wl,libglint2.so.0 instead of -Wl,-soname=libglint2.so.0 This causes errors in make, like: /usr/bin/ld: libglint2.so.0: No such file: No such file or directory collect2: error: ld returned 1 exit status make: *** [libglint2.la] Error 1 I'm using the following latest versions of autotools: drwxrwx--- 9 rpfische s1001 32768 2013-05-07 16:42 autoconf-2.69 drwxr-x--- 8 rpfische s1001 32768 2013-05-07 16:42 automake-1.13 drwxrwx--- 5 rpfische s1001 32768 2013-05-07 16:42 libtool-2.4.2 drwxrwx--- 10 rpfische s1001 32768 2013-05-07 16:42 m4-1.4.16 I'm using g++ 4.7.1 rpfische&lt; at &gt;dali14:~/git/glint2/slib&gt; which g++ /usr/local/other/SLES11/gcc/4.7.1/bin/g++ BUT... the OS is pretty old. I believe it's SLES 11: rpfische&lt; at &gt;dali14:~/git/glint2/slib&gt; uname -a Linux dali14 2.6.32.54-0.3-default #1 SMP 2012-01-27 17:38:56 +0100 x86_64 x86_64 x86_64 GNU/Linux rpfische&lt; at &gt;dali14:~/git</pre> Bob Fischer 2013-05-07T21:11:00 http://permalink.gmane.org/gmane.comp.gnu.libtool.bugs/8161 <pre>Ping &amp; update :), Pavel Here should be 'test' rather than '['. If the file is not readable (and possibly other?) ~&gt; 2&gt;/dev/null I found that the first indentation is 4 spaces.. Fixed indent. ------------------------------------------------------------------------------ From 38d952a1378e58655fba7cdb1e7f8edcd052e3ec Mon Sep 17 00:00:00 2001 From: Pavel Raiskup &lt;praiskup&lt; at &gt;redhat.com&gt; Date: Thu, 25 Apr 2013 10:24:33 +0200 Subject: [PATCH] libtool: speed up by pre-cutting sed's input by dd The execute mode was too slow when any parameter of executed command was a big binary file not having any newlines inside: $ libtool --mode=execute ls BIG_FILE_WITHOUT_NEWLINES This was because of the lalib detection among parameters. Every such file is pre-filtered by sed uitlity. That big slowdown is there because the sed utility tries to read and cache _unlimitedly_ the first four lines of these files. The new approach is pre-cutting relevant files by dd utility at 4kB size. * build-aux/ltmain.in (func_</pre> Pavel Raiskup 2013-04-29T06:37:49 http://permalink.gmane.org/gmane.comp.gnu.libtool.bugs/8160 <pre> I have now learned more about this problem. The problem occurs with LANG=en_US.UTF-8 but not with LANG=C. It seems that with LANG=en_US.UTF-8 various behaviors occur ranging from producing a different computed value, or gawk core dump. With LANG=C results are consistent on Solaris/OpenSolaris and no core dump. Presumably the character set used by an unmarked file (ChangeLog) is left up to the 'awk' utility to guess. Legacy awk programs may process the file as extended ANSI while modern awk programs will assume either plain ASCII or UTF-8. Bob </pre> Bob Friesenhahn 2013-04-27T19:52:59 http://permalink.gmane.org/gmane.comp.gnu.libtool.bugs/8159 <pre>I have narrowed the problem down to a difference in output from libltdl/config/mkstamp. Not all awks produce the same output, and the 'gawk' provided as a package with OpenSolaris (as well as hand-built 3.1.8) core dumps. Using Solaris /usr/xpg4/bin/awk: 1.3135 2011-10-17 Using GNU Awk 3.1.5: awk: cmd. line:3: (FILENAME=/home/bfriesen/src/gnu/libtool-2.4.2/ChangeLog.1997 FNR=134) fatal error: internal error zsh: IOT instruction (core dumped) ./libltdl/config/mkstamp /home/bfriesen/src/gnu/libtool-2.4.2 Using GNU Awk 3.1.8: awk: cmd. line:3: (FILENAME=/home/bfriesen/src/gnu/libtool-2.4.2/ChangeLog.1997 FNR=134) fatal error: internal error zsh: IOT instruction (core dumped) ./libltdl/config/mkstamp /home/bfriesen/src/gnu/libtool-2.4.2 Using GNU Awk 4.0.2: 1.3337 2011-10-17 On Solaris 10 with GNU Awk 3.1.5: 1.3337 2011-10-17 On GNU/Linux with GNU Awk 3.1.8: 1.3337 2011-10-17 On FreeBSD with FreeBSD awk 20070501: 1.3337 2011-10-17 Bob </pre> Bob Friesenhahn 2013-04-27T17:28:12 http://permalink.gmane.org/gmane.comp.gnu.libtool.bugs/8158 <pre>On an OpenIndiana (Solaris) system where I last formally installed libtool 2.4.2 on July 30, 2012, I am no longer able to build libtool 2.4.2. Regardless of if the build is done in the libtool source tree, or in another directory, the build fails with: libtool: Version mismatch error. This is libtool 2.4.2, revision 1.3337, libtool: but the definition of this LT_INIT comes from revision 1.3135. libtool: You should recreate aclocal.m4 with macros from revision 1.3337 libtool: of libtool 2.4.2 and run autoconf again. % autoconf --version autoconf (GNU Autoconf) 2.69 % automake --version automake (GNU automake) 1.13 % libtool --version libtool (GNU libtool) 2.4.2 % m4 --version m4 (GNU M4) 1.4.12 [ yes, the above is old ] % gcc --version gcc (GCC) 4.8.0 % gmake --version GNU Make 3.82 Quite bizarrely (not sure why), the first step of the build process regenerates libltdl/m4/ltversion.m4 in the source tree and ends up with a different serial number (1.3135) than what it had before (1.3337) even t</pre> Bob Friesenhahn 2013-04-27T15:59:08 http://permalink.gmane.org/gmane.comp.gnu.libtool.bugs/8157 <pre>The execute mode was too slow when any parameter of executed command was a big binary file not having any newlines inside: $ libtool --mode=execute ls BIG_FILE_WITHOUT_NEWLINES This was because of the lalib detection among parameters. Every such file is pre-filtered by sed uitlity. That big slowdown is there because the sed utility tries to read and cache _unlimitedly_ the first four lines of these files. The new approach is pre-cutting relevant files by dd utility at 4kB size. * build-aux/ltmain.in (func_try_sizelim): New function. (func_lalib_p): Cut the input file at 4kB before it is passed to sed utility. * gl/build-aux/funclib.sh: New variable $DD. * m4/libtool.m4 (_LT_PROG_DD): New macro. (_LT_SETUP): Require _LT_PROG_DD for the dd detection. --- build-aux/ltmain.in | 14 +++++++++++++- gl/build-aux/funclib.sh | 1 + m4/libtool.m4 | 14 ++++++++++++++ 3 files changed, 28 insertions(+), 1 deletion(-) diff --git a/build-aux/ltmain.in b/build-aux/ltmain.in index 4c56b98..4a21b58</pre> Pavel Raiskup 2013-04-25T11:48:35 http://permalink.gmane.org/gmane.comp.gnu.libtool.bugs/8156 <pre>Hi, sorry for the delay, here comes my (quite simple) proposal, this idea is not included, sadly - I'm unable to provide enough error prone solution and design such architecture. Thanks for this suggestion! I was thinking about it and it looks that the 'dd' utility should be enough portable for POSIX systems as it will be used with basic arguments. And if the 'dd' is not found, no so big issue happens; libtool has the same behaviour as before — read the whole file. Anyway, use of 'hexdump' or 'od' (which is at least on linux usually part of coreutils (same as dd)) may easily be incorporated when necessary which will cost just another one bash if-branch. [PATCH] libtool: speed up by pre-cutting sed's input by dd Pavel _______________________________________________ Bug-libtool mailing list Bug-libtool&lt; at &gt;gnu.org https://lists.gnu.org/mailman/listinfo/bug-libtool </pre> Pavel Raiskup 2013-04-25T11:48:34 http://permalink.gmane.org/gmane.comp.gnu.libtool.bugs/8155 <pre>There wasn't any update on this... It's still buggy. Could anyone point to the right direction? Lucas De Marchi </pre> Lucas De Marchi 2013-04-17T03:08:03 http://permalink.gmane.org/gmane.comp.gnu.libtool.bugs/8154 <pre> </pre> Toralf Förster 2013-04-12T21:25:38 http://permalink.gmane.org/gmane.comp.gnu.libtool.bugs/8153 <pre>I've libtool --version libtool (GNU libtool) 2.4.2 Written by Gordon Matzigkeit &lt;gord&lt; at &gt;gnu.ai.mit.edu&gt;, 1996 Copyright (C) 2011 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. on lsb_release -a LSB Version: core-2.0-noarch:core-3.2-noarch:core-4.0-noarch:core-2.0-x86_64:core-3.2-x86_64:core-4.0-x86_64:desktop-4.0-amd64:desktop-4.0-noarch:graphics-2.0-amd64:graphics-2.0-noarch:graphics-3.2-amd64:graphics-3.2-noarch:graphics-4.0-amd64:graphics-4.0-noarch Distributor ID: openSUSE project Description: openSUSE 12.3 (x86_64) Release: 12.3 Codename: Dartmouth I originally reported this &lt; at &gt; Opensuse bugzilla https://bugzilla.novell.com/show_bug.cgi?id=786460 but was told to report it upstream. IMO, the issue is directly related to Opensuse's use of LIBDIR=lib64 on X86_64 systems, and should be patched THERE, but ... here's the iss</pre> ar16< at >imapmail.org 2013-04-07T18:32:55 http://permalink.gmane.org/gmane.comp.gnu.libtool.bugs/8152 <pre>Hello, In regards of libtool bug #13920 and debian bug #702737 I kindly ask you to update the documentation of libtool in aspect of link_all_deplibs, with something like the text below. I consider this as essential, as it would have saved me quite some (from my free) time investigating why the linking on Debian works differently/not according to the documentation. A proper documentation of link_all_deplibs on different systems, will safe the time of other developers investigating the same issue. diff --git a/doc/libtool.texi b/doc/libtool.texi index c06ddaa..ec0d926 100644 --- a/doc/libtool.texi +++ b/doc/libtool.texi &lt; at &gt;&lt; at &gt; -6938,6 +6938,9 &lt; at &gt;&lt; at &gt; the file name that the linker finds when given &lt; at &gt;option{-l&lt; at &gt;var{name}}. Whether libtool must link a program against all its dependency libraries. Set to &lt; at &gt;samp{yes} or &lt; at &gt;samp{no}. Default is &lt; at &gt;samp{unknown}, which is a synonym for &lt; at &gt;samp{yes}. + +On Debian and Ubuntu systems the default is &lt; at &gt;samp{no}. As a side effect, +transitive dependencies which rely on &lt; at &gt;s</pre> Дилян Палаузов 2013-04-02T20:04:09 http://permalink.gmane.org/gmane.comp.gnu.libtool.bugs/8151 <pre>Hi, additional output: /bin/sh ../../libtool --tag=CC --mode=link /usr/bin/ccache x86_64-w64-mingw32-gcc -std=gnu99 -shared -I/home/dev1usr/Project/NHI1/theLink/tclmsgque/../libmsgque -I/cygdrive/c/Tcl/include -DMQ_IGNORE_EXTERN -g -Wall -Wcast-align -g -O2 -shared -module -avoid-version -no-undefined -L/cygdrive/c/Tcl/lib -ltcl86 -o tclmsgque.la -rpath /usr/local/lib/NHI1 tclmsgque_la-MqS_tcl.lo tclmsgque_la-misc_tcl.lo tclmsgque_la-msgque_tcl.lo tclmsgque_la-read_tcl.lo tclmsgque_la-send_tcl.lo tclmsgque_la-config_tcl.lo tclmsgque_la-service_tcl.lo tclmsgque_la-slave_tcl.lo tclmsgque_la-MqBufferS_tcl.lo tclmsgque_la-error_tcl.lo tclmsgque_la-link_tcl.lo tclmsgque_la-MqFactoryS_tcl.lo tclmsgque_la-MqDumpS_tcl.lo ../libmsgque/libtmp.la *** Warning: linker path does not have real file for library -ltcl86. *** I have the capability to make that library automatically link in when *** you link to this library. But I can only do this if you have a *** shared version of the library, which you</pre> Andreas Otto 2013-03-26T15:21:48 http://permalink.gmane.org/gmane.comp.gnu.libtool.bugs/8150 <pre>[SNIP] Try to generate import library compatible with GNU C compiler . Expected suffix is dll.a . You could find hints in internet . From you post is not clear if tcl86.lib is static or import library . Listing sharer liibrary before object files in most case work but correct order is after. Roumen P.S. Welcome to windows DLL hell. </pre> Roumen Petrov 2013-03-26T21:50:08 http://permalink.gmane.org/gmane.comp.gnu.libtool.bugs/8149 <pre> This is the classic case of putting the library before the objects. As I told you before, you should have the library providing the needed symbols *after* the objects requiring them. I.e. /bin/sh ../../libtool --tag=CC --verbose --mode=link /usr/bin/ccache x86_64-w64-mingw32-gcc -std=gnu99 -shared -I/home/dev1usr/Project/NHI1/theLink/tclmsgque/../libmsgque -I/cygdrive/c/Tcl/include -DMQ_IGNORE_EXTERN -g -Wall -Wcast-align -g -O2 -shared -module -avoid-version -no-undefined -o tclmsgque.la -rpath /usr/local/lib/NHI1 tclmsgque_la-MqS_tcl.lo tclmsgque_la-misc_tcl.lo tclmsgque_la-msgque_tcl.lo tclmsgque_la-read_tcl.lo tclmsgque_la-send_tcl.lo tclmsgque_la-config_tcl.lo tclmsgque_la-service_tcl.lo tclmsgque_la-slave_tcl.lo tclmsgque_la-MqBufferS_tcl.lo tclmsgque_la-error_tcl.lo tclmsgque_la-link_tcl.lo tclmsgque_la-MqFactoryS_tcl.lo tclmsgque_la-MqDumpS_tcl.lo ../libmsgque/libtmp.la /cygdrive/c/Tcl/lib/tcl86.lib I can only assume, since the library is named tcl86.lib and not libtcl86.dll.a, that it is was co</pre> Peter Rosin 2013-03-26T16:17:17 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.comp.gnu.libtool.bugs