Package: libtool;
Reported by: Bob Fischer <rpf2116 <at> columbia.edu>
Date: Tue, 7 May 2013 21:53:02 UTC
Severity: normal
To reply to this bug, email your comments to 14364 AT debbugs.gnu.org.
Toggle the display of automated, internal messages from the tracker.
View this report as an mbox folder, status mbox, maintainer mbox
bug-libtool <at> gnu.org:bug#14364; Package libtool.
(Tue, 07 May 2013 21:53:02 GMT) Full text and rfc822 format available.Bob Fischer <rpf2116 <at> columbia.edu>:bug-libtool <at> gnu.org.
(Tue, 07 May 2013 21:53:02 GMT) Full text and rfc822 format available.Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
From: Bob Fischer <rpf2116 <at> columbia.edu> To: bug-libtool <at> gnu.org Subject: Bug Report: Lacking '=' when specifying -soname Date: Tue, 07 May 2013 17:11:00 -0400
[Message part 1 (text/plain, inline)]
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 <at> dali14:~/git/glint2/slib> 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 <at> dali14:~/git/glint2/slib> 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 <at> dali14:~/git/glint2/slib> ld --version
GNU ld (GNU Binutils; SUSE Linux Enterprise 11) 2.20.0.20100122-0.7.9
Copyright 2009 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the
terms of
the GNU General Public License version 3 or (at your option) a later
version.
This program has absolutely no warranty.
rpfische <at> dali14:~/git/glint2/slib> which ld
/usr/bin/ld
I suspect that the syntax for '-soname' might have changed for ld, and
that autotools is not correctly generating command line flags for this
old ld that I'm using. Things work just fine on MacPorts.
A fuller transcript follows.
-- Bob
===============================================
rpfische <at> dali14:~/git/glint2/slib> make
/bin/sh ../libtool --tag=CXX --mode=link
/usr/local/other/SLES11/gcc/4.7.1/bin/g++ -std=c++11 -I../slib -I
/home/rpfische/nobackup/opt-gcc-4.7.1/netcdf-4.3.0/include
-I/home/rpfische/nobackup/opt-gcc-4.7.1/netcdf-cxx-4.2/include -I
/home/rpfische/nobackup/opt-gcc-4.7.1/proj-4.8.0/include -I
/home/rpfische/nobackup/opt-gcc-4.7.1/gmp-5.1.1/include -I
/home/rpfische/nobackup/opt-gcc-4.7.1/blitz-0.10/include -I
/home/rpfische/nobackup/opt-gcc-4.7.1/eigen-3.1.3/include -I
/home/rpfische/nobackup/opt-gcc-4.7.1/cgal-4.0.2/include -I
/home/rpfische/nobackup/opt-gcc-4.7.1/mpfr-3.1.2/include
-I/home/rpfische/nobackup/opt-gcc-4.7.1/boost-1.53.0/include -pthread -I
/usr/local/intel/mpi/3.2.2.006/lib64/include -frounding-math
-I/usr/include/python2.6 -I/usr/include/python2.6 -fno-strict-aliasing
-DNDEBUG -fmessage-length=0 -O2 -Wall -D_FORTIFY_SOURCE=2
-fstack-protector -funwind-tables -fasynchronous-unwind-tables -g
-fwrapv -I/usr/lib64/python2.6/site-packages/numpy/core/include -g -O2
-L/home/rpfische/nobackup/opt-gcc-4.7.1/netcdf-4.3.0/lib -lnetcdf
-L/home/rpfische/nobackup/opt-gcc-4.7.1/netcdf-cxx-4.2/lib -lnetcdf_c++
-L/home/rpfische/nobackup/opt-gcc-4.7.1/netcdf-fortran-4.2/lib
-lnetcdff -L/home/rpfische/nobackup/opt-gcc-4.7.1/proj-4.8.0/lib
-lproj -L/home/rpfische/nobackup/opt-gcc-4.7.1/gmp-5.1.1/lib -lgmp
-L/home/rpfische/nobackup/opt-gcc-4.7.1/blitz-0.10/lib -lblitz
-L/home/rpfische/nobackup/opt-gcc-4.7.1/cgal-4.0.2/lib -lCGAL
-L/usr/local/intel/mpi/3.2.2.006/lib64/lib -lmpi
-L/home/rpfische/nobackup/opt-gcc-4.7.1/boost-1.53.0/lib -Wl,-rpath
/home/rpfische/nobackup/opt-gcc-4.7.1/boost-1.53.0/lib -lboost_thread
-lboost_system -pthread -lgfortran -o libglint2.la -rpath
/home/rpfische/nobackup/opt-gcc-4.7.1/glint2/lib geodesy.lo
hsl_zd11_x.lo IndexTranslator.lo ncutil.lo Proj2.lo SparseMatrix.lo
sparsemult.lo clippers.lo ExchangeGrid.lo GCMCoupler.lo
GCMCoupler_MPI.lo Grid.lo Grid_LonLat.lo Grid_XY.lo GridDomain.lo
GridDomain_Listed.lo gridutil.lo HeightClassifier.lo IceModel_DISMAL.lo
IceSheet.lo IceSheet_L0.lo matrix_ops.lo MatrixMaker.lo grids_ll.lo
glint2_modele.lo read_grid.lo read_icemodel.lo read_matrixmaker.lo
f90blitz_f.lo glint2_modele_f.lo
libtool: link: /usr/local/other/SLES11/gcc/4.7.1/bin/g++ -fPIC -DPIC
-shared -nostdlib /usr/lib/../lib64/crti.o
/usr/local/other/SLES11/gcc/4.7.1/lib/gcc/x86_64-unknown-linux-gnu/4.7.1/crtbeginS.o
.libs/geodesy.o .libs/hsl_zd11_x.o .libs/IndexTranslator.o
.libs/ncutil.o .libs/Proj2.o .libs/SparseMatrix.o .libs/sparsemult.o
.libs/clippers.o .libs/ExchangeGrid.o .libs/GCMCoupler.o
.libs/GCMCoupler_MPI.o .libs/Grid.o .libs/Grid_LonLat.o .libs/Grid_XY.o
.libs/GridDomain.o .libs/GridDomain_Listed.o .libs/gridutil.o
.libs/HeightClassifier.o .libs/IceModel_DISMAL.o .libs/IceSheet.o
.libs/IceSheet_L0.o .libs/matrix_ops.o .libs/MatrixMaker.o
.libs/grids_ll.o .libs/glint2_modele.o .libs/read_grid.o
.libs/read_icemodel.o .libs/read_matrixmaker.o .libs/f90blitz_f.o
.libs/glint2_modele_f.o -Wl,-rpath
-Wl,/home/rpfische/nobackup/opt-gcc-4.7.1/netcdf-cxx-4.2/lib -Wl,-rpath
-Wl,/home/rpfische/nobackup/opt-gcc-4.7.1/netcdf-fortran-4.2/lib
-Wl,-rpath -Wl,/home/rpfische/nobackup/opt-gcc-4.7.1/netcdf-4.3.0/lib
-Wl,-rpath -Wl,/home/rpfische/nobackup/opt-gcc-4.7.1/proj-4.8.0/lib
-Wl,-rpath -Wl,/home/rpfische/nobackup/opt-gcc-4.7.1/gmp-5.1.1/lib
-Wl,-rpath -Wl,/usr/local/other/SLES11/gcc/4.7.1/lib/../lib64 -Wl,-rpath
-Wl,/home/rpfische/nobackup/opt-gcc-4.7.1/netcdf-cxx-4.2/lib -Wl,-rpath
-Wl,/home/rpfische/nobackup/opt-gcc-4.7.1/netcdf-fortran-4.2/lib
-Wl,-rpath -Wl,/home/rpfische/nobackup/opt-gcc-4.7.1/netcdf-4.3.0/lib
-Wl,-rpath -Wl,/home/rpfische/nobackup/opt-gcc-4.7.1/proj-4.8.0/lib
-Wl,-rpath -Wl,/home/rpfische/nobackup/opt-gcc-4.7.1/gmp-5.1.1/lib
-Wl,-rpath -Wl,/usr/local/other/SLES11/gcc/4.7.1/lib/../lib64
-L/home/rpfische/nobackup/opt-gcc-4.7.1/netcdf-4.3.0/lib
-L/home/rpfische/nobackup/opt-gcc-4.7.1/netcdf-cxx-4.2/lib
/home/rpfische/nobackup/opt-gcc-4.7.1/netcdf-cxx-4.2/lib/libnetcdf_c++.so -L/usr/local/other/SLES11/gcc/4.7.1/lib/../lib64
-L/home/rpfische/nobackup/opt-gcc-4.7.1/netcdf-fortran-4.2/lib
/home/rpfische/nobackup/opt-gcc-4.7.1/netcdf-fortran-4.2/lib/libnetcdff.so
/home/rpfische/nobackup/opt-gcc-4.7.1/netcdf-4.3.0/lib/libnetcdf.so
-lcurl -L/home/rpfische/nobackup/opt-gcc-4.7.1/proj-4.8.0/lib
/home/rpfische/nobackup/opt-gcc-4.7.1/proj-4.8.0/lib/libproj.so
-L/home/rpfische/nobackup/opt-gcc-4.7.1/gmp-5.1.1/lib
/home/rpfische/nobackup/opt-gcc-4.7.1/gmp-5.1.1/lib/libgmp.so
-L/home/rpfische/nobackup/opt-gcc-4.7.1/blitz-0.10/lib
/home/rpfische/nobackup/opt-gcc-4.7.1/blitz-0.10/lib/libblitz.a
-L/home/rpfische/nobackup/opt-gcc-4.7.1/cgal-4.0.2/lib -lCGAL
-L/usr/local/intel/mpi/3.2.2.006/lib64/lib -lmpi
-L/home/rpfische/nobackup/opt-gcc-4.7.1/boost-1.53.0/lib -lboost_thread
-lboost_system
/usr/local/other/SLES11/gcc/4.7.1/lib/../lib64/libgfortran.so
/usr/local/other/SLES11/gcc/4.7.1/lib/../lib64/libquadmath.so
-L/usr/local/other/SLES11/gcc/4.7.1/lib64/../lib64
-L/usr/local/intel/mpi/3.2.2.006/lib64/../lib64
-L/usr/local/other/SLES11/gcc/4.7.1/lib/gcc/x86_64-unknown-linux-gnu/4.7.1
-L/usr/local/other/SLES11/gcc/4.7.1/lib/gcc/x86_64-unknown-linux-gnu/4.7.1/../../../../lib64
-L/lib/../lib64 -L/usr/lib/../lib64
-L/usr/local/other/SLES11/gcc/4.7.1/lib64
-L/usr/local/other/Git/1.7.3.4/lib
-L/usr/local/intel/mpi/3.2.2.006/lib64
-L/usr/local/intel/Composer/composer_xe_2013.3.163/compiler/lib/intel64
-L/usr/local/intel/Composer/composer_xe_2013.3.163/ipp/lib/intel64
-L/usr/local/intel/Composer/composer_xe_2013.3.163/mkl/lib/intel64
-L/usr/local/intel/Composer/composer_xe_2013.3.163/tbb/lib/intel64
-L/usr/local/other/SLES11/gcc/4.7.1/lib/gcc/x86_64-unknown-linux-gnu/4.7.1/../../..
/usr/local/other/SLES11/gcc/4.7.1/lib/../lib64/libstdc++.so -lm -lc
-lgcc_s
/usr/local/other/SLES11/gcc/4.7.1/lib/gcc/x86_64-unknown-linux-gnu/4.7.1/crtendS.o
/usr/lib/../lib64/crtn.o -pthread -O2 -O2 -Wl,-rpath -pthread -pthread
-Wl,-soname -Wl,libglint2.so.0 -o .libs/libglint2.so.0.0.0
/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
rpfische <at> dali14:~/git/glint2/slib>
[Message part 2 (text/html, inline)]
bug-libtool <at> gnu.org:bug#14364; Package libtool.
(Wed, 08 May 2013 07:43:01 GMT) Full text and rfc822 format available.Message #8 received at 14364 <at> debbugs.gnu.org (full text, mbox):
From: Peter Rosin <peda <at> lysator.liu.se> To: Bob Fischer <rpf2116 <at> columbia.edu> Cc: 14364 <at> debbugs.gnu.org Subject: Re: bug#14364: Bug Report: Lacking '=' when specifying -soname Date: Wed, 08 May 2013 09:41:24 +0200
On 2013-05-07 23:11, Bob Fischer wrote: > The problem: libtool is generating a command line like > -Wl,-soname -Wl,libglint2.so.0 > instead of > -Wl,-soname=libglint2.so.0 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
bug-libtool <at> gnu.org:bug#14364; Package libtool.
(Wed, 08 May 2013 11:15:02 GMT) Full text and rfc822 format available.Message #11 received at 14364 <at> debbugs.gnu.org (full text, mbox):
From: Bob Fischer <rpf2116 <at> columbia.edu> To: Peter Rosin <peda <at> lysator.liu.se> Cc: 14364 <at> debbugs.gnu.org Subject: Re: bug#14364: Bug Report: Lacking '=' when specifying -soname Date: Wed, 8 May 2013 07:13:41 -0400
>
>
> So, the problem does not appear to be the command line libtool is
> generating. I.e., the problem appears to be elsewhere.
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'd also be relatively happy if there was a way I could build the configure.ac file to work around this problem --- in essence, override the '-soname' with '-soname=' coming from the standard libtool. However, libtool looks like it's a little all-or-nothing, and not quite amenable to incremental overrides (hence the see hack). I'm wondering if maybe generating '-soname=' for specific versions of SUSE ld would be the most expedient way to solve this problem.
Thanks,
-- Bob
bug-libtool <at> gnu.org:bug#14364; Package libtool.
(Wed, 08 May 2013 15:49:02 GMT) Full text and rfc822 format available.Message #14 received at submit <at> debbugs.gnu.org (full text, mbox):
From: Mike Frysinger <vapier <at> gentoo.org> To: bug-libtool <at> gnu.org Cc: Bob Fischer <rpf2116 <at> columbia.edu>, Peter Rosin <peda <at> lysator.liu.se>, 14364 <at> debbugs.gnu.org Subject: Re: bug#14364: Bug Report: Lacking '=' when specifying -soname Date: Wed, 8 May 2013 11:46:54 -0400
[Message part 1 (text/plain, inline)]
On Wednesday 08 May 2013 07:13:41 Bob Fischer wrote: > > So, the problem does not appear to be the command line libtool is > > generating. I.e., the problem appears to be elsewhere. > > 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. of course you can use a different GNU ld. build & install a different binutils package yourself. and file a bug with the SUSE maintainers. -mike
[signature.asc (application/pgp-signature, inline)]
bug-libtool <at> gnu.org:bug#14364; Package libtool.
(Wed, 08 May 2013 15:49:02 GMT) Full text and rfc822 format available.bug-libtool <at> gnu.org:bug#14364; Package libtool.
(Wed, 08 May 2013 21:01:01 GMT) Full text and rfc822 format available.Message #20 received at 14364 <at> debbugs.gnu.org (full text, mbox):
From: Peter Rosin <peda <at> lysator.liu.se> To: Bob Fischer <rpf2116 <at> columbia.edu> Cc: 14364 <at> debbugs.gnu.org Subject: Re: bug#14364: Bug Report: Lacking '=' when specifying -soname Date: Wed, 08 May 2013 23:00:11 +0200
On 2013-05-08 13:13, Bob Fischer wrote: >> >> >> So, the problem does not appear to be the command line libtool is >> generating. I.e., the problem appears to be elsewhere. > > 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 I'm sure there are other places you can patch to make this work. > 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. 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. > 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? Maybe, doesn't sound too exotic, but it's not my area of expertise. > I'd also be relatively happy if there was a way I could build the configure.ac file to work around this problem --- in essence, override the '-soname' with '-soname=' coming from the standard libtool. However, libtool looks like it's a little all-or-nothing, and not quite amenable to incremental overrides (hence the see hack). I'm wondering if maybe generating '-soname=' for specific versions of SUSE ld would be the most expedient way to solve this problem. I'm not so sure the SLES ld is to blame, it even seems unlikely. Cheers, Peter
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.