Re: --preserve-dup-deps seems not to work
Hello Stefan,
Thanks for the bug report.
* Stefan Traby wrote on Wed, Sep 13, 2006 at 04:01:19AM CEST:
I tried libtool-1.4.3 (which introduced --preserve-dup-deps)
in addition to 1.5.22 which I use normally:
The long (real-world) output is here:
http://txt.hello-penguin.com/b841990fcf3769591e90b01c8947e03a.txt
here a short variant:
/bin/sh ./libtool --preserve-dup-deps --mode=link gcc -g -O2 -o prog prog.o
liba.la libb.la liba.la libb.la
gcc -g -O2 -o prog prog.o ./.libs/liba.a ./.libs/libb.a
I don't know how to make libtool to honor duplicate dependencies.
In this special case, you have two convenience archives liba.la and
libb.la which have a circular dependency (as opposed to: one or both
libraries are to-be-installed static or shared libraries). I agree
that this case should work. But this case is also the easiest to work
around: you could add liba.la as a dependency to the link line of
libb.la:
$LIBTOOL --mode=link --tag=CC $CC $CFLAGS $LDFLAGS -o libb.la \
b.lo [OBJECTS...] liba.la
This is a bit wasteful in that all objects from liba will also appear
in some form or other in libb, but it should be portable. It will
require you to add a dependency of libb.la on liba.la in your Makefile
(in case you use Automake it should take care of that, I believe).
I think we should fix this. Proposed test case below.
Cheers,
Ralf
* tests/duplicate_deps.at: New file. Test circular depending
convenience archives (currently failing).
* Makefile.am: Update.
Report by Stefan Traby [EMAIL PROTECTED].
Index: Makefile.am
===
RCS file: /cvsroot/libtool/libtool/Makefile.am,v
retrieving revision 1.198
diff -u -r1.198 Makefile.am
--- Makefile.am 12 Sep 2006 18:02:31 - 1.198
+++ Makefile.am 13 Sep 2006 05:48:01 -
@@ -399,6 +399,7 @@
tests/libtoolize.at \
tests/duplicate_members.at \
tests/duplicate_conv.at \
+ tests/duplicate_deps.at \
tests/inherited_flags.at \
tests/convenience.at \
tests/link-order.at \
--- /dev/null 2006-09-05 22:40:33.520458500 +0200
+++ tests/duplicate_deps.at 2006-09-13 07:48:16.0 +0200
@@ -0,0 +1,64 @@
+# Hand crafted tests for GNU Libtool. -*- Autotest -*-
+# Copyright 2006 Free Software Foundation, Inc.
+
+# This program is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation; either version 2, or (at your option)
+# any later version.
+
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+# GNU General Public License for more details.
+
+# You should have received a copy of the GNU General Public License
+# along with this program; if not, write to the Free Software
+# Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA
+# 02110-1301, USA.
+
+AT_SETUP([preserve duplicate convenience deps])
+AT_KEYWORDS([libtool])
+
+# --preserve-dup-deps should work for convenience archives.
+
+# Create a circular dependency of liba and libb:
+# a1 pulls in b1, that pulls in a2.
+cat a1.c \EOF
+extern int b1 ();
+int a1 () { return b1 (); }
+EOF
+cat a2.c \EOF
+int a2 () { return 0; }
+EOF
+cat b1.c \EOF
+extern int a2 ();
+int b1 () { return a2 (); }
+EOF
+cat main.c \EOF
+extern int a1 ();
+int main () { return a1 (); }
+EOF
+
+for file in a1.c a2.c b1.c; do
+ $LIBTOOL --mode=compile $CC $CPPFLAGS $CFLAGS -c $file
+done
+$CC $CPPFLAGS $CFLAGS -c main.c
+$LIBTOOL --mode=link --tag=CC $CC $CFLAGS $LDFLAGS -o liba.la a1.lo a2.lo
+
+# This could be worked around by adding liba.la to libb.la
+# (in that case all objects from liba would be merged into
+# libb.a as well, possibly renamed.)
+$LIBTOOL --mode=link --tag=CC $CC $CFLAGS $LDFLAGS -o libb.la b1.lo liba.la
+AT_CHECK([$LIBTOOL --mode=link --tag=CC \
+ $CC $CFLAGS $LDFLAGS -o main main.$OBJEXT liba.la libb.la],
+ [0], [ignore], [ignore])
+LT_AT_EXEC_CHECK([./main])
+
+# This currently fails:
+AT_XFAIL_IF([:])
+$LIBTOOL --mode=link --tag=CC $CC $CFLAGS $LDFLAGS -o libb.la b1.lo
+AT_CHECK([$LIBTOOL --mode=link --preserve-dup-deps --tag=CC \
+ $CC $CFLAGS $LDFLAGS -o main main.$OBJEXT liba.la libb.la liba.la],
+ [0], [ignore], [ignore])
+
+AT_CLEANUP
___
Bug-libtool mailing list
Bug-libtool@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-libtool
AC_LIBTOOL_SYS_DYNAMIC_LINKER gcc -print-search-dirs problem
On my x86_64-unknown-linux-gnu system, the m4 macro AC_LIBTOOL_SYS_DYNAMIC_LINKER in libtool.m4 uses gcc -print-search-dirs to set sys_lib_search_path_spec. Unfortunately, -print-search-dirs lists -m32 library directories, but gcc is in (default) -m64 mode on my system. Consequently libtool tries to link with the wrong library (32 bit when it should be using 64 bit). The particular error message I get is : /usr/local/gcc-4.1.1/x86_64-Linux/lib/../lib/libstdc++.so: could not read symbols: : File in wrong format I can get the appropriate 64-bit directories to search by 'gcc -v -o hello hello.c' from a hello world program and then looking at the directories following each -L. If I then hack configure to explicitly set sys_lib_search_path_spec with these directories, then /usr/local/gcc-4.1.1/x86_64-Linux/lib/../lib64/libstdc++.so is used and everything is fine. Unfortunately, I do not have a small example to demonstrate the problem. I found this while trying to compile givaro-3.2.1 (http://www-lmc.imag.fr/Logiciels/givaro/). Any help or suggestions on what should be the appropriate change to AC_LIBTOOL_SYS_DYNAMIC_LINKER to make it work in the multilib environment would be appreciated. Kate Minola University of Maryland, College Park ___ Bug-libtool mailing list Bug-libtool@gnu.org http://lists.gnu.org/mailman/listinfo/bug-libtool
Re: AC_LIBTOOL_SYS_DYNAMIC_LINKER gcc -print-search-dirs problem
Hello Bob, Kate, * Bob Friesenhahn wrote on Wed, Sep 13, 2006 at 04:34:52PM CEST: On Wed, 13 Sep 2006, Kate Minola wrote: On my x86_64-unknown-linux-gnu system, the m4 macro AC_LIBTOOL_SYS_DYNAMIC_LINKER in libtool.m4 uses gcc -print-search-dirs to set sys_lib_search_path_spec. I think that this is really a GCC bug. I have the same problem under Solaris. Libtool should work around the GCC bug by detecting 64-bit compilation and expanding the search path to look in the 64-bit library directories first. Would it be semantically correct for libtool to make use of any of gcc -print-multi-lib gcc -print-multi-directory gcc -print-multi-os-directory ? If yes: which, and for which paths? It seems of those, only the last is understood by gcc 3.3; I have not tested earlier versions. Cheers, Ralf ___ Bug-libtool mailing list Bug-libtool@gnu.org http://lists.gnu.org/mailman/listinfo/bug-libtool
Re: AC_LIBTOOL_SYS_DYNAMIC_LINKER gcc -print-search-dirs problem
On Sep 13, 2006, at 11:34 PM, Bob Friesenhahn wrote:
On Wed, 13 Sep 2006, Kate Minola wrote:
On my x86_64-unknown-linux-gnu system, the m4 macro
AC_LIBTOOL_SYS_DYNAMIC_LINKER in libtool.m4
uses gcc -print-search-dirs to set sys_lib_search_path_spec.
Unfortunately, -print-search-dirs lists -m32 library directories,
but gcc is in (default) -m64 mode on my system. Consequently libtool
tries to link with the wrong library (32 bit when it should be
using 64 bit).
The particular error message I get is
I think that this is really a GCC bug. I have the same problem
under Solaris. Libtool should work around the GCC bug by detecting
64-bit compilation and expanding the search path to look in the 64-
bit library directories first.
Hi Bob,
As far as I'm aware there is not going to be a fix for this in gcc,
so yes, we need to fix it.
Perhaps something like:
echo int main(){return 0;} conftest.c
search_path=`$CC $CFLAGS -c conftest.c 21 | awk 'BEGIN {RS= } /^
[\]?-L/ {sub (-L,);print $0};'`
rm -f conftest.c conftest.o
Peter
___
Bug-libtool mailing list
Bug-libtool@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-libtool
Re: AC_LIBTOOL_SYS_DYNAMIC_LINKER gcc -print-search-dirs problem
On Sep 13, 2006, at 11:41 PM, Peter O'Gorman wrote:
On Sep 13, 2006, at 11:34 PM, Bob Friesenhahn wrote:
On Wed, 13 Sep 2006, Kate Minola wrote:
On my x86_64-unknown-linux-gnu system, the m4 macro
AC_LIBTOOL_SYS_DYNAMIC_LINKER in libtool.m4
uses gcc -print-search-dirs to set sys_lib_search_path_spec.
Unfortunately, -print-search-dirs lists -m32 library directories,
but gcc is in (default) -m64 mode on my system. Consequently
libtool
tries to link with the wrong library (32 bit when it should be
using 64 bit).
The particular error message I get is
I think that this is really a GCC bug. I have the same problem
under Solaris. Libtool should work around the GCC bug by
detecting 64-bit compilation and expanding the search path to look
in the 64-bit library directories first.
Hi Bob,
As far as I'm aware there is not going to be a fix for this in gcc,
so yes, we need to fix it.
Perhaps something like:
echo int main(){return 0;} conftest.c
search_path=`$CC $CFLAGS -c conftest.c 21 | awk 'BEGIN {RS= } /^
[\]?-L/ {sub (-L,);print $0};'`
rm -f conftest.c conftest.o
I really should try things before sending mail :)
gcc -v -o conftest conftest.c 21 | awk 'BEGIN {RS= } /^[\]?-L/
{sub (-L,); print $0};'
Peter
___
Bug-libtool mailing list
Bug-libtool@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-libtool
Re: AC_LIBTOOL_SYS_DYNAMIC_LINKER gcc -print-search-dirs problem
* Peter O'Gorman wrote on Wed, Sep 13, 2006 at 04:41:56PM CEST:
As far as I'm aware there is not going to be a fix for this in gcc,
so yes, we need to fix it.
Perhaps something like:
echo int main(){return 0;} conftest.c
search_path=`$CC $CFLAGS -c conftest.c 21 | awk 'BEGIN {RS= } /^
[\]?-L/ {sub (-L,);print $0};'`
rm -f conftest.c conftest.o
Only as a last resort, if you ask me. Other compilers love to
disguise as gcc, and Autoconf's AC_FC_LIBRARY_LDFLAGS is witness of
how helplessly maintenance-intensive an approach like the above is.
Cheers,
Ralf
___
Bug-libtool mailing list
Bug-libtool@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-libtool
Re: AC_LIBTOOL_SYS_DYNAMIC_LINKER gcc -print-search-dirs problem
On Sep 13, 2006, at 11:49 PM, Ralf Wildenhues wrote: Only as a last resort, if you ask me. Other compilers love to disguise as gcc, and Autoconf's AC_FC_LIBRARY_LDFLAGS is witness of how helplessly maintenance-intensive an approach like the above is. That's looking at all kinds of flags, in this case we're only interested in -L. Peter ___ Bug-libtool mailing list Bug-libtool@gnu.org http://lists.gnu.org/mailman/listinfo/bug-libtool
general question on gcc -print-search-dirs multilib problem
Hi, Based on recent thread on AC_LIBTOOL_SYS_DYNAMIC_LINKER: I wonder why it is actually necessary for libtool to query system library search dirs from gcc, because when gcc is used as linker, it will know where to get system libs from. Are there exceptions to this behaviour, which libtool has to work around ? Thanks, haubi -- Michael HaubenwallnerSALOMON Automation GmbH Forschung Entwicklung A-8114 Friesach bei Graz mailto:[EMAIL PROTECTED] http://www.salomon.at No HTML/MIME please, see http://expita.com/nomime.html ___ Bug-libtool mailing list Bug-libtool@gnu.org http://lists.gnu.org/mailman/listinfo/bug-libtool
Re: AC_LIBTOOL_SYS_DYNAMIC_LINKER gcc -print-search-dirs problem
* Peter O'Gorman wrote on Wed, Sep 13, 2006 at 04:55:11PM CEST: On Sep 13, 2006, at 11:49 PM, Ralf Wildenhues wrote: Only as a last resort, if you ask me. Other compilers love to disguise as gcc, and Autoconf's AC_FC_LIBRARY_LDFLAGS is witness of how helplessly maintenance-intensive an approach like the above is. That's looking at all kinds of flags, in this case we're only interested in -L. Alright, feel free to give it a shot. From the Autoconf macro we know that -LANG:=* | -LIST:* | -LNO:* should be ignored, for pathscale and some other compilers I have forgotten now. Otherwise your awk script seems to work with PGI, Intel, and PathScale. Cheers, Ralf ___ Bug-libtool mailing list Bug-libtool@gnu.org http://lists.gnu.org/mailman/listinfo/bug-libtool
Re: AC_LIBTOOL_SYS_DYNAMIC_LINKER gcc -print-search-dirs problem
On Sep 14, 2006, at 12:12 AM, Ralf Wildenhues wrote: * Peter O'Gorman wrote on Wed, Sep 13, 2006 at 04:55:11PM CEST: On Sep 13, 2006, at 11:49 PM, Ralf Wildenhues wrote: Only as a last resort, if you ask me. Other compilers love to disguise as gcc, and Autoconf's AC_FC_LIBRARY_LDFLAGS is witness of how helplessly maintenance-intensive an approach like the above is. That's looking at all kinds of flags, in this case we're only interested in -L. Alright, feel free to give it a shot. From the Autoconf macro we know that -LANG:=* | -LIST:* | -LNO:* should be ignored, for pathscale and some other compilers I have forgotten now. Otherwise your awk script seems to work with PGI, Intel, and PathScale. I don't think we need to worry about that as the test is specific to gcc. However I'll think about it more tomorrow when I hack at it, bedtime here now :) Peter ___ Bug-libtool mailing list Bug-libtool@gnu.org http://lists.gnu.org/mailman/listinfo/bug-libtool
Re: AC_LIBTOOL_SYS_DYNAMIC_LINKER gcc -print-search-dirs problem
On Wed, 13 Sep 2006, Ralf Wildenhues wrote: Also my gcc likes to output stuff like .. /usr/lib/gcc/x86_64-linux-gnu/4.0.3 /usr/lib/gcc/x86_64-linux-gnu/4.0.3 /usr/lib/gcc/x86_64-linux-gnu/4.0.3/../../../../lib64 /usr/lib/gcc/x86_64-linux-gnu/4.0.3/../../.. /lib/../lib64 /usr/lib/../lib64 without a flag (i.e., -m64). Looks kinda scary to not have /usr/lib and /usr/lib32 and /usr/lib64 in this list. It's nice to know that gcc-4.0.3 has fixed one part of the problem. However, not having /usr/lib, /lib, and /usr/local/lib is really bad. The above output should be compared with the default (GNU) linker search path as, e.g., in /usr/x86_64-linux-gnu/lib/ldsripts/elf_x86_64.x: SEARCH_DIR(/usr/x86_64-linux-gnu/lib64); SEARCH_DIR(/usr/local/lib64); SEARCH_DIR(/lib64); SEARCH_DIR(/usr/lib64); SEARCH_DIR(/usr/x86_64-linux-gnu/lib); SEARCH_DIR(/usr/local/lib); SEARCH_DIR(/lib); SEARCH_DIR(/usr/lib); containing both .../lib64 and .../lib directories. regards Peter Breitenlohner [EMAIL PROTECTED] ___ Bug-libtool mailing list Bug-libtool@gnu.org http://lists.gnu.org/mailman/listinfo/bug-libtool
Re: Re: AC_LIBTOOL_SYS_DYNAMIC_LINKER gcc -print-search-dirs problem
Ralf, Peter, Why not use the output of gcc -print-search-dirs and, for every directory that ends with lib, append the value returned by gcc -print-multi-os-directory? Naturally one will have to backup directories such as /usr/lib/gcc/x86_64-linux-gnu/4.0.3/../../.. to realize that it ends with lib. (Other than writing a program, I do not see an easy way to do this last bit.) Kate Minola University of Maryland, College Park ___ Bug-libtool mailing list Bug-libtool@gnu.org http://lists.gnu.org/mailman/listinfo/bug-libtool
