Re: libtool C++ link bug with -lm functions with Sun Workshop compiler
On Wed, Mar 19, 2008 at 07:03:38PM -0500, Tim Mooney wrote: I think I have discovered a bug in libtool's link behavior with the Sun Workshop C++ compiler when creating a C++ library that requires libm. I observed it on x86_64-sun-solaris2.10, but it may also affect the Workshop C++ compiler on Linux too. I found it when trying to build GNU aspell 0.60.5. What version of Sun C++ are you using? If you have a configure.ac that calls AC_LANG([C++]), any subsequent AC_CHECK_FUNCS will result in a link that uses the C++ compiler. Because the C++ compiler initiates the link, it automatically adds some libraries to the final call to ld. Which libraries it adds depends on what flags CC was passed (arguments like -library=stlport4 change what C++ libraries are automatically added). The C++ compiler appears to always add `-lm -lc' after the C++ libraries, though. That means that doing something like AC_INIT(lttest, 0.60.5) AC_CONFIG_SRCDIR(configure.ac) AC_PROG_CXX AC_LANG([C++]) AC_CHECK_FUNCS(sqrt) AC_OUTPUT will always detect sqrt(), because the C++ compiler added `-lm -lc' behind the scenes. When libtool is called to generate a C++ library on Solaris, it doesn't add -lm, though. It only adds -lc. That will result in link failures if functions like sqrt(), floor(), etc. from libm are used by the C++ library. But if Sun C++ automatically adds -lm -lc, why, with libtool using C++ to link the library, isn't -lm -lc automatically added? Because Sun C++ is creating a library and not a program? -- albert chin ([EMAIL PROTECTED]) ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: why does libtool reorder -Wl, arguments to the end making -Wl, --as-needed unusable
On Sun, Mar 02, 2008 at 07:42:53PM -0600, Albert Chin wrote: On Mon, Mar 03, 2008 at 02:02:09AM +0200, Petteri Räty wrote: Albert Chin kirjoitti: On Thu, Feb 28, 2008 at 03:17:54PM +0200, Petteri Räty wrote: [EMAIL PROTECTED] /mnt/checkouts/classpath/native/jni/qt-peer $ make make all-am make[1]: Entering directory `/mnt/checkouts/classpath/native/jni/qt-peer' /bin/sh ../../../libtool --tag=CXX --mode=link g++ -DQT_SHARED -I/usr/include/qt4 -I/usr/include/qt4/QtCore -I/usr/include/qt4/QtGui -g -O2 -module -version-info 0:0:0 -no-undefined -avoid-version -Wl,--as-needed -o libqtpeer.la -rpath /usr/local/classpath/lib/classpath ... [snip snip] --as-needed needs to come before the object files and libs to be effective but libtool moves it to the end. This happens with both 1.5.26 and cvs head. The fact that libtool reorders _any_ of the command-line is a bug. I think Ralf has a fix for this but I don't think it'll happen until 2.1 or 2.2. Still there in libtool 2.2 I forgot we skipped 2.0. So, that means I don't think it'll happen until 2.3 or 2.4 http://lists.gnu.org/archive/html/libtool-patches/2006-06/msg00033.html http://lists.gnu.org/archive/html/libtool-patches/2006-01/msg00061.html http://wiki.azazil.net/GnuLibtoolProject/RoadMap: Preserve the order of the command-line and make changes in-place, if required. -- albert chin ([EMAIL PROTECTED]) ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: why does libtool reorder -Wl, arguments to the end making -Wl, --as-needed unusable
On Mon, Mar 03, 2008 at 02:02:09AM +0200, Petteri Räty wrote: Albert Chin kirjoitti: On Thu, Feb 28, 2008 at 03:17:54PM +0200, Petteri Räty wrote: [EMAIL PROTECTED] /mnt/checkouts/classpath/native/jni/qt-peer $ make make all-am make[1]: Entering directory `/mnt/checkouts/classpath/native/jni/qt-peer' /bin/sh ../../../libtool --tag=CXX --mode=link g++ -DQT_SHARED -I/usr/include/qt4 -I/usr/include/qt4/QtCore -I/usr/include/qt4/QtGui -g -O2 -module -version-info 0:0:0 -no-undefined -avoid-version -Wl,--as-needed -o libqtpeer.la -rpath /usr/local/classpath/lib/classpath ... [snip snip] --as-needed needs to come before the object files and libs to be effective but libtool moves it to the end. This happens with both 1.5.26 and cvs head. The fact that libtool reorders _any_ of the command-line is a bug. I think Ralf has a fix for this but I don't think it'll happen until 2.1 or 2.2. Still there in libtool 2.2 I forgot we skipped 2.0. So, that means I don't think it'll happen until 2.3 or 2.4 -- albert chin ([EMAIL PROTECTED]) ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: why does libtool reorder -Wl, arguments to the end making -Wl, --as-needed unusable
On Thu, Feb 28, 2008 at 03:17:54PM +0200, Petteri Räty wrote: [EMAIL PROTECTED] /mnt/checkouts/classpath/native/jni/qt-peer $ make make all-am make[1]: Entering directory `/mnt/checkouts/classpath/native/jni/qt-peer' /bin/sh ../../../libtool --tag=CXX --mode=link g++ -DQT_SHARED -I/usr/include/qt4 -I/usr/include/qt4/QtCore -I/usr/include/qt4/QtGui -g -O2 -module -version-info 0:0:0 -no-undefined -avoid-version -Wl,--as-needed -o libqtpeer.la -rpath /usr/local/classpath/lib/classpath ... [snip snip] --as-needed needs to come before the object files and libs to be effective but libtool moves it to the end. This happens with both 1.5.26 and cvs head. The fact that libtool reorders _any_ of the command-line is a bug. I think Ralf has a fix for this but I don't think it'll happen until 2.1 or 2.2. -- albert chin ([EMAIL PROTECTED]) ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Link error for blahS.c when used in multiple GCC environment.
On Sat, Mar 31, 2007 at 11:53:12AM +1000, Brendon Costa wrote: Development GCC that i compile from GCC 4.0.1 sources: Version: 4.0.1 Prefix: /home/bcosta/build/install_gcc libstdc++: /home/bcosta/build/install_gcc/lib/libstdc++.so (libstdc++ version: 6.5) When i want to build using the development GCC i do the following: export PATH=/home/bcosta/build/install_gcc/bin:$PATH export LD_LIBRARY_PATH=/home/bcosta/build/install_gcc/lib:$LD_LIBRARY_PATH What if you also set LDFLAGS=-L/home/bcosta/build/install_gcc/lib? -- albert chin ([EMAIL PROTECTED]) ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: no .so file on HPUX platform?
On Mon, Jan 29, 2007 at 04:11:07PM -0700, Ed Hartnett wrote: Ralf Wildenhues [EMAIL PROTECTED] writes: * Ed Hartnett wrote on Mon, Jan 22, 2007 at 09:31:36PM CET: I only have this one HPUX system to test on, and it's pretty out of date, I suspect. But if I ask them to upgrade it, they'll probably just say Nah, let's just get rid of it... Do you have aCC installed there? If yes, could you try to build netcdf with it? Over here it's chosen, rather than CC, as C++ compiler. OK, this gave me the clue to try with with CXX=g++. This allows libtool to continue to build shared libraries. But there is still a problem, alas! Can anyone tell me why this link is failing? /bin/sh ../libtool --tag=CC--mode=link cc -g -version-info 4:0:0 -no-undefined -o libnetcdf.la -rp\ ath /usr/local/lib attr.lo ncx.lo putget.lo dim.lo error.lo libvers.lo nc.lo string.lo v1hpg.lo var.lo posixio.l\ o libtool: link: cc -b -Wl,+h -Wl,libnetcdf.sl.4 -Wl,+b -Wl,/usr/local/lib -o .libs/libnetcdf.sl.4.0 .libs/attr.o .l\ ibs/ncx.o .libs/putget.o .libs/dim.o .libs/error.o .libs/libvers.o .libs/nc.o .libs/string.o .libs/v1hpg.o .libs/va\ r.o .libs/posixio.o -lc cc: warning 422: Unknown option b ignored. /usr/ccs/bin/ld: Unsatisfied symbols: main (Not referenced yet! Probably due to -u option) While you set CXX=g++, did you set CC=gcc? If not, then the default bundled compiler, cc, would be selected. And, it cannot be used to build shared libraries. So, just add CC=gcc. -- albert chin ([EMAIL PROTECTED]) ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Sun Studio 11 request ...
On Fri, Nov 03, 2006 at 10:29:00AM -0800, Edward Maros wrote: I am using 1.5.22 of libtool and noticed that libtool hard codes -lCstd and -lCrun. It would be better for libtool to use -library=Cstd by default and allow the user to over write if they pass -library on the command line. This is an issue for me as I need the stlport4 library's definition of the std C++ library. I have had to had patch libtool for several packages (including my own) because of this limitation. The latest version in CVS (both for 1.5 branch and HEAD) does this. -- albert chin ([EMAIL PROTECTED]) ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: interdependent shared library problem
On Sun, Oct 15, 2006 at 08:53:41PM +0100, Patrick Welche wrote: With CVS autotools of this month I am getting in a pickle trying to build a program which depends on a shared library which depends on a shared library. This is on NetBSD which uses rpath. An example based on one from autobook is attached which builds hello - libhello - (libSM,libICE) .libs/libhello.so seems fine (objdump -x): NEEDED libSM.so.6 NEEDED libICE.so.6 SONAME libhello.so.0 RPATH /usr/X11R6/lib but the binary .libs/hello seems less happy: NEEDED libhello.so.0 NEEDED libSM.so.6 NEEDED libICE.so.6 NEEDED libc.so.12 RPATH /usr/local/lib What does the dependency_libs variable in libhello.la look like? Does an ldd on libhello.so.0 find the correct libraries? so on execution libSM and libICE won't be found. Because /usr/X11R6/lib isn't in the default set of paths searched by the loader? -- albert chin ([EMAIL PROTECTED]) ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Splitting dependency_libs in *.la?
On Tue, Oct 03, 2006 at 08:16:47AM -0500, Rex Dieter wrote: Albert Chin wrote: I don't see how libtool can intelligently decide the minimum set of libraries needed to satisfy the link. pkgconfig has both Libs = Libs.private = The latter being for private and/or static linking. libtool needs something similar to pkgconfig's Libs.private. This, coupled with setting link_all_deplibs=no in the non-static case (ie, see the debian patch referenced earlier in this thread), should pretty much do the trick, afaict. And how do you handle the inherited_linker_flags variable in .la files? There seems to be a pkg-config competitor as well: https://realityforge.vrsource.org/view/FlagPoll/WebHome -- albert chin ([EMAIL PROTECTED]) ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Splitting dependency_libs in *.la?
On Tue, Oct 03, 2006 at 09:14:37PM +0200, Kurt Roeckx wrote: Also, libtool has a problem with it, since it can reorder things. See http://bugs.debian.org/347650 Yeah, reordering of command-line args is not nice. I think Ralf has a patch to fix this but it's post-2.0 work. -- albert chin ([EMAIL PROTECTED]) ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Splitting dependency_libs in *.la?
On Mon, Oct 02, 2006 at 09:00:36PM +0200, Kurt Roeckx wrote: On Mon, Oct 02, 2006 at 01:51:58PM +0200, Axel Thimm wrote: Can this be somehow dealt with within libtool? It would need to fork the semantics of dependency_libs into static vs shared libs or something similar. I guess the difficult part is identifying what parts of dependency_libs are needed for a shared build against this library. Debian has a patch that sets link_all_deplibs to no. This basicly doesn't use dependency_libs for shared linking. Note that this causes various problems for which there are open bugs in the Debian bug tracking system. Because of this, Debian is more and more moving from .la files to using pkg-config's .pc files, which contains the info we need, and also has cflags (-Is) in it. If you add LDFLAGS=-Wl,--as-needed, then linking against dependency_libs shouldn't matter. But, that only helps if you use a recent version of GNU ld. And, even for .pc files, it doesn't mean you get _only_ the libraries you need. What if someone has Requires: -lpng -lz in a .pc file? Then you have a dependency on libpng and libz, which is unnecessary as libpng already depends on libz. I don't see how libtool can intelligently decide the minimum set of libraries needed to satisfy the link. -- albert chin ([EMAIL PROTECTED]) ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: cannot install...to a directory not ending in
On Fri, Sep 22, 2006 at 05:26:07PM -0400, Jeff Blaine wrote: I tried DESTDIR. It doesn't do what I want. If I specify % ./configure --prefix=/usr/local % make % make install DESTDIR=/blah/blah ...then the install process builds out /blah/blah/usr/local. We can't use that. Let me explain better what it is I am doing. The players that are relevant to this particular issue: 1. /afs/blah/dest/sun4x_59/local/bison/1875 The installed destination for a bison build. We build everything as follows, and always have: ./configure --prefix=/usr/local make make install prefix=/afs/blah/dest/sun4x_59/local/bison/1875 After that build, /afs/blah/dest/sun4x_59/local/bison/1875 looks like: % ls bin/info/ lib/man/share/ % Disregard that I am using bison as an example. It's only an example. Then how about: % ./configure --prefix=/ % make % make install DESTDIR=/blah/blah -- albert chin ([EMAIL PROTECTED]) ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: cannot install...to a directory not ending in
On Fri, Sep 22, 2006 at 04:52:27PM -0500, Albert Chin wrote: On Fri, Sep 22, 2006 at 05:26:07PM -0400, Jeff Blaine wrote: I tried DESTDIR. It doesn't do what I want. If I specify % ./configure --prefix=/usr/local % make % make install DESTDIR=/blah/blah ...then the install process builds out /blah/blah/usr/local. We can't use that. Let me explain better what it is I am doing. The players that are relevant to this particular issue: 1. /afs/blah/dest/sun4x_59/local/bison/1875 The installed destination for a bison build. We build everything as follows, and always have: ./configure --prefix=/usr/local make make install prefix=/afs/blah/dest/sun4x_59/local/bison/1875 After that build, /afs/blah/dest/sun4x_59/local/bison/1875 looks like: % ls bin/info/ lib/man/share/ % Disregard that I am using bison as an example. It's only an example. Then how about: % ./configure --prefix=/ % make % make install DESTDIR=/blah/blah Sorry, disregard this foolish suggestion. -- albert chin ([EMAIL PROTECTED]) ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: HP-UX module linking problem
On Tue, Sep 19, 2006 at 10:11:36AM +0200, Kent Boortz wrote: Albert Chin [EMAIL PROTECTED] writes: snip So, in both cases, libz is not on the command-line used to create the shared library. Yes, what I meant was that I took the cc line libtool expand to, inserted -lmysqlclient and tried link it manually. and it worked. Making me beleive it is a libtool problem. Well, I suppose you could argue libtool should exit(1) rather than stripping libraries from the command-line in this case. Looking inside the libtool command and Googling a bit more, I found an ugly way around this. After generating the configure script, I change it to say hpux10.20* | hpux11*) lt_cv_deplibs_check_method=pass_all This makes it let -lmysqlclient pass on, I found no way to force this using any command line flag. Correct. Some systems like AIX and Tru64 UNIX generate PIC for all object files. -- albert chin ([EMAIL PROTECTED]) ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: wgcc 2.0 RC1 released
On Tue, Sep 19, 2006 at 11:05:25AM +0200, Duft Markus wrote: For all interested in native Windows binaries built with Autotools and mnay other interesting things: wgcc is a cross-compiler tool primarily written for Microsoft's Interix. Its primary purpose is to produce native Windows binaries (internally using the Microsoft Tool chain), and to mimic the behaviour of the GNU compiler collection. This means that wgcc understands many of GCC's command line arguments, and in most cases delivers the same results as expected, sometimes manipulating the underlying tool's input and output. So, with this tool, someone doesn't need the cccl Visual C++ wrapper: http://cccl.sourceforge.net/ -- albert chin ([EMAIL PROTECTED]) ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: deploying libraries and executables from a staging area
On Tue, Sep 19, 2006 at 03:32:58PM -0700, Noel Yap wrote:
What are the proper incantations to deploy libraries and executables
from a staging area (such that the rpath correctly points to the
deployment area)?
The following doesn't seem to work:
./libtool --mode=install install ${la} ${destination}/lib/${l}
./libtool --mode=finish ${destination}/lib/${l}
./libtool --mode=install install ${exe} ${destination}/bin/${x}
./libtool --mode=finish ${destination}/bin/${x}
Look at the libtool documentation for -inst-prefix and DESTDIR.
--
albert chin ([EMAIL PROTECTED])
___
http://lists.gnu.org/mailman/listinfo/libtool
Re: deploying libraries and executables from a staging area
On Tue, Sep 19, 2006 at 05:18:08PM -0700, Noel Yap wrote:
On 9/19/06, Albert Chin [EMAIL PROTECTED] wrote:
On Tue, Sep 19, 2006 at 03:32:58PM -0700, Noel Yap wrote:
What are the proper incantations to deploy libraries and executables
from a staging area (such that the rpath correctly points to the
deployment area)?
The following doesn't seem to work:
./libtool --mode=install install ${la} ${destination}/lib/${l}
./libtool --mode=finish ${destination}/lib/${l}
./libtool --mode=install install ${exe}
${destination}/bin/${x}
./libtool --mode=finish ${destination}/bin/${x}
Look at the libtool documentation for -inst-prefix and DESTDIR.
I read that documentation. It's not that clear to someone new to
libtool and automake especially since the canonical way to release the
product is via configure and make.
I think DESTDIR is to be thought of as a virtual root. I don't know if
this mimics what you want. So, if you:
$ ./configure --prefix=/usr/local
and you want it installed to the /nfs/stage1 staging directory,
you'd:
$ make install DESTDIR=/nfs/stage1
From my reading of DESTDIR in the libtool manual, this should install
the software in /nfs/stage1/usr/local, with the RPATH configured for
/usr/local.
--
albert chin ([EMAIL PROTECTED])
___
http://lists.gnu.org/mailman/listinfo/libtool
Re: HP-UX module linking problem
On Tue, Sep 19, 2006 at 12:29:50AM +0200, Kent Boortz wrote: On HP-UX 11.11 PA-RISC I try create a module that is loadable using libltdl. When creating the module, I try link against a static library libmysqlclient. This fails. OS : HP-UX B.11.11 (hppa) c.guess : hppa2.0w-hp-hpux11.11 libtool : 1.5.22 cc : HP92453-01 B.11.11.12 HP C Compiler ld : HP92453-07 B.11.41 040909 The final link does (removing the -Ipath, -Lpath and optimizer flags) % /bin/sh ../libtool --tag=CC --mode=link cc +DAportable -g \ -o libmyodbc3_r.la -rpath rpath -release 3.51.13 .lo-files \ ../myodbc3u/libmyodbc3u.la ../MYODBCDbg/MYODBCDbgLib/libMYODBCDbg.la \ instbase/libtool/lib/libltdl.la -lmysqlclient_r \ -lz -lpthread -lnsl -lm -liodbcinst libmysqlclient_r is a static library compiled with --with-pic, i.e. +Z. libiodbcinst is a shared library. Libtool complains with *** Warning: This system can not link to static lib archive /home/mysqldev/odbc/inst/libtool/lib/libltdl.la. *** 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 do not appear to have. *** Warning: Trying to link with static lib archive libmysqlclient_r.a. *** 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 do not appear to have *** because the file extensions .a of this argument makes me believe *** that it is just a static archive that I should not used here. but produces a shared library, just *without* libmysqlclient_r.If I copy the expanded link line and insert path/libmysqlclient_r.a, it links ok, So why this complaint? How to I convince libtool not to remove this static library from the generated link line? I don't get it. I'm not getting the same results: $ file /opt/TWWfsw/zlib11s/lib/libz.a /opt/TWWfsw/zlib11s/lib/libz.a: archive file -PA-RISC1.1 relocatable library Using the latest libtool-1.5 from CVS: $ /opt/TWWfsw/libtool15/bin/libtool --mode=link cc -g a.lo \ -L/opt/TWWfsw/zlib11s/lib -lz -rpath /tmp/ti -o liba.la *** Warning: This system can not link to static lib archive /opt/TWWfsw/zlib11s/lib/libz.la. *** 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 do not appear to have. rm -fr .libs/liba.a .libs/liba.la .libs/liba.lai .libs/liba.sl .libs/liba.sl.0 .libs/liba.sl.0.0 cc -b -Wl,+h -Wl,liba.sl.0 -Wl,+b -Wl,/tmp/ti -o .libs/liba.sl.0.0 .libs/a.o -L/opt/TWWfsw/zlib11s/lib -lc (cd .libs rm -f liba.sl.0 ln -s liba.sl.0.0 liba.sl.0) (cd .libs rm -f liba.sl ln -s liba.sl.0.0 liba.sl) ar cru .libs/liba.a a.o ranlib .libs/liba.a creating liba.la (cd .libs rm -f liba.la ln -s ../liba.la liba.la) $ /opt/TWWfsw/libtool15/bin/libtool --mode=link cc -g a.lo \ /opt/TWWfsw/zlib11s/lib/libz.a -rpath /tmp/ti -o liba.la *** Warning: Trying to link with static lib archive /opt/TWWfsw/zlib11s/lib/libz.a. *** 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 do not appear to have *** because the file extensions .a of this argument makes me believe *** that it is just a static archive that I should not used here. rm -fr .libs/liba.a .libs/liba.la .libs/liba.lai .libs/liba.sl .libs/liba.sl.0 .libs/liba.sl.0.0 cc -b -Wl,+h -Wl,liba.sl.0 -Wl,+b -Wl,/tmp/ti -o .libs/liba.sl.0.0 .libs/a.o -lc (cd .libs rm -f liba.sl.0 ln -s liba.sl.0.0 liba.sl.0) (cd .libs rm -f liba.sl ln -s liba.sl.0.0 liba.sl) ar cru .libs/liba.a /opt/TWWfsw/zlib11s/lib/libz.a a.o /opt/TWWfsw/zlib11s/lib/libz.a ranlib .libs/liba.a creating liba.la (cd .libs rm -f liba.la ln -s ../liba.la liba.la) So, in both cases, libz is not on the command-line used to create the shared library. On HP-UX, lib*.a libraries are always static archives, regardless of how the members were compiled. If you want to link in libmysqlclient_r, I think your only solution is to build it as part of whatever program you're building but create it as a convenience library. -- albert chin ([EMAIL PROTECTED]) ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: cygwin convenience library -dlpreopen installation
On Fri, Sep 08, 2006 at 02:31:06PM -0600, Eric Blake wrote: Then perhaps the right fix is making -dlpreopen on Windows be a key that the convenience library .dll must be installed alongside the final image in PATH. But -dlpreopen isn't used on the command-line to install the program. -- albert chin ([EMAIL PROTECTED]) ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: cygwin convenience library -dlpreopen installation
On Fri, Sep 08, 2006 at 04:14:27PM -0600, Eric Blake wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Albert Chin on 9/8/2006 3:54 PM: On Fri, Sep 08, 2006 at 02:31:06PM -0600, Eric Blake wrote: Then perhaps the right fix is making -dlpreopen on Windows be a key that the convenience library .dll must be installed alongside the final image in PATH. But -dlpreopen isn't used on the command-line to install the program. But isn't it stored in the .la files associated with the program? Ah yes, sorry! -- albert chin ([EMAIL PROTECTED]) ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Supporting -export-dynamic on AIX
On Tue, Aug 08, 2006 at 02:58:44PM -0500, Albert Chin wrote:
Another version. Patch against branch-1-5 only. I've reordered where
--export-dynamic occurs so we don't have to worry about the above.
Our use of both $export_dynamic_symbols_cmds and
$export_dynamic_flag_spec somewhat breaks the whether a program can
dlopen itself test:
case $lt_cv_dlopen in
dlopen)
save_CPPFLAGS=$CPPFLAGS
test x$ac_cv_header_dlfcn_h = xyes CPPFLAGS=$CPPFLAGS -DHAVE_DLFCN_H
save_LDFLAGS=$LDFLAGS
wl=$lt_prog_compiler_wl eval LDFLAGS=\\$LDFLAGS $export_dynamic_flag_spec\
...
Why? Because we set $export_dynamic_flag_spec to:
_LT_AC_TAGVAR(export_dynamic_flag_spec,
$1)=\${wl}$exp_sym_flag:\$export_symbols
so, in the above LDFLAGS=$LDFLAGS -Wl,-bexport:. Because -bexport:
requires an argument, we get an error from the linker:
ld: 0706-015 The -b export option needs a parameter.
Option syntax: -b export:PARM
We could make this test pass by creating conftest.exp, setting
export_symbols=conftest.exp, and adding fnord to it:
save_LDFLAGS=$LDFLAGS
echo fnord conftest.exp
wl=$lt_prog_compiler_wl export_symbols=conftest.exp \
eval LDFLAGS=\\$LDFLAGS $export_dynamic_flag_spec\
Should we do this or let it continue failing?
--
albert chin ([EMAIL PROTECTED])
Re: Supporting -export-dynamic on AIX
On Tue, Aug 08, 2006 at 02:58:44PM -0500, Albert Chin wrote:
Another version. Patch against branch-1-5 only. I've reordered where
--export-dynamic occurs so we don't have to worry about the above.
Our use of both $export_dynamic_symbols_cmds and
$export_dynamic_flag_spec somewhat breaks the whether a program can
dlopen itself test:
case $lt_cv_dlopen in
dlopen)
save_CPPFLAGS=$CPPFLAGS
test x$ac_cv_header_dlfcn_h = xyes CPPFLAGS=$CPPFLAGS -DHAVE_DLFCN_H
save_LDFLAGS=$LDFLAGS
wl=$lt_prog_compiler_wl eval LDFLAGS=\\$LDFLAGS $export_dynamic_flag_spec\
...
Why? Because we set $export_dynamic_flag_spec to:
_LT_AC_TAGVAR(export_dynamic_flag_spec,
$1)=\${wl}$exp_sym_flag:\$export_symbols
so, in the above LDFLAGS=$LDFLAGS -Wl,-bexport:. Because -bexport:
requires an argument, we get an error from the linker:
ld: 0706-015 The -b export option needs a parameter.
Option syntax: -b export:PARM
We could make this test pass by creating conftest.exp, setting
export_symbols=conftest.exp, and adding fnord to it:
save_LDFLAGS=$LDFLAGS
echo fnord conftest.exp
wl=$lt_prog_compiler_wl export_symbols=conftest.exp \
eval LDFLAGS=\\$LDFLAGS $export_dynamic_flag_spec\
Should we do this or let it continue failing?
--
albert chin ([EMAIL PROTECTED])
___
http://lists.gnu.org/mailman/listinfo/libtool
-dlopen self on AIX
Does -dlopen self work on AIX? While building epiphany-1.6.5 on this
platform, seems that not all the correct symbols are being exported.
On AIX 5.3, dlopen_self=no. If -dlopen self is specified, then the
following code is executed (from the 1.5 branch):
if test $dlself = yes; then
$show generating symbol list for \`$output'
test -z $run $echo ': @PROGRAM@ ' $nlist
# Add our own program objects to the symbol list.
progfiles=`$echo X$objs$old_deplibs | $SP2NL | $Xsed -e $lo2o |
$NL2SP`
for arg in $progfiles; do
$show extracting global C symbols from \`$arg'
$run eval $NM $arg | $global_symbol_pipe '$nlist'
done
...
First, if noinst_LTLIBRARIES *.la files are specified on the
command-line, their symbol list will not be searched because the only
files searched for symbols is X$objs$old_deplibs. This should really
be X$objs$libobjs$old_deplibs$old_convenience.
Running the link line and the progfiles change I get:
$ ../libtool --mode=link xlC_r -O2 -qro -qroconst -qmaxmem=-1
-qarch=com -L/opt/TWWfsw/gettext014/lib -Wl,-brtl
-o epiphany -R/opt/TWWfsw/firefox15/lib -dlopen
self epiphany-ephy-main.o libephymain.la
../src/bookmarks/libephybookmarks.la ../embed/libephyembedfactory.la
../embed/mozilla/libephymozillaembed.la ../embed/libephyembed.la
../lib/widgets/libephywidgets.la ../lib/libephymisc.la
../lib/egg/libegg.la -L/opt/TWWfsw/firefox15/lib -lgtkembedmoz
-lxpcom -lxpcom_core -lplds4 -lplc4 -lnspr4 -lpthreads -ldl ...
rm -f .libs/epiphany.nm .libs/epiphany.nmS .libs/epiphany.nmT
creating .libs/epiphanyS.c
generating symbol list for `epiphany'
extracting global C symbols from `epiphany-ephy-main.o'
extracting global C symbols from `./.libs/libephymain.a'
extracting global C symbols from `../src/bookmarks/.libs/libephybookmarks.a'
extracting global C symbols from `../embed/.libs/libephyembedfactory.a'
extracting global C symbols from
`../embed/mozilla/.libs/libephymozillaembed.a'
extracting global C symbols from `../embed/.libs/libephyembed.a'
extracting global C symbols from `../lib/widgets/.libs/libephywidgets.a'
extracting global C symbols from `../lib/.libs/libephymisc.a'
extracting global C symbols from `../lib/egg/.libs/libegg.a'
(cd .libs xlc_r -O2 -qro -qroconst -qmaxmem=-1 -qarch=com -c epiphanyS.c)
rm -f .libs/epiphanyS.c .libs/epiphany.nm .libs/epiphany.nmS
.libs/epiphany.nmT
xlC_r -O2 -qro -qroconst -qmaxmem=-1 -qarch=com -brtl
-o epiphany .libs/epiphanyS.o epiphany-ephy-main.o
-L/opt/TWWfsw/gettext014/lib ./.libs/libephymain.a
../src/bookmarks/.libs/libephybookmarks.a
../embed/.libs/libephyembedfactory.a
../embed/mozilla/.libs/libephymozillaembed.a
../embed/.libs/libephyembed.a ../lib/widgets/.libs/libephywidgets.a
../lib/.libs/libephymisc.a ../lib/egg/.libs/libegg.a
-L/opt/TWWfsw/firefox15/lib -lgtkembedmoz -lxpcom -lxpcom_core -lplds4
-lplc4 -lnspr4 -lpthreads -ldl ...
One of the symbols not being exported is
language_editor_up_button_clicked_cb. So, let's check out the above:
$ grep language_editor_up_button_clicked_cb .libs/epiphanyS.c
{language_editor_up_button_clicked_cb, (lt_ptr)
language_editor_up_button_clicked_cb},
$ nm -BCpg .libs/epiphanyS.o | grep language_editor_up_button_clicked_cb
- U language_editor_up_button_clicked_cb
$ nm -BCpg epiphany | grep language_editor_up_button_clicked_cb
269185316 T .language_editor_up_button_clicked_cb
But what I want is the following:
$ nm -BCpg epiphany | grep language_editor_up_button_clicked_cb
269185316 T .language_editor_up_button_clicked_cb
536936672 D language_editor_up_button_clicked_cb
--
albert chin ([EMAIL PROTECTED])
___
http://lists.gnu.org/mailman/listinfo/libtool
Re: -dlopen self and optimizing away symbols
On Thu, Aug 17, 2006 at 08:22:08AM +0200, Ralf Wildenhues wrote: * Albert Chin wrote on Thu, Aug 17, 2006 at 07:55:14AM CEST: On Thu, Aug 17, 2006 at 07:42:00AM +0200, Ralf Wildenhues wrote: But say, why is -Wl,-E not passed to the link line? It should be export_dynamic_flag_spec. And it should have the desired effect: | -E Mark all symbols defined by a program for export | to shared libraries. In a +compat mode link, ld | marks only those symbols that are actually | referenced by a shared library seen at link time. | In a +std link, all symbols are exported by | default, so -E is not necessary to make symbols | visible. However, it has an additional side | effect of identifying all exported symbols as | necessary, so that they will not be removed when | using dead code elimination (+Oprocelim). Because -export-dynamic is not specified. It should not need to be. IOW, either the Libtool documentation or the implementation is broken: | `-dlopen FILE' | Same as `-dlpreopen FILE', if native dlopening is not supported on | the host platform (*note Dlopened modules::) or if the program is | linked with `-static', `-static-libtool-libs', or `-all-static'. | Otherwise, no effect. If FILE is `self' Libtool will make sure | that the program can `dlopen' itself, either by enabling | `-export-dynamic' or by falling back to `-dlpreopen self'. But anyway, if you have other modules, you should specify -export-dynamic, I think. At least I can't infer from the above snippet that `-dlopen self' would be sufficient. What do you think? I agree. I think the program in question should be linked with `-export-dynamic'. I'll ping the developers and try to find out why they're using `-dlopen self'. In any case, we need to find a fix as `-dlopen self' works on AIX but `-export-dynamic' does not. Otherwise, -Wl,+Onoprocelim should be the hammer we're looking for, I guess; but that should not even be necessary, given above documentation (from ld(1)). Well, export_dynamic_flag_spec isn't even looked at when -dlopen self is being handled. Maybe it should and only use the -dlopen self code when export_dynamic_flag_spec is empty? I still need to look at that code. Ok, I should have looked closer. The documentation is correct: case $prev in dlfiles|dlprefiles) ... case $arg in *.la | *.lo) ;; # We handle these cases below. force) ... self) if test $prev = dlprefiles; then dlself=yes elif test $prev = dlfiles test $dlopen_self != yes; then dlself=yes else dlself=needless export_dynamic=yes fi prev= continue ;; On HP-UX 11.23/IA, dlopen_self=unknown. Hence, we never set export_dynamic=yes. Why isn't export_dynamic=yes on this platform? Because lt_cv_dlopen!=dlopen as we prefer shl_load rather than dlopen (this change was made a long time ago because on HP-UX 11.00, dlopen() required a patch while shl_load() is always available): http://lists.gnu.org/archive/html/libtool/2001-04/msg00221.html Because of this, the following code never gets executed: case $lt_cv_dlopen in dlopen) save_CPPFLAGS=$CPPFLAGS test x$ac_cv_header_dlfcn_h = xyes CPPFLAGS=$CPPFLAGS -DHAVE_DLFCN_H save_LDFLAGS=$LDFLAGS wl=$lt_prog_compiler_wl eval LDFLAGS=\\$LDFLAGS $export_dynamic_flag_spec\ save_LIBS=$LIBS LIBS=$lt_cv_dlopen_libs $LIBS AC_CACHE_CHECK([whether a program can dlopen itself], lt_cv_dlopen_self, [dnl _LT_AC_TRY_DLOPEN_SELF( lt_cv_dlopen_self=yes, lt_cv_dlopen_self=yes, lt_cv_dlopen_self=no, lt_cv_dlopen_self=cross) ]) So, what do we do? Revert the dlopen() change and agree that enough time has passed and all HP-UX 11.x users should have the dlopen() patch? It's been 5 years so I say we can now prefer dlopen! Or do we do the above _and_ try to fix this somehow? It doesn't seem to be a problem on HP-UX 10.20 which uses shl_load(). -- albert chin ([EMAIL PROTECTED]) ___ http://lists.gnu.org/mailman/listinfo/libtool
-dlopen self and optimizing away symbols
Just built openldap-2.3.25 on HP-UX 11.23/IA. 'make check' fails because a symbol wasn't available in the main binary which dlopen()'ed a module that required the symbol. The main binary was built with -dlopen self. The problem is, after the symbols were extracted from all .o objects that comprise the main binary, the main binary was then linked with: /bin/sh ../..//libtool --mode=link cc -z +O2 +Onofltacc \ +Olit=all +Oentrysched +DD64 +Odataprefetch +Onolimit +We901 \ -L/opt/TWWfsw/libsasl21/lib/hpux64 \ -L/opt/TWWfsw/libopenssl097/lib/hpux64 \ -L/opt/TWWfsw/libdb42/lib/hpux64 \ -Wl,+b,/opt/TWWfsw/openldap2325lib/hpux64:/opt/TWWfsw/libdb42/lib/hpux64:/opt/TWWfsw/libsasl21/lib/hpux64:/opt/TWWfsw/libopenssl097/lib/hpux64 \ -dlopen self -o slapd main.o globals.o bconfig.o config.o daemon.o connection.o search.o ... rm -f .libs/slapd.nm .libs/slapd.nmS .libs/slapd.nmT creating .libs/slapdS.c generating symbol list for `slapd' extracting global C symbols from `main.o' extracting global C symbols from `globals.o' extracting global C symbols from `bconfig.o' extracting global C symbols from `config.o' extracting global C symbols from `daemon.o' ... (cd .libs cc -z +O2 +Onofltacc +Olit=all +Oentrysched +DD64 +Odataprefetch +Onolimit +We901 -c -DPIC slapdS.c) cc -z +O2 +Onofltacc +Olit=all +Oentrysched +DD64 +Odataprefetch \ +Onolimit +We901 -Wl,+b \ -Wl,/opt/TWWfsw/openldap2325lib/hpux64:/opt/TWWfsw/libdb42/lib/hpux64:/opt/TWWfsw/libsasl21/lib/hpux64:/opt/TWWfsw/libopenssl097/lib/hpux64 \ .libs/slapdS.o -o .libs/slapd main.o globals.o bconfig.o config.o \ daemon.o ... Unfortunately, the HP-UX 11.23/IA compiler, when generating .libs/slapd, will optimize _away_ symbols that are not used by any of the object files being linked: $ nm .libs/slapd | grep backend_add $ nm .libs/slapd | grep backend_group [947]| 4611686018428014688| 176|FUNC |GLOB |0| .text|backend_group $ nm main.o globals.o bconfig.o config.o ... | grep backend_add [129]| 0| 800|FUNC |GLOB |0| .text|backend_add $ nm main.o globals.o bconfig.o config.o ... | grep backend_group [157]| 0| 176|FUNC |GLOB |0| .text|backend_group [71] | 0| 0|FUNC |GLOB |0| UNDEF|backend_group [43] | 0| 0|FUNC |GLOB |0| UNDEF|backend_group How do we solve this? I suppose we could build without CFLAGS but then we'd lose +DD64 for 64-bit objects. -- albert chin ([EMAIL PROTECTED]) ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: -dlopen self and optimizing away symbols
On Thu, Aug 17, 2006 at 07:42:00AM +0200, Ralf Wildenhues wrote: * Albert Chin wrote on Thu, Aug 17, 2006 at 12:39:25AM CEST: Just built openldap-2.3.25 on HP-UX 11.23/IA. 'make check' fails because a symbol wasn't available in the main binary which dlopen()'ed a module that required the symbol. The main binary was built with -dlopen self. Unfortunately, the HP-UX 11.23/IA compiler, when generating .libs/slapd, will optimize _away_ symbols that are not used by any of the object files being linked: Which compiler option causes it to optimize away the symbols? +O2. +O1 and no optimization seem to be ok. Which linker option is that translated to? +O2 passes +Oprocelim to ld. How do we solve this? I suppose we could build without CFLAGS but then we'd lose +DD64 for 64-bit objects. Probably adding a linker flag at the end to undo the dangerous setting should be safest, given there is such a flag. But say, why is -Wl,-E not passed to the link line? It should be export_dynamic_flag_spec. And it should have the desired effect: | -E Mark all symbols defined by a program for export | to shared libraries. In a +compat mode link, ld | marks only those symbols that are actually | referenced by a shared library seen at link time. | In a +std link, all symbols are exported by | default, so -E is not necessary to make symbols | visible. However, it has an additional side | effect of identifying all exported symbols as | necessary, so that they will not be removed when | using dead code elimination (+Oprocelim). Because -export-dynamic is not specified. Otherwise, -Wl,+Onoprocelim should be the hammer we're looking for, I guess; but that should not even be necessary, given above documentation (from ld(1)). Well, export_dynamic_flag_spec isn't even looked at when -dlopen self is being handled. Maybe it should and only use the -dlopen self code when export_dynamic_flag_spec is empty? If not, looks like we'll need to add +Onoprocelim to the cc command-line for HP-UX. What's the best way to do this? A new variable? -- albert chin ([EMAIL PROTECTED]) ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Supporting -export-dynamic on AIX
On Sun, Jul 02, 2006 at 10:58:23PM +0900, Peter O'Gorman wrote:
On Tue, 2006-06-20 at 12:12 -0500, Albert Chin wrote:
Albert also questioned the documentation:
On some operating systems, a program symbol must be specially
declared
in order to be dynamically resolved with the `dlsym' (or equivalent)
function.
Libtool provides the `-export-dynamic' and `-module' link flags
(*note Link mode::), which do this declaration. You need to use
these
flags if you are linking an application program that dlopens other
modules or a libtool library that will also be dlopened.
Should the last sentence above end with , respectively?
I think this is a documentation bug. -export-dynamic does not imply
-module, there is a line of code in ltmain that adds dlname to the .la
file if either -module or -export-dynamic was specified, but this only
works if modules and libraries are otherwise equivalent, so it should
probably be removed and the documentation adjusted for HEAD, thoughts?
Either way this patch does not affect that behavior at all.
Here are patches against branch-1-5 and HEAD, okay (with apropriate
ChangeLog, of course)?
Another version. Patch against branch-1-5 only. I've reordered where
--export-dynamic occurs so we don't have to worry about the above.
--
albert chin ([EMAIL PROTECTED])
Index: libtool.m4
===
RCS file: /cvsroot/libtool/libtool/Attic/libtool.m4,v
retrieving revision 1.314.2.162
diff -u -p -r1.314.2.162 libtool.m4
--- libtool.m4 3 Aug 2006 14:31:47 - 1.314.2.162
+++ libtool.m4 8 Aug 2006 13:16:45 -
@@ -2911,6 +2911,13 @@ case $host_os in
exp_sym_flag='-bexport'
no_entry_flag='-bnoentry'
+
+ if $NM -V 21 | grep 'GNU' /dev/null; then
+ _LT_AC_TAGVAR(export_dynamic_symbols_cmds, $1)='$NM -Bpg $objs $libobjs
$old_deplibs $old_convenience | awk '\''{ if (((\[$]2 == T) || (\[$]2 == D)
|| (\[$]2 == B)) ([substr](\[$]3,1,1) != .)) { print \[$]3 } }'\'' |
sort -u $export_symbols'
+ else
+ _LT_AC_TAGVAR(export_dynamic_symbols_cmds, $1)='$NM -BCpg $objs
$libobjs $old_deplibs $old_convenience | awk '\''{ if (((\[$]2 == T) ||
(\[$]2 == D) || (\[$]2 == B)) ([substr](\[$]3,1,1) != .)) { print
\[$]3 } }'\'' | sort -u $export_symbols'
+ fi
+ _LT_AC_TAGVAR(export_dynamic_flag_spec,
$1)=\${wl}$exp_sym_flag:\$export_symbols
fi
# When large executables or shared objects are built, AIX ld can
@@ -3974,6 +3981,7 @@ _LT_AC_TAGVAR(archive_cmds_need_lc, $1)=
_LT_AC_TAGVAR(allow_undefined_flag, $1)=
_LT_AC_TAGVAR(always_export_symbols, $1)=no
_LT_AC_TAGVAR(archive_expsym_cmds, $1)=
+_LT_AC_TAGVAR(export_dynamic_symbols_cmds, $1)=
_LT_AC_TAGVAR(export_dynamic_flag_spec, $1)=
_LT_AC_TAGVAR(hardcode_direct, $1)=no
_LT_AC_TAGVAR(hardcode_libdir_flag_spec, $1)=
@@ -4209,6 +4217,7 @@ if test -f $ltmain; then
_LT_AC_TAGVAR(lt_prog_compiler_pic, $1) \
_LT_AC_TAGVAR(lt_prog_compiler_static, $1) \
_LT_AC_TAGVAR(lt_prog_compiler_no_builtin_flag, $1) \
+_LT_AC_TAGVAR(export_dynamic_symbols_cmds, $1) \
_LT_AC_TAGVAR(export_dynamic_flag_spec, $1) \
_LT_AC_TAGVAR(thread_safe_flag_spec, $1) \
_LT_AC_TAGVAR(whole_archive_flag_spec, $1) \
@@ -4243,6 +4252,7 @@ if test -f $ltmain; then
_LT_AC_TAGVAR(old_archive_from_new_cmds, $1) | \
_LT_AC_TAGVAR(archive_cmds, $1) | \
_LT_AC_TAGVAR(archive_expsym_cmds, $1) | \
+_LT_AC_TAGVAR(export_dynamic_symbols_cmds, $1) | \
_LT_AC_TAGVAR(module_cmds, $1) | \
_LT_AC_TAGVAR(module_expsym_cmds, $1) | \
_LT_AC_TAGVAR(old_archive_from_expsyms_cmds, $1) | \
@@ -4455,6 +4465,7 @@ link_static_flag=$lt_[]_LT_AC_TAGVAR(lt_
no_builtin_flag=$lt_[]_LT_AC_TAGVAR(lt_prog_compiler_no_builtin_flag, $1)
# Compiler flag to allow reflexive dlopens.
+export_dynamic_symbols_cmds=$lt_[]_LT_AC_TAGVAR(export_dynamic_symbols_cmds,
$1)
export_dynamic_flag_spec=$lt_[]_LT_AC_TAGVAR(export_dynamic_flag_spec, $1)
# Compiler flag to generate shared objects directly from archives.
@@ -5480,6 +5491,7 @@ ifelse([$1],[CXX],[
_LT_AC_TAGVAR(archive_expsym_cmds, $1)=
_LT_AC_TAGVAR(old_archive_From_new_cmds, $1)=
_LT_AC_TAGVAR(old_archive_from_expsyms_cmds, $1)=
+ _LT_AC_TAGVAR(export_dynamic_symbols_cmds, $1)=
_LT_AC_TAGVAR(export_dynamic_flag_spec, $1)=
_LT_AC_TAGVAR(whole_archive_flag_spec, $1)=
_LT_AC_TAGVAR(thread_safe_flag_spec, $1)=
@@ -5788,8 +5800,11 @@ _LT_EOF
# -C means demangle to AIX nm, but means don't demangle with GNU nm
if $NM -V 21 | grep 'GNU' /dev/null; then
_LT_AC_TAGVAR(export_symbols_cmds, $1)='$NM -Bpg $libobjs
$convenience | awk '\''{ if (((\[$]2 == T) || (\[$]2 == D) || (\[$]2 ==
B)) ([substr](\[$]3,1,1) != .)) { print \[$]3 } }'\'' | sort -u
$export_symbols'
+ _LT_AC_TAGVAR(export_dynamic_symbols_cmds, $1)='$NM -Bpg $objs
$libobjs $old_deplibs $old_convenience | awk
Re: Supporting -export-dynamic on AIX
On Sun, Jul 02, 2006 at 10:58:23PM +0900, Peter O'Gorman wrote:
On Tue, 2006-06-20 at 12:12 -0500, Albert Chin wrote:
Albert also questioned the documentation:
On some operating systems, a program symbol must be specially
declared
in order to be dynamically resolved with the `dlsym' (or equivalent)
function.
Libtool provides the `-export-dynamic' and `-module' link flags
(*note Link mode::), which do this declaration. You need to use
these
flags if you are linking an application program that dlopens other
modules or a libtool library that will also be dlopened.
Should the last sentence above end with , respectively?
I think this is a documentation bug. -export-dynamic does not imply
-module, there is a line of code in ltmain that adds dlname to the .la
file if either -module or -export-dynamic was specified, but this only
works if modules and libraries are otherwise equivalent, so it should
probably be removed and the documentation adjusted for HEAD, thoughts?
Either way this patch does not affect that behavior at all.
Here are patches against branch-1-5 and HEAD, okay (with apropriate
ChangeLog, of course)?
Another version. Patch against branch-1-5 only. I've reordered where
--export-dynamic occurs so we don't have to worry about the above.
--
albert chin ([EMAIL PROTECTED])
Index: libtool.m4
===
RCS file: /cvsroot/libtool/libtool/Attic/libtool.m4,v
retrieving revision 1.314.2.162
diff -u -p -r1.314.2.162 libtool.m4
--- libtool.m4 3 Aug 2006 14:31:47 - 1.314.2.162
+++ libtool.m4 8 Aug 2006 13:16:45 -
@@ -2911,6 +2911,13 @@ case $host_os in
exp_sym_flag='-bexport'
no_entry_flag='-bnoentry'
+
+ if $NM -V 21 | grep 'GNU' /dev/null; then
+ _LT_AC_TAGVAR(export_dynamic_symbols_cmds, $1)='$NM -Bpg $objs $libobjs
$old_deplibs $old_convenience | awk '\''{ if (((\[$]2 == T) || (\[$]2 == D)
|| (\[$]2 == B)) ([substr](\[$]3,1,1) != .)) { print \[$]3 } }'\'' |
sort -u $export_symbols'
+ else
+ _LT_AC_TAGVAR(export_dynamic_symbols_cmds, $1)='$NM -BCpg $objs
$libobjs $old_deplibs $old_convenience | awk '\''{ if (((\[$]2 == T) ||
(\[$]2 == D) || (\[$]2 == B)) ([substr](\[$]3,1,1) != .)) { print
\[$]3 } }'\'' | sort -u $export_symbols'
+ fi
+ _LT_AC_TAGVAR(export_dynamic_flag_spec,
$1)=\${wl}$exp_sym_flag:\$export_symbols
fi
# When large executables or shared objects are built, AIX ld can
@@ -3974,6 +3981,7 @@ _LT_AC_TAGVAR(archive_cmds_need_lc, $1)=
_LT_AC_TAGVAR(allow_undefined_flag, $1)=
_LT_AC_TAGVAR(always_export_symbols, $1)=no
_LT_AC_TAGVAR(archive_expsym_cmds, $1)=
+_LT_AC_TAGVAR(export_dynamic_symbols_cmds, $1)=
_LT_AC_TAGVAR(export_dynamic_flag_spec, $1)=
_LT_AC_TAGVAR(hardcode_direct, $1)=no
_LT_AC_TAGVAR(hardcode_libdir_flag_spec, $1)=
@@ -4209,6 +4217,7 @@ if test -f $ltmain; then
_LT_AC_TAGVAR(lt_prog_compiler_pic, $1) \
_LT_AC_TAGVAR(lt_prog_compiler_static, $1) \
_LT_AC_TAGVAR(lt_prog_compiler_no_builtin_flag, $1) \
+_LT_AC_TAGVAR(export_dynamic_symbols_cmds, $1) \
_LT_AC_TAGVAR(export_dynamic_flag_spec, $1) \
_LT_AC_TAGVAR(thread_safe_flag_spec, $1) \
_LT_AC_TAGVAR(whole_archive_flag_spec, $1) \
@@ -4243,6 +4252,7 @@ if test -f $ltmain; then
_LT_AC_TAGVAR(old_archive_from_new_cmds, $1) | \
_LT_AC_TAGVAR(archive_cmds, $1) | \
_LT_AC_TAGVAR(archive_expsym_cmds, $1) | \
+_LT_AC_TAGVAR(export_dynamic_symbols_cmds, $1) | \
_LT_AC_TAGVAR(module_cmds, $1) | \
_LT_AC_TAGVAR(module_expsym_cmds, $1) | \
_LT_AC_TAGVAR(old_archive_from_expsyms_cmds, $1) | \
@@ -4455,6 +4465,7 @@ link_static_flag=$lt_[]_LT_AC_TAGVAR(lt_
no_builtin_flag=$lt_[]_LT_AC_TAGVAR(lt_prog_compiler_no_builtin_flag, $1)
# Compiler flag to allow reflexive dlopens.
+export_dynamic_symbols_cmds=$lt_[]_LT_AC_TAGVAR(export_dynamic_symbols_cmds,
$1)
export_dynamic_flag_spec=$lt_[]_LT_AC_TAGVAR(export_dynamic_flag_spec, $1)
# Compiler flag to generate shared objects directly from archives.
@@ -5480,6 +5491,7 @@ ifelse([$1],[CXX],[
_LT_AC_TAGVAR(archive_expsym_cmds, $1)=
_LT_AC_TAGVAR(old_archive_From_new_cmds, $1)=
_LT_AC_TAGVAR(old_archive_from_expsyms_cmds, $1)=
+ _LT_AC_TAGVAR(export_dynamic_symbols_cmds, $1)=
_LT_AC_TAGVAR(export_dynamic_flag_spec, $1)=
_LT_AC_TAGVAR(whole_archive_flag_spec, $1)=
_LT_AC_TAGVAR(thread_safe_flag_spec, $1)=
@@ -5788,8 +5800,11 @@ _LT_EOF
# -C means demangle to AIX nm, but means don't demangle with GNU nm
if $NM -V 21 | grep 'GNU' /dev/null; then
_LT_AC_TAGVAR(export_symbols_cmds, $1)='$NM -Bpg $libobjs
$convenience | awk '\''{ if (((\[$]2 == T) || (\[$]2 == D) || (\[$]2 ==
B)) ([substr](\[$]3,1,1) != .)) { print \[$]3 } }'\'' | sort -u
$export_symbols'
+ _LT_AC_TAGVAR(export_dynamic_symbols_cmds, $1)='$NM -Bpg $objs
$libobjs $old_deplibs $old_convenience | awk
Re: Support -library=stlport4 with Sun C++ compiler
On Thu, Aug 03, 2006 at 02:50:31PM +0200, Ralf Menzel wrote: Albert Chin [EMAIL PROTECTED] writes: Good catch. Updated patch attached. 2006-08-01 Albert Chin [EMAIL PROTECTED] * libtool.m4 (AC_LIBTOOL_POSTDEP_PREDEP) [ solaris ]: Don't set $postdeps to -lCstd -lCrun if -library=stlport4 set in CXXFLAGS as stlport4 C++ library incompatible with Cstd C++ library. Use '-library=Cstd -library=Crun' instead of '-lCstd -lCrun'. 2006-08-01 Albert Chin [EMAIL PROTECTED] * libltdl/m4/libtool.m4 (_LT_SYS_HIDDEN_LIBDEPS) [ solaris ]: Don't set $postdeps to -lCstd -lCrun if -library=stlport4 set in CXXFLAGS as stlport4 C++ library incompatible with Cstd C++ library. Use '-library=Cstd -library=Crun' instead of '-lCstd -lCrun'. I found some problems with the patches: 1. In the patch for libtool-HEAD the 'for ... do' line is superflous. 2. _LT_AC_TAGVAR doesn't seem to work with libtool-HEAD. I used _LT_TAGVAR, which seems to work. 3. In libtool-HEAD the patch addresses the Sun C compiler for Linux and not for Solaris, while the patch for libtool-1-5 addresses the Solaris compiler and ignores the linux version. The following patches seem to work for me: Good catch. I should have tested the new patches! Updated patches attached. 2006-08-03 Albert Chin [EMAIL PROTECTED] * libltdl/m4/libtool.m4 (_LT_SYS_HIDDEN_LIBDEPS) [ linux, solaris ]: Remove unterminated for loop from last patch; change variable name from $solaris_use_stlport4 to $suncpp_use_stlport4 as Sun C++ on GNU/Linux might need this feature as well; add -library=stlport4 to solaris section as well. 2006-08-03 Albert Chin [EMAIL PROTECTED] * libtool.m4 (AC_LIBTOOL_POSTDEP_PREDEP) [ linux, solaris ]: Change variable name from $solaris_use_stlport4 to $suncpp_use_stlport4 as Sun C++ on GNU/Linux might need this feature as well; add -library=stlport4 to linux section as well. -- albert chin ([EMAIL PROTECTED]) Index: libtool.m4 === RCS file: /cvsroot/libtool/libtool/Attic/libtool.m4,v retrieving revision 1.314.2.161 diff -u -p -r1.314.2.161 libtool.m4 --- libtool.m4 2 Aug 2006 13:35:37 - 1.314.2.161 +++ libtool.m4 3 Aug 2006 13:45:30 - @@ -3913,7 +3920,23 @@ linux*) case `$CC -V 21 | sed 5q` in *Sun\ C*) # Sun C++ 5.9 -_LT_AC_TAGVAR(postdeps,$1)='-lCstd -lCrun' + +# The more standards-conforming stlport4 library is +# incompatible with the Cstd library. Avoid specifying +# it if it's in CXXFLAGS. Ignore libCrun as +# -library=stlport4 depends on it. +case $CXX $CXXFLAGS in +* -library=stlport4 *) + suncpp_use_stlport4=yes + ;; +esac + +# Adding this requires a known-good setup of shared libraries for +# Sun compiler versions before 5.6, else PIC objects from an old +# archive will be linked into the output, leading to subtle bugs. +if test $suncpp_use_stlport4 != yes; then + _LT_AC_TAGVAR(postdeps,$1)='-library=Cstd -library=Crun' +fi ;; esac ;; @@ -3927,14 +3950,14 @@ solaris*) # -library=stlport4 depends on it. case $CXX $CXXFLAGS in * -library=stlport4 *) - solaris_use_stlport4=yes + suncpp_use_stlport4=yes ;; esac # Adding this requires a known-good setup of shared libraries for # Sun compiler versions before 5.6, else PIC objects from an old # archive will be linked into the output, leading to subtle bugs. -if test $solaris_use_stlport4 != yes; then +if test $suncpp_use_stlport4 != yes; then _LT_AC_TAGVAR(postdeps,$1)='-library=Cstd -library=Crun' fi ;; Index: libltdl/m4/libtool.m4 === RCS file: /cvsroot/libtool/libtool/libltdl/m4/libtool.m4,v retrieving revision 1.77 diff -u -p -r1.77 libtool.m4 --- libltdl/m4/libtool.m4 2 Aug 2006 13:35:30 - 1.77 +++ libltdl/m4/libtool.m4 3 Aug 2006 13:45:41 - @@ -6343,15 +6343,14 @@ linux*) # incompatible with the Cstd library. Avoid specifying # it if it's in CXXFLAGS. Ignore libCrun as # -library=stlport4 depends on it. -for cc_flag in $CXXFLAGS; do case $CXX $CXXFLAGS in * -library=stlport4 *) - solaris_use_stlport4=yes + suncpp_use_stlport4=yes ;; esac -if test $solaris_use_stlport4 != yes; then - _LT_AC_TAGVAR(postdeps,$1)='-library=Cstd -library=Crun' +if test $suncpp_use_stlport4 != yes; then + _LT_TAGVAR(postdeps,$1)='-library=Cstd -library=Crun' fi ;; esac @@ -6363,7 +6362,20 @@ solaris*) # Adding this requires a known-good setup of shared libraries for # Sun compiler versions before 5.6, else PIC objects from an old # archive will be linked into the output, leading to subtle bugs
Re: Support -library=stlport4 with Sun C++ compiler
On Thu, Aug 03, 2006 at 11:44:17PM +0900, Peter O'Gorman wrote: I just applied Ralf's patches, then saw this. It's okay with me as is, do you insist on the variable name change? I can see the value, but am tired of applying patches for this :) No, I don't insist. As long as it works. -- albert chin ([EMAIL PROTECTED])
Re: Support -library=stlport4 with Sun C++ compiler
On Tue, Aug 01, 2006 at 02:12:31PM +0900, Peter O'Gorman wrote: On Aug 1, 2006, at 1:38 PM, Albert Chin wrote: Sun C++ supports two C++ libraries, -library=Cstd (default), and the newer -library=stlport4. They are incompatible. Therefore, libtool's use of -lCstd (equivalent to -library=Cstd) should not be assigned to $postdeps if -library=stlport4 is in CXXFLAGS. Patch attached. Patch against branch-1-5 and branch-2.0 attached. This makes sense, but branch-2-0 is dead :-) Before I apply it though, do we also want to check CXX for - library=stlport4 ? Someone could do CXX='CC -library=stlport4' and expect libtool not to add CStd etc. Can't we do case $CXX $CXXFLAGS in * -library=stlport4 *) solaris_use_stlport4=yes ;; esac To save the loop too? Good catch. Updated patch attached. 2006-08-01 Albert Chin [EMAIL PROTECTED] * libtool.m4 (AC_LIBTOOL_POSTDEP_PREDEP) [ solaris ]: Don't set $postdeps to -lCstd -lCrun if -library=stlport4 set in CXXFLAGS as stlport4 C++ library incompatible with Cstd C++ library. Use '-library=Cstd -library=Crun' instead of '-lCstd -lCrun'. 2006-08-01 Albert Chin [EMAIL PROTECTED] * libltdl/m4/libtool.m4 (_LT_SYS_HIDDEN_LIBDEPS) [ solaris ]: Don't set $postdeps to -lCstd -lCrun if -library=stlport4 set in CXXFLAGS as stlport4 C++ library incompatible with Cstd C++ library. Use '-library=Cstd -library=Crun' instead of '-lCstd -lCrun'. -- albert chin ([EMAIL PROTECTED]) Index: libtool.m4 === RCS file: /cvsroot/libtool/libtool/Attic/libtool.m4,v retrieving revision 1.314.2.160 diff -u -p -r1.314.2.160 libtool.m4 --- libtool.m4 28 Jul 2006 16:57:36 - 1.314.2.160 +++ libtool.m4 1 Aug 2006 16:57:51 - @@ -3921,10 +3928,22 @@ linux*) solaris*) case $cc_basename in CC*) +# The more standards-conforming stlport4 library is +# incompatible with the Cstd library. Avoid specifying +# it if it's in CXXFLAGS. Ignore libCrun as +# -library=stlport4 depends on it. +case $CXX $CXXFLAGS in +* -library=stlport4 *) + solaris_use_stlport4=yes + ;; +esac + # Adding this requires a known-good setup of shared libraries for # Sun compiler versions before 5.6, else PIC objects from an old # archive will be linked into the output, leading to subtle bugs. -_LT_AC_TAGVAR(postdeps,$1)='-lCstd -lCrun' +if test $solaris_use_stlport4 != yes; then + _LT_AC_TAGVAR(postdeps,$1)='-library=Cstd -library=Crun' +fi ;; esac ;; Index: libltdl/m4/libtool.m4 === RCS file: /cvsroot/libtool/libtool/libltdl/m4/libtool.m4,v retrieving revision 1.76 diff -u -p -r1.76 libtool.m4 --- libltdl/m4/libtool.m4 28 Jul 2006 17:01:05 - 1.76 +++ libltdl/m4/libtool.m4 1 Aug 2006 16:58:11 - @@ -6338,7 +6338,21 @@ linux*) case `$CC -V 21 | sed 5q` in *Sun\ C*) # Sun C++ 5.9 -_LT_TAGVAR(postdeps,$1)='-lCstd -lCrun' + +# The more standards-conforming stlport4 library is +# incompatible with the Cstd library. Avoid specifying +# it if it's in CXXFLAGS. Ignore libCrun as +# -library=stlport4 depends on it. +for cc_flag in $CXXFLAGS; do +case $CXX $CXXFLAGS in +* -library=stlport4 *) + solaris_use_stlport4=yes + ;; +esac + +if test $solaris_use_stlport4 != yes; then + _LT_AC_TAGVAR(postdeps,$1)='-library=Cstd -library=Crun' +fi ;; esac ;;
Support -library=stlport4 with Sun C++ compiler
Sun C++ supports two C++ libraries, -library=Cstd (default), and the newer -library=stlport4. They are incompatible. Therefore, libtool's use of -lCstd (equivalent to -library=Cstd) should not be assigned to $postdeps if -library=stlport4 is in CXXFLAGS. Patch attached. Patch against branch-1-5 and branch-2.0 attached. 2006-07-31 Albert Chin [EMAIL PROTECTED] * libtool.m4 (AC_LIBTOOL_POSTDEP_PREDEP) [ solaris ]: Don't set $postdeps to -lCstd -lCrun if -library=stlport4 set in CXXFLAGS as stlport4 C++ library incompatible with Cstd C++ library. Use '-library=Cstd -library=Crun' instead of '-lCstd -lCrun'. 2006-07-31 Albert Chin [EMAIL PROTECTED] * m4/libtool.m4 (_LT_SYS_HIDDEN_LIBDEPS) [ solaris ]: Don't set $postdeps to -lCstd -lCrun if -library=stlport4 set in CXXFLAGS as stlport4 C++ library incompatible with Cstd C++ library. Use '-library=Cstd -library=Crun' instead of '-lCstd -lCrun'. -- albert chin ([EMAIL PROTECTED]) Index: libtool.m4 === RCS file: /cvsroot/libtool/libtool/Attic/libtool.m4,v retrieving revision 1.314.2.160 diff -u -p -r1.314.2.160 libtool.m4 --- libtool.m4 28 Jul 2006 16:57:36 - 1.314.2.160 +++ libtool.m4 1 Aug 2006 04:28:45 - @@ -3921,10 +3928,25 @@ linux*) solaris*) case $cc_basename in CC*) +# The more standards-conforming stlport4 library is +# incompatible with the Cstd library. Avoid specifying +# it if it's in CXXFLAGS. Ignore libCrun as +# -library=stlport4 depends on it. +for cc_flag in $CXXFLAGS; do + case $cc_flag in + *-library=stlport4*) + solaris_use_stlport4=yes + break + ;; + esac +done + # Adding this requires a known-good setup of shared libraries for # Sun compiler versions before 5.6, else PIC objects from an old # archive will be linked into the output, leading to subtle bugs. -_LT_AC_TAGVAR(postdeps,$1)='-lCstd -lCrun' +if test $solaris_use_stlport4 != yes; then + _LT_AC_TAGVAR(postdeps,$1)='-library=Cstd -library=Crun' +fi ;; esac ;; Index: m4/libtool.m4 === RCS file: /cvsroot/libtool/libtool/m4/Attic/libtool.m4,v retrieving revision 1.125.2.76 diff -u -p -r1.125.2.76 libtool.m4 --- m4/libtool.m4 24 Aug 2005 15:05:20 - 1.125.2.76 +++ m4/libtool.m4 1 Aug 2006 04:28:53 - @@ -5919,7 +5919,22 @@ m4_if([$1], [CXX], solaris*) case $cc_basename in CC*) -_LT_TAGVAR(postdeps,$1)='-lCstd -lCrun' +# The more standards-conforming stlport4 library is +# incompatible with the Cstd library. Avoid specifying +# it if it's in CXXFLAGS. Ignore libCrun as +# -library=stlport4 depends on it. +for cc_flag in $CXXFLAGS; do + case $cc_flag in + *-library=stlport4*) + solaris_use_stlport4=yes + break + ;; + esac +done + +if test $solaris_use_stlport4 != yes; then + _LT_AC_TAGVAR(postdeps,$1)='-library=Cstd -library=Crun' +fi ;; esac esac
Re: Supporting -export-dynamic on AIX
On Sun, Jul 02, 2006 at 10:58:23PM +0900, Peter O'Gorman wrote: Here are patches against branch-1-5 and HEAD, okay (with apropriate ChangeLog, of course)? The patch I submitted doesn't work when the command-line length is exceeded so the patch needs a little more work. I'll try to address this soon. -- albert chin ([EMAIL PROTECTED]) ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: LT_* equivalent to AC_CHECK_LIB?
On Mon, Jul 03, 2006 at 02:20:45PM -0500, Bob Friesenhahn wrote: A challenge is that in libtool 2.0, the libtool script is not generated until the end of the configure script run (an `enhancement' in 2.0) so it is not available for use. Didn't Ralf address this? -- albert chin ([EMAIL PROTECTED]) ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Supporting -export-dynamic on AIX
On Sun, Jun 11, 2006 at 01:14:23AM -0500, Albert Chin wrote:
On Sat, Jun 10, 2006 at 07:12:34PM -0500, Albert Chin wrote:
On Sun, Jun 11, 2006 at 01:04:17AM +0200, Ralf Wildenhues wrote:
* Albert Chin wrote on Sat, Jun 10, 2006 at 08:49:29PM CEST:
On Sat, Jun 10, 2006 at 08:29:44PM +0200, Ralf Wildenhues wrote:
* Albert Chin wrote on Sat, Jun 10, 2006 at 08:08:15PM CEST:
Any reason we don't use -bexpall to support -export-dynamic on AIX?
Yes, as commented in libtool.m4:
I think this is still correct. How should I fix it?
Well. In what way(s) do gaim and galculator fail, and why?
Is there a way to reproduce the failure without much hassle
such as lots of required packages, maybe even a stripped down
test case? Are those packages doing something we may want
to allow, or is it impossible to realize portably anyway?
I'm sorry but I cannot answer your question without more
information. (That is not to say that I could otherwise ;-)
When I say how should I fix it, I mean what's the best way to
implement -export-dynamic on AIX. Maybe a new export_dynamic_cmds
command that creates the symbols ala export_symbols_cmds and then
export_dynamic_flag_spec to add the ld flag to export the symbols from
export_symbols_cmds to the binary?
I'm thinking of a patch along the lines of the one below. What do you
think?
Well, this has some problems. First, if only export_dynamic_flag_spec
is set, the new export list code is wrong. Fixed in the patch below.
The second problem is when libtool is passed multiple source files,
rather than object files to create the executable. This method totally
fails then. What to do in this case?
--
albert chin ([EMAIL PROTECTED])
-- snip snip
Index: libtool.m4
===
RCS file: /cvsroot/libtool/libtool/Attic/libtool.m4,v
retrieving revision 1.314.2.158
diff -u -p -r1.314.2.158 libtool.m4
--- libtool.m4 12 Jun 2006 05:25:26 - 1.314.2.158
+++ libtool.m4 20 Jun 2006 17:09:14 -
@@ -2911,6 +2911,13 @@ case $host_os in
exp_sym_flag='-bexport'
no_entry_flag='-bnoentry'
+
+ if $NM -V 21 | grep 'GNU' /dev/null; then
+ _LT_AC_TAGVAR(export_dynamic_symbols_cmds, $1)='$NM -Bpg $objs | awk
'\''{ if (((\[$]2 == T) || (\[$]2 == D) || (\[$]2 == B))
([substr](\[$]3,1,1) != .)) { print \[$]3 } }'\'' | sort -u $export_symbols'
+ else
+ _LT_AC_TAGVAR(export_dynamic_symbols_cmds, $1)='$NM -BCpg $objs | awk
'\''{ if (((\[$]2 == T) || (\[$]2 == D) || (\[$]2 == B))
([substr](\[$]3,1,1) != .)) { print \[$]3 } }'\'' | sort -u $export_symbols'
+ fi
+ _LT_AC_TAGVAR(export_dynamic_flag_spec,
$1)=\${wl}$exp_sym_flag:\$export_symbols
fi
# When large executables or shared objects are built, AIX ld can
@@ -3950,6 +3957,7 @@ _LT_AC_TAGVAR(archive_cmds_need_lc, $1)=
_LT_AC_TAGVAR(allow_undefined_flag, $1)=
_LT_AC_TAGVAR(always_export_symbols, $1)=no
_LT_AC_TAGVAR(archive_expsym_cmds, $1)=
+_LT_AC_TAGVAR(export_dynamic_symbols_cmds, $1)=
_LT_AC_TAGVAR(export_dynamic_flag_spec, $1)=
_LT_AC_TAGVAR(hardcode_direct, $1)=no
_LT_AC_TAGVAR(hardcode_libdir_flag_spec, $1)=
@@ -4178,6 +4186,7 @@ if test -f $ltmain; then
_LT_AC_TAGVAR(lt_prog_compiler_pic, $1) \
_LT_AC_TAGVAR(lt_prog_compiler_static, $1) \
_LT_AC_TAGVAR(lt_prog_compiler_no_builtin_flag, $1) \
+_LT_AC_TAGVAR(export_dynamic_symbols_cmds, $1) \
_LT_AC_TAGVAR(export_dynamic_flag_spec, $1) \
_LT_AC_TAGVAR(thread_safe_flag_spec, $1) \
_LT_AC_TAGVAR(whole_archive_flag_spec, $1) \
@@ -4212,6 +4221,7 @@ if test -f $ltmain; then
_LT_AC_TAGVAR(old_archive_from_new_cmds, $1) | \
_LT_AC_TAGVAR(archive_cmds, $1) | \
_LT_AC_TAGVAR(archive_expsym_cmds, $1) | \
+_LT_AC_TAGVAR(export_dynamic_symbols_cmds, $1) | \
_LT_AC_TAGVAR(module_cmds, $1) | \
_LT_AC_TAGVAR(module_expsym_cmds, $1) | \
_LT_AC_TAGVAR(old_archive_from_expsyms_cmds, $1) | \
@@ -4424,6 +4434,7 @@ link_static_flag=$lt_[]_LT_AC_TAGVAR(lt_
no_builtin_flag=$lt_[]_LT_AC_TAGVAR(lt_prog_compiler_no_builtin_flag, $1)
# Compiler flag to allow reflexive dlopens.
+export_dynamic_symbols_cmds=$lt_[]_LT_AC_TAGVAR(export_dynamic_symbols_cmds,
$1)
export_dynamic_flag_spec=$lt_[]_LT_AC_TAGVAR(export_dynamic_flag_spec, $1)
# Compiler flag to generate shared objects directly from archives.
@@ -5449,6 +5460,7 @@ ifelse([$1],[CXX],[
_LT_AC_TAGVAR(archive_expsym_cmds, $1)=
_LT_AC_TAGVAR(old_archive_From_new_cmds, $1)=
_LT_AC_TAGVAR(old_archive_from_expsyms_cmds, $1)=
+ _LT_AC_TAGVAR(export_dynamic_symbols_cmds, $1)=
_LT_AC_TAGVAR(export_dynamic_flag_spec, $1)=
_LT_AC_TAGVAR(whole_archive_flag_spec, $1)=
_LT_AC_TAGVAR(thread_safe_flag_spec, $1)=
@@ -5757,8 +5769,11 @@ _LT_EOF
# -C means demangle to AIX nm, but means don't demangle with GNU nm
if $NM -V 21 | grep 'GNU' /dev/null
TODO Addition
Addition to TODO file. Should I expand on why this is needed or is it obvious? -- albert chin ([EMAIL PROTECTED]) -- snip snip Index: TODO === RCS file: /cvsroot/libtool/libtool/TODO,v retrieving revision 1.71 diff -u -p -r1.71 TODO --- TODO3 Dec 2005 17:36:15 - 1.71 +++ TODO19 Jun 2006 05:35:31 - @@ -188,6 +188,8 @@ GNU Libtool * Add caching mechanism. Look at `libtool-cache' from Robert ??gren. +* Preserve the order of the command-line and make changes in-place, + if required. 2.4. libtool autoconf macros
Re: TODO Addition
On Mon, Jun 19, 2006 at 07:42:40AM +0200, Ralf Wildenhues wrote: * Albert Chin wrote on Mon, Jun 19, 2006 at 07:37:00AM CEST: Addition to TODO file. Should I expand on why this is needed or is it obvious? It's obvious why you want this, and why this is needed in many situations. There are some intricate exceptions, though. As to how to realize it: it needs only a slight generalization of my proposed per-deplib flags patch. Also, the in-tree TODO file is hopelessly outdated. Any chance you could just add this to http://wiki.azazil.net/GnuLibtoolProject/RoadMap for now? Sure. -- albert chin ([EMAIL PROTECTED])
Remove hardcode_libdir_flag_spec_ld for hppa*64*|ia64*
The most recent changelog entry for the 1.5 branch has: 2006-06-12 Ralf Wildenhues [EMAIL PROTECTED] * ltmain.in (link mode): Disregard `hardcode_libdir_flag_spec_ld' if we're using `$CC' to link. * libtool.m4 () [ hpux10, hpux11; hppa*64*, ia64* ] hardcode_libdir_flag_spec_ld: Removed. Reported by Roger While [EMAIL PROTECTED]. However, one entry for hardcode_libdir_flag_spec_ld remains (patch below to remove). Did you skip this on purpose? -- albert chin ([EMAIL PROTECTED]) -- snip snip Index: libtool.m4 === RCS file: /cvsroot/libtool/libtool/Attic/libtool.m4,v retrieving revision 1.314.2.158 diff -u -p -r1.314.2.158 libtool.m4 --- libtool.m4 12 Jun 2006 05:25:26 - 1.314.2.158 +++ libtool.m4 14 Jun 2006 15:45:39 - @@ -6051,7 +6066,6 @@ _LT_EOF case $host_cpu in hppa*64*|ia64*) - _LT_AC_TAGVAR(hardcode_libdir_flag_spec_ld, $1)='+b $libdir' _LT_AC_TAGVAR(hardcode_direct, $1)=no _LT_AC_TAGVAR(hardcode_shlibpath_var, $1)=no ;;
Re: HP-UX hppa64 and gcc
On Mon, Jun 12, 2006 at 08:05:45AM +0200, Ralf Wildenhues wrote: Hi Albert, * Albert Chin wrote on Mon, Jun 12, 2006 at 07:37:11AM CEST: On Mon, Jun 12, 2006 at 07:25:32AM +0200, Ralf Wildenhues wrote: * Ralf Wildenhues wrote on Thu, Jan 05, 2006 at 02:03:49PM CET: * Albert Chin wrote on Wed, Jan 04, 2006 at 11:49:35PM CET: On Wed, Jan 04, 2006 at 10:19:27AM +0100, Roger While wrote: Libtool 1.5.22 There is a problem on HP-UX 64 bit when using gcc. Problem is at line 3167 in libtool.m4 : _LT_AC_TAGVAR(hardcode_libdir_flag_spec_ld, $1)='+b $libdir' gcc doesn't like that ! We can ditch hardcode_libdir_flag_spec_ld for HP-UX. In the C++ case, yes, but for some HP-UX cases we use $LD still. and we still need to revisit the choice of $CC vs $LD based upon compiler version, not HP-UX version. Why? For HP-UX 11.00 and above, why would you ever use $LD? See this thread: http://lists.gnu.org/archive/html/bug-libtool/2006-06/msg1.html Wow. That compiler is from June 2000! http://h21007.www2.hp.com/dspp/tech/tech_TechDocumentDetailPage_IDX/1,1701,1255,00.html -- albert chin ([EMAIL PROTECTED]) ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: HP-UX hppa64 and gcc
On Mon, Jun 12, 2006 at 07:25:32AM +0200, Ralf Wildenhues wrote: * Ralf Wildenhues wrote on Thu, Jan 05, 2006 at 02:03:49PM CET: * Albert Chin wrote on Wed, Jan 04, 2006 at 11:49:35PM CET: On Wed, Jan 04, 2006 at 10:19:27AM +0100, Roger While wrote: Libtool 1.5.22 There is a problem on HP-UX 64 bit when using gcc. Problem is at line 3167 in libtool.m4 : _LT_AC_TAGVAR(hardcode_libdir_flag_spec_ld, $1)='+b $libdir' gcc doesn't like that ! Thank you for the bug report. We can ditch hardcode_libdir_flag_spec_ld for HP-UX. In the C++ case, yes, but for some HP-UX cases we use $LD still. Wouldn't a better fix be something like this (not yet tested)? Roger, could you try whether this works for you? Actually, we should just ditch the variable altogether and compute it anew from hardcode_libdir_flag_spec by emptying $wl if we decide to link with $LD. (Not for branch-1-5, this would change interface.) and we still need to revisit the choice of $CC vs $LD based upon compiler version, not HP-UX version. Why? For HP-UX 11.00 and above, why would you ever use $LD? -- albert chin ([EMAIL PROTECTED])
Re: HP-UX hppa64 and gcc
On Mon, Jun 12, 2006 at 07:25:32AM +0200, Ralf Wildenhues wrote: * Ralf Wildenhues wrote on Thu, Jan 05, 2006 at 02:03:49PM CET: * Albert Chin wrote on Wed, Jan 04, 2006 at 11:49:35PM CET: On Wed, Jan 04, 2006 at 10:19:27AM +0100, Roger While wrote: Libtool 1.5.22 There is a problem on HP-UX 64 bit when using gcc. Problem is at line 3167 in libtool.m4 : _LT_AC_TAGVAR(hardcode_libdir_flag_spec_ld, $1)='+b $libdir' gcc doesn't like that ! Thank you for the bug report. We can ditch hardcode_libdir_flag_spec_ld for HP-UX. In the C++ case, yes, but for some HP-UX cases we use $LD still. Wouldn't a better fix be something like this (not yet tested)? Roger, could you try whether this works for you? Actually, we should just ditch the variable altogether and compute it anew from hardcode_libdir_flag_spec by emptying $wl if we decide to link with $LD. (Not for branch-1-5, this would change interface.) and we still need to revisit the choice of $CC vs $LD based upon compiler version, not HP-UX version. Why? For HP-UX 11.00 and above, why would you ever use $LD? -- albert chin ([EMAIL PROTECTED]) ___ http://lists.gnu.org/mailman/listinfo/libtool
Supporting -export-dynamic on AIX
Any reason we don't use -bexpall to support -export-dynamic on AIX? From ld(1): autoexp Automatically exports some symbols from the output module without having to list them in an export file. (This option does not export all symbols from the output module. Use the -bexpall option to export all symbols.)This is the default. Use this option when linking a main program. The linker assumes that you are linking a main program when you do not specify a module type (with the M or modtype option) beginning with S and you do not use the noentry option. It's needed for things like gaim and galculator to work. -- albert chin ([EMAIL PROTECTED]) ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Supporting -export-dynamic on AIX
On Sat, Jun 10, 2006 at 08:29:44PM +0200, Ralf Wildenhues wrote: * Albert Chin wrote on Sat, Jun 10, 2006 at 08:08:15PM CEST: Any reason we don't use -bexpall to support -export-dynamic on AIX? Yes, as commented in libtool.m4: # It seems that -bexpall does not export symbols beginning with # underscore (_), so it is better to generate a list of symbols to export. _LT_AC_TAGVAR(always_export_symbols, $1)=yes No, I haven't researched the origin of this, nor its validity for non-ancient systems. The 2001-04-19 change seems relevant. I think this is still correct. How should I fix it? -- albert chin ([EMAIL PROTECTED]) ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Supporting -export-dynamic on AIX
On Sun, Jun 11, 2006 at 01:04:17AM +0200, Ralf Wildenhues wrote: * Albert Chin wrote on Sat, Jun 10, 2006 at 08:49:29PM CEST: On Sat, Jun 10, 2006 at 08:29:44PM +0200, Ralf Wildenhues wrote: * Albert Chin wrote on Sat, Jun 10, 2006 at 08:08:15PM CEST: Any reason we don't use -bexpall to support -export-dynamic on AIX? Yes, as commented in libtool.m4: I think this is still correct. How should I fix it? Well. In what way(s) do gaim and galculator fail, and why? Is there a way to reproduce the failure without much hassle such as lots of required packages, maybe even a stripped down test case? Are those packages doing something we may want to allow, or is it impossible to realize portably anyway? I'm sorry but I cannot answer your question without more information. (That is not to say that I could otherwise ;-) When I say how should I fix it, I mean what's the best way to implement -export-dynamic on AIX. Maybe a new export_dynamic_cmds command that creates the symbols ala export_symbols_cmds and then export_dynamic_flag_spec to add the ld flag to export the symbols from export_symbols_cmds to the binary? gaim/galculator fail because they require symbols in the main executable to be exported to dlopen()'ed modules. -- albert chin ([EMAIL PROTECTED]) ___ http://lists.gnu.org/mailman/listinfo/libtool
Missed $hardcode_direct_absolute in CXX tag
I missed the addition of $hardcode_direct_absolute for the CXX tag.
2006-05-23 Albert Chin [EMAIL PROTECTED]
* libltdl/m4/libtool.m4 (_LT_LANG_CXX_CONFIG)
[ aix4*, aix5*, hpux10*, hpux11* ]: Forgot to add
hardcode_direct_absolute for CXX tag.
--
albert chin ([EMAIL PROTECTED])
-- snip snip
Index: libltdl/m4/libtool.m4
===
RCS file: /cvsroot/libtool/libtool/libltdl/m4/libtool.m4,v
retrieving revision 1.72
diff -u -p -r1.72 libtool.m4
--- libltdl/m4/libtool.m4 18 May 2006 16:32:21 - 1.72
+++ libltdl/m4/libtool.m4 23 May 2006 18:42:33 -
@@ -5308,6 +5308,7 @@ if test $_lt_caught_CXX_error != yes;
_LT_TAGVAR(archive_cmds, $1)=''
_LT_TAGVAR(hardcode_direct, $1)=yes
+_LT_TAGVAR(hardcode_direct_absolute, $1)=yes
_LT_TAGVAR(hardcode_libdir_separator, $1)=':'
_LT_TAGVAR(link_all_deplibs, $1)=yes
_LT_TAGVAR(file_list_spec, $1)='${wl}-f,'
@@ -5595,6 +5596,7 @@ if test $_lt_caught_CXX_error != yes;
;;
*)
_LT_TAGVAR(hardcode_direct, $1)=yes
+_LT_TAGVAR(hardcode_direct_absolute, $1)=yes
_LT_TAGVAR(hardcode_minus_L, $1)=yes # Not in the search PATH,
# but as the default
# location of the library.
inherited_flags.at failure on HP-UX 10.20
HP-UX 10.20 uses ld rather than cc to create shared libraries. Because
of this, inherited_linker_flags in a *.la file is not added to the
link line.
From ltmain.sh:
if test $linkmode,$pass = prog,link; then
compile_deplibs=$new_inherited_linker_flags $compile_deplibs
finalize_deplibs=$new_inherited_linker_flags $finalize_deplibs
else
compiler_flags=$compiler_flags $inherited_linker_flags
fi
$inherited_linker_flags is added to $compiler_flags but
$compiler_flags is used only when cc is used to create a shared
library. From libtool.m4:
hpux10*)
if test $GCC = yes -a $with_gnu_ld = no; then
_LT_TAGVAR(archive_cmds, $1)='$CC -shared -fPIC ${wl}+h ${wl}$soname
${wl}+b ${wl}$install_libdir -o $lib $libobjs $deplibs $compiler_flags'
else
_LT_TAGVAR(archive_cmds, $1)='$LD -b +h $soname +b $install_libdir -o
$lib $libobjs $deplibs $linker_flags'
fi
So, should we modify the code in ltmain.sh to add
$inherited_linker_flags to $linker_flags:
if test $linkmode,$pass = prog,link; then
compile_deplibs=$new_inherited_linker_flags $compile_deplibs
finalize_deplibs=$new_inherited_linker_flags $finalize_deplibs
else
compiler_flags=$compiler_flags $inherited_linker_flags
linker_flags=$linker_flags $inherited_linker_flags
fi
Looking at what is added to $new_inherited_linker_flags in ltmain.sh,
this looks safe.
--
albert chin ([EMAIL PROTECTED])
___
http://lists.gnu.org/mailman/listinfo/libtool
Re: inherited_flags.at failure on HP-UX 10.20
On Thu, May 18, 2006 at 09:53:06AM +0200, Ralf Wildenhues wrote: * Albert Chin wrote on Thu, May 18, 2006 at 09:40:21AM CEST: HP-UX 10.20 uses ld rather than cc to create shared libraries. Because of this, inherited_linker_flags in a *.la file is not added to the link line. Which of those flags are important for HP-UX 10.20 ld? Which of what flags? $inherited_linker_flags is added to $compiler_flags but $compiler_flags is used only when cc is used to create a shared library. From libtool.m4: So, should we modify the code in ltmain.sh to add $inherited_linker_flags to $linker_flags: Looking at what is added to $new_inherited_linker_flags in ltmain.sh, this looks safe. Yes, but that is fragile. At least, it would need a comment that whatever is added to new_inherited_linker_flags should also be understood by the linker iff $LD is used to link. Yep, definitely fragile. A comment with a test should be sufficient. Then, do we need to pass any of those flags to $LD while doing partial linking (reload_cmds)? Probably not, but I'm not sure. I doubt it. It'd be good to have a test for this; the use of $LD in archive_cmds will likely provoke other failures; putting all of them in a test may help us preserve libtool functioning on HP-UX 10.20. (I can try to write one once we've settled on the rest.) Agreed. -- albert chin ([EMAIL PROTECTED]) ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: inherited_flags.at failure on HP-UX 10.20
On Thu, May 18, 2006 at 10:17:42AM +0200, Ralf Wildenhues wrote: * Albert Chin wrote on Thu, May 18, 2006 at 10:11:29AM CEST: On Thu, May 18, 2006 at 09:53:06AM +0200, Ralf Wildenhues wrote: * Albert Chin wrote on Thu, May 18, 2006 at 09:40:21AM CEST: HP-UX 10.20 uses ld rather than cc to create shared libraries. Because of this, inherited_linker_flags in a *.la file is not added to the link line. Which of those flags are important for HP-UX 10.20 ld? Which of what flags? Currently the list of inherited linker flags is -mt|-mthreads|-kthread|-Kthread|-pthread|-pthreads|--thread-safe and stuff matching *.ltframework. Which of these flags, if any, matters to HP-UX ld? None. -- albert chin ([EMAIL PROTECTED]) ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Ignore hardcode_direct=yes if results in static lib entry
On Wed, May 17, 2006 at 05:17:54PM +0200, Ralf Wildenhues wrote: * Gary V. Vaughan wrote on Wed, May 17, 2006 at 05:11:46PM CEST: Ralf Wildenhues wrote: * Albert Chin wrote on Wed, May 17, 2006 at 03:18:09AM CEST: The following patch addresses http://lists.gnu.org/archive/html/libtool/2006-04/msg00044.html. I added a new variable, hardcode_direct_static, to indicate if hardcode_direct=yes would hardcode a static library dependency. This impacts HP-UX/PA and AIX. This patch is missing a documentation update (doc/libtool.texi). I'll commit one presently. Thanks. It would be great if you could explain that static library dependency does _not_ have to do with static libraries at all -- what a confusing name IMHO! Maybe we should think of a better one. Is that what HP-UX is using in their documentation? I couldn't find a name for this in the HP documentation so I made something up :) However, the output of 'chatr' has 'static' in the type of the DT_NEEDED line so that's where I came up with the name. -- albert chin ([EMAIL PROTECTED])
Re: Ignore hardcode_direct=yes if results in static lib entry
On Wed, May 17, 2006 at 05:59:23PM +0200, Ralf Wildenhues wrote: * Albert Chin wrote on Wed, May 17, 2006 at 03:18:09AM CEST: The following patch addresses http://lists.gnu.org/archive/html/libtool/2006-04/msg00044.html. I added a new variable, hardcode_direct_static, to indicate if hardcode_direct=yes would hardcode a static library dependency. This impacts HP-UX/PA and AIX. I think this should be set for OpenBSD as well, no? Possibly. OpenBSD does seem to have this problem, from my limited testing. -- albert chin ([EMAIL PROTECTED])
Re: Ignore hardcode_direct=yes if results in static lib entry
On Wed, May 17, 2006 at 05:00:04PM +0200, Ralf Wildenhues wrote: * Albert Chin wrote on Wed, May 17, 2006 at 03:18:09AM CEST: The following patch addresses http://lists.gnu.org/archive/html/libtool/2006-04/msg00044.html. I added a new variable, hardcode_direct_static, to indicate if hardcode_direct=yes would hardcode a static library dependency. This impacts HP-UX/PA and AIX. Patch against HEAD. Does the testsuite pass with this? Yes. -- albert chin ([EMAIL PROTECTED])
Re: HEAD link-order.at fails when hardcode_direct=yes
On Wed, May 17, 2006 at 04:48:24PM +0200, Ralf Wildenhues wrote: * Albert Chin wrote on Wed, May 17, 2006 at 02:44:49PM CEST: + case $hardcode_direct$hardcode_direct_static in + yesno) +AT_CHECK([if $EGREP relinking stderr; then + $EGREP .*\/new\/lib/libb$shrext_cmds .*\/old\/lib/libcee$shrext_cmds stdout + else :; fi], [0], [ignore], [], [echo wrong link order]) +;; You shouldn't grep for $shrext_cmds. It's called *_cmds because it may contain commands. The right way is to module=no eval shared_ext=\$shrext_cmds\ The patch below fixes this. I skipped it because I knew I wouldn't need it for HP-UX/AIX :) 2006-05-17 Albert Chin [EMAIL PROTECTED] Ralf Wildenhues [EMAIL PROTECTED] * tests/link-order.at: Don't use $shrext_cmds directly because it might contain commands. -- albert chin ([EMAIL PROTECTED]) -- snip snip Index: tests/link-order.at === RCS file: /cvsroot/libtool/libtool/tests/link-order.at,v retrieving revision 1.10 diff -u -p -r1.10 link-order.at --- tests/link-order.at 17 May 2006 14:28:40 - 1.10 +++ tests/link-order.at 17 May 2006 16:38:15 - @@ -23,6 +23,9 @@ AT_KEYWORDS([libtool]) eval `$LIBTOOL --config | $EGREP '^(hardcode_direct|hardcode_direct_static|shrext_cmds)='` LDFLAGS=$LDFLAGS -no-undefined +module=no +eval shared_ext=\$shrext_cmds\ + prefix_old=`pwd`/old prefix_new=`pwd`/new mkdir src $prefix_old $prefix_new $prefix_old/lib $prefix_new/lib @@ -72,7 +75,7 @@ aix* | interix*) ;; # These systems hav case $hardcode_direct$hardcode_direct_static in yesno) AT_CHECK([if $EGREP relinking stderr; then - $EGREP .*\/new\/lib/libb$shrext_cmds .*\/old\/lib/libcee$shrext_cmds stdout + $EGREP .*\/new\/lib/libb$shared_ext .*\/old\/lib/libcee$shared_ext stdout else :; fi], [0], [ignore], [], [echo wrong link order]) ;; *)
Re: Ignore hardcode_direct=yes if results in static lib entry
On Wed, May 17, 2006 at 09:55:42PM +0200, Ralf Wildenhues wrote: * Albert Chin wrote on Wed, May 17, 2006 at 06:35:06PM CEST: On Wed, May 17, 2006 at 05:17:54PM +0200, Ralf Wildenhues wrote: * Gary V. Vaughan wrote on Wed, May 17, 2006 at 05:11:46PM CEST: Ralf Wildenhues wrote: * Albert Chin wrote on Wed, May 17, 2006 at 03:18:09AM CEST: The following patch addresses http://lists.gnu.org/archive/html/libtool/2006-04/msg00044.html. I added a new variable, hardcode_direct_static, to indicate if hardcode_direct=yes would hardcode a static library dependency. This impacts HP-UX/PA and AIX. Thanks. It would be great if you could explain that static library dependency does _not_ have to do with static libraries at all -- what a confusing name IMHO! Maybe we should think of a better one. Is that what HP-UX is using in their documentation? I couldn't find a name for this in the HP documentation so I made something up :) However, the output of 'chatr' has 'static' in the type of the DT_NEEDED line so that's where I came up with the name. OK. So let's name the thingy hardcode_direct_absolute. Ok. I'm still not convinced this approach is right at all; here's why: First, there are more bugs in the description: you're not going after the fact that the absolute DT_NEEDED entry cannot be overridden by $shlibpath_var, but that the absolute DT_NEEDED entry just isn't overridden by any other paths, not even DT_RPATH. Here's why: it may be possible that the system allows absolute DT_NEEDED entries, but that shlibpath_overrides_runpath=no. Then you're still out of luck when trying to relocate stuff. But once indirect dependencies come into play, this issue is still important, because now you don't only have the runpaths in that library at hand, but also those of the objects that are already loaded and higher up in the graph. True. What I'm trying to say: the current description doesn't make it clear that from a Libtool POV these variables are orthogonal to each other. Ok, so should I contribute a new patch with the rewording? I actually believe that the absolute DT_NEEDED is actually the normal case with most of the systems we have hardcode_direct=yes for; I just need some time to go check and prove that. Then, the right fix would be to kill this variable again and just reorder the hardcode methods in ltmain.in. -- albert chin ([EMAIL PROTECTED])
Ignore hardcode_direct=yes if results in static lib entry
The following patch addresses
http://lists.gnu.org/archive/html/libtool/2006-04/msg00044.html. I
added a new variable, hardcode_direct_static, to indicate if
hardcode_direct=yes would hardcode a static library dependency. This
impacts HP-UX/PA and AIX.
Patch against HEAD.
2006-05-16 Albert Chin-A-Young [EMAIL PROTECTED]
* libltdl/config/ltmain.m4sh, libltdl/m4/libtool.m4
(_LT_LINKER_SHLIBS, _LT_LANG_CXX_CONFIG, _LT_LANG_F77_CONFIG,
_LT_LANG_FC_CONFIG) [ aix4*, aix5*, hpux10*, hpux11* ]:
Introduce a new variable, hardcode_direct_static, which
would ignore hardcode_direct=yes if the result would create a
static library dependency. Static library dependencies are
immune to $shlibpath_var.
--
albert chin ([EMAIL PROTECTED])
-- snip snip
Index: libltdl/config/ltmain.m4sh
===
RCS file: /cvsroot/libtool/libtool/libltdl/config/ltmain.m4sh,v
retrieving revision 1.43
diff -u -p -r1.43 ltmain.m4sh
--- libltdl/config/ltmain.m4sh 14 May 2006 08:20:11 - 1.43
+++ libltdl/config/ltmain.m4sh 17 May 2006 00:58:16 -
@@ -3832,7 +3832,8 @@ func_mode_link ()
fi
;;
relink)
- if test $hardcode_direct = yes; then
+ if test $hardcode_direct = yes
+test $hardcode_direct_static = no; then
add=$dir/$linklib
elif test $hardcode_minus_L = yes; then
add_dir=-L$dir
@@ -3887,7 +3888,8 @@ func_mode_link ()
add_dir=
add=
# Finalize command for both is simple: just hardcode it.
- if test $hardcode_direct = yes; then
+ if test $hardcode_direct = yes
+ test $hardcode_direct_static = no; then
add=$libdir/$linklib
elif test $hardcode_minus_L = yes; then
add_dir=-L$libdir
Index: libltdl/m4/libtool.m4
===
RCS file: /cvsroot/libtool/libtool/libltdl/m4/libtool.m4,v
retrieving revision 1.65
diff -u -p -r1.65 libtool.m4
--- libltdl/m4/libtool.m4 15 May 2006 16:40:43 - 1.65
+++ libltdl/m4/libtool.m4 17 May 2006 00:58:16 -
@@ -3967,6 +3968,7 @@ m4_if([$1], [CXX], [
_LT_TAGVAR(export_symbols_cmds, $1)='$NM $libobjs $convenience |
$global_symbol_pipe | $SED '\''s/.* //'\'' | sort | uniq $export_symbols'
_LT_TAGVAR(hardcode_automatic, $1)=no
_LT_TAGVAR(hardcode_direct, $1)=no
+ _LT_TAGVAR(hardcode_direct_static, $1)=no
_LT_TAGVAR(hardcode_libdir_flag_spec, $1)=
_LT_TAGVAR(hardcode_libdir_flag_spec_ld, $1)=
_LT_TAGVAR(hardcode_libdir_separator, $1)=
@@ -4316,6 +4318,7 @@ _LT_EOF
_LT_TAGVAR(archive_cmds, $1)=''
_LT_TAGVAR(hardcode_direct, $1)=yes
+ _LT_TAGVAR(hardcode_direct_static, $1)=yes
_LT_TAGVAR(hardcode_libdir_separator, $1)=':'
_LT_TAGVAR(link_all_deplibs, $1)=yes
_LT_TAGVAR(file_list_spec, $1)='${wl}-f,'
@@ -4561,6 +4564,7 @@ _LT_EOF
_LT_TAGVAR(hardcode_libdir_flag_spec_ld, $1)='+b $libdir'
_LT_TAGVAR(hardcode_libdir_separator, $1)=:
_LT_TAGVAR(hardcode_direct, $1)=yes
+ _LT_TAGVAR(hardcode_direct_static, $1)=yes
_LT_TAGVAR(export_dynamic_flag_spec, $1)='${wl}-E'
# hardcode_minus_L: Not really in the search PATH,
# but as the default location of the library.
@@ -4605,6 +4609,7 @@ _LT_EOF
;;
*)
_LT_TAGVAR(hardcode_direct, $1)=yes
+ _LT_TAGVAR(hardcode_direct_static, $1)=yes
_LT_TAGVAR(export_dynamic_flag_spec, $1)='${wl}-E'
# hardcode_minus_L: Not really in the search PATH,
@@ -4975,6 +4980,11 @@ _LT_TAGDECL([], [hardcode_libdir_separat
_LT_TAGDECL([], [hardcode_direct], [0],
[Set to yes if using DIR/libNAME${shared_ext} during linking hardcodes
DIR into the resulting binary])
+_LT_TAGDECL([], [hardcode_direct_static], [0],
+[Set to yes if using DIR/libNAME${shared_ext} during linking hardcodes
+DIR into the resulting binary and the resulting library dependency is
+static, impossible to change by setting ${shlibpath_var} if the
+library is relocated])
_LT_TAGDECL([], [hardcode_minus_L], [0],
[Set to yes if using the -LDIR flag during linking hardcodes DIR
into the resulting binary])
@@ -5134,6 +5144,7 @@ _LT_TAGVAR(always_export_symbols, $1)=no
_LT_TAGVAR(archive_expsym_cmds, $1)=
_LT_TAGVAR(export_dynamic_flag_spec, $1)=
_LT_TAGVAR(hardcode_direct, $1)=no
+_LT_TAGVAR(hardcode_direct_static, $1)=no
_LT_TAGVAR(hardcode_libdir_flag_spec, $1)=
_LT_TAGVAR(hardcode_libdir_flag_spec_ld, $1)=
_LT_TAGVAR(hardcode_libdir_separator, $1)=
@@ -6390,6 +6401,7 @@ _LT_TAGVAR(always_export_symbols, $1)=no
_LT_TAGVAR(archive_expsym_cmds, $1)=
_LT_TAGVAR(export_dynamic_flag_spec, $1)=
_LT_TAGVAR(hardcode_direct, $1)=no
+_LT_TAGVAR(hardcode_direct_static, $1)=no
_LT_TAGVAR
Re: fail.at failing on HP-UX
On Wed, May 03, 2006 at 06:16:46PM +0200, Ralf Wildenhues wrote: This should work. Let's just hope there is no legacy system where both test -x doesn't work and the linker outputs broken binaries. OK? (We can still factor it nicely in a macro should we need it elsewhere.) It works fine. Thanks. -- albert chin ([EMAIL PROTECTED]) ___ http://lists.gnu.org/mailman/listinfo/libtool
fail.at failing on HP-UX
I'm getting the following test failure from HEAD on HP-UX 11.23/PA:
$ gmake check-local TESTSUITE_FLAGS=15 -v
...
fail.at:54: if $LIBTOOL --mode=link $CC $CFLAGS $LDFLAGS -o a a.$OBJEXT; then
(exit 1); else :; fi
stderr:
/usr/ccs/bin/ld: Unsatisfied symbols:
main (Not referenced yet! Probably due to -u option)
stdout:
libtool: link: cc -z +O2 +Olit=all +Onofltacc +Oentrysched +Odataprefetch
+Onolimit -o a a.o
fail.at:55: test -f a || test -f a$EXEEXT
fail.at:55: exit code was 0, expected 1
15. fail.at:22: FAILED (fail.at:55)
The code in tests/fail.at:
echo 'int not_main(void) { return 0; }' a.c
$CC $CPPFLAGS $CFLAGS -c a.c
FAIL_CHECK([$LIBTOOL --mode=link $CC $CFLAGS $LDFLAGS -o a a.$OBJEXT])
AT_CHECK([test -f a || test -f a$EXEEXT], [1])
$ echo 'int not_main(void) { return 0; }' a.c
$ cc -c a.c
$ sh /opt/build/libtool/libtool --mode=link cc -o a a.o
libtool: link: cc -o a a.o
/usr/ccs/bin/ld: Unsatisfied symbols:
main (Not referenced yet! Probably due to -u option)
However, even though there is no main, `a' is still created. How do we
work around this?
--
albert chin ([EMAIL PROTECTED])
___
http://lists.gnu.org/mailman/listinfo/libtool
Re: fail.at failing on HP-UX
On Sun, Apr 30, 2006 at 05:09:23PM +0200, Ralf Wildenhues wrote: * Albert Chin wrote on Sun, Apr 30, 2006 at 05:00:46PM CEST: I'm getting the following test failure from HEAD on HP-UX 11.23/PA: However, even though there is no main, `a' is still created. How do we work around this? Yes. I didn't finish this when I saw it, several weeks ago. Bob suggested removing the binary in mode=link when an error occurred, I am hesitant as the binary may still be useful for the clueful developer. If cc doesn't remove it, libtool definitely should not. OTOH another `make' may erroneously report nothing to do, depending on whether the binary appears in the current directory or in .libs/. That's ok, as, if they were using cc, they would encounter the same problem. Can we XFAIL it for now on *-hpux*? How do I do this? -- albert chin ([EMAIL PROTECTED]) ___ http://lists.gnu.org/mailman/listinfo/libtool
Remove duplicate hardcode_direct=yes for AIX
$hardcode_direct is set twice for AIX.
2006-04-29 Albert Chin-A-Young [EMAIL PROTECTED]
* libltdl/m4/libtool.m4 (_LT_LINKER_SHLIBS) [ aix ]:
$hardcode_direct is set twice.
--
albert chin ([EMAIL PROTECTED])
-- snip snip
Index: libltdl/m4/libtool.m4
===
RCS file: /cvsroot/libtool/libtool/libltdl/m4/libtool.m4,v
retrieving revision 1.63
diff -u -p -U14 -r1.63 libtool.m4
--- libltdl/m4/libtool.m4 28 Mar 2006 18:11:28 - 1.63
+++ libltdl/m4/libtool.m4 30 Apr 2006 01:08:30 -
@@ -4283,29 +4284,29 @@ _LT_EOF
_LT_TAGVAR(hardcode_direct, $1)=yes
_LT_TAGVAR(hardcode_libdir_separator, $1)=':'
_LT_TAGVAR(link_all_deplibs, $1)=yes
_LT_TAGVAR(file_list_spec, $1)='${wl}-f,'
if test $GCC = yes; then
case $host_os in aix4.[[012]]|aix4.[[012]].*)
# We only want to do this on AIX 4.2 and lower, the check
# below for broken collect2 doesn't work under 4.3+
collect2name=`${CC} -print-prog-name=collect2`
if test -f $collect2name
strings $collect2name | $GREP resolve_lib_name /dev/null
then
# We have reworked collect2
- _LT_TAGVAR(hardcode_direct, $1)=yes
+ :
else
# We have old collect2
_LT_TAGVAR(hardcode_direct, $1)=unsupported
# It fails to find uninstalled libraries when the uninstalled
# path is not listed in the libpath. Setting hardcode_minus_L
# to unsupported forces relinking
_LT_TAGVAR(hardcode_minus_L, $1)=yes
_LT_TAGVAR(hardcode_libdir_flag_spec, $1)='-L$libdir'
_LT_TAGVAR(hardcode_libdir_separator, $1)=
fi
;;
esac
shared_flag='-shared'
if test $aix_use_runtimelinking = yes; then
Re: hardcode_direct problem on HP-UX/PA
On Tue, Apr 25, 2006 at 01:52:00PM -0500, Albert Chin wrote: [snip snip] How do we solve this? Either we set hardcode_direct=no for these platforms or, in ltmain.in, make it smart enough to check and use hardcode_minus_L=yes before hardcode_direct=yes. Another possibility is to add a new variable, hardcode_direct_static, that defines whether or not the above is true for the specified system. We'd then modify ltmain.in to take hardcode_direct_static=yes into consideration when hardcode_direct=yes. -- albert chin ([EMAIL PROTECTED]) ___ http://lists.gnu.org/mailman/listinfo/libtool
HEAD link-order.at fails when hardcode_direct=yes
On systems with hardcode_direct=yes, the following section in tests/link-order.at will fail: AT_CHECK([if $EGREP relinking stderr; then $EGREP ' -L.*\/new\/lib -lb -L.*\/old\/lib -lcee' stdout else :; fi], [0], [ignore], [], [echo wrong link order]) Why? Because -L.*\/new\/lib -lb will be converted to .*\/new\/lib/liblb$shrext_cmds. Patch attached. Note, the new RE doesn't fully address what you intended. The original libtool output: libtool: install: warning: relinking `src/liba.la' stdout: libtool: install: (cd /opt/build/libtool/tests/testsuite.dir/14; /bin/sh /opt/build/libtool/libtool --mode=relink cc -z +O2 +Olit=all +Onofltacc +Oentrysched +Odataprefetch +Onolimit -no-undefined -o src/liba.la src/a.lo src/libb.la -L/opt/build/libtool/tests/testsuite.dir/14/old/lib -lcee -rpath /opt/build/libtool/tests/testsuite.dir/14/new/lib ) libtool: relink: cc -b -Wl,+h -Wl,liba.sl.0 -Wl,+b -Wl,/opt/build/libtool/tests/testsuite.dir/14/new/lib -o src/.libs/liba.sl.0.0 src/.libs/a.o /opt/build/libtool/tests/testsuite.dir/14/new/lib/libb.sl -L/opt/build/libtool/tests/testsuite.dir/14/old/lib /opt/build/libtool/tests/testsuite.dir/14/old/lib/libcee.sl -lc Note the link order above is: /opt/build/libtool/tests/testsuite.dir/14/new/lib/libb.sl -L/opt/build/libtool/tests/testsuite.dir/14/old/lib /opt/build/libtool/tests/testsuite.dir/14/old/lib/libcee.sl rather than what you probably want: /opt/build/libtool/tests/testsuite.dir/14/new/lib/libb.sl /opt/build/libtool/tests/testsuite.dir/14/old/lib/libcee.sl But the .* pattern sucks up the -L/opt/build/libtool/tests/testsuite.dir/14/old/lib. 2006-05-25 Albert Chin-A-Young [EMAIL PROTECTED] * tests/link-order.at: Take hardcode_direct into consideration when testing link order. -- albert chin ([EMAIL PROTECTED]) Index: tests/link-order.at === RCS file: /cvsroot/libtool/libtool/tests/link-order.at,v retrieving revision 1.9 diff -u -3 -p -r1.9 link-order.at --- tests/link-order.at 5 Feb 2006 09:56:44 - 1.9 +++ tests/link-order.at 25 Apr 2006 19:51:16 - @@ -20,6 +20,7 @@ AT_SETUP([Link order test.]) AT_KEYWORDS([libtool]) +eval `$LIBTOOL --config | $EGREP '^(hardcode_direct|shrext_cmds)='` LDFLAGS=$LDFLAGS -no-undefined prefix_old=`pwd`/old @@ -68,10 +69,18 @@ case $host_os in aix* | interix*) ;; # These systems have different path syntax *) # Do not error if we do not relink (e.g. static-only systems) - AT_CHECK([if $EGREP relinking stderr; then - $EGREP ' -L.*\/new\/lib -lb -L.*\/old\/lib -lcee' stdout - else :; fi], [0], [ignore], [], [echo wrong link order]) - ;; + case $hardcode_direct in + yes) +AT_CHECK([if $EGREP relinking stderr; then + $EGREP .*\/new\/lib/libb$shrext_cmds .*\/old\/lib/libcee$shrext_cmds stdout + else :; fi], [0], [ignore], [], [echo wrong link order]) +;; + no) +AT_CHECK([if $EGREP relinking stderr; then + $EGREP -L.*\/new\/lib -lb -L.*\/old\/lib -lcee stdout + else :; fi], [0], [ignore], [], [echo wrong link order]) +;; + esac esac for i in old new; do
Re: Uninstalled interlibrary dependencies
On Tue, Mar 14, 2006 at 03:30:55PM +0100, Magnus Lie Hetland wrote: It seems a bit icky to use Autotools, and then to slap on an if statement to choose between DYLD_LIBRARY_PATH and LD_LIBRARY_PATH... (I guess this might be in the docs, though. I'll have another look there.) Set them all: DYLD_LIBRARY_PATH=... LD_LIBRARY_PATH=... SHLIB_PATH=... LIBPATH=... \ python ... -- albert chin ([EMAIL PROTECTED]) ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Solaris whole_archive_flags fixes
On Fri, Feb 03, 2006 at 05:03:35PM +0100, Ralf Wildenhues wrote: We still did not have whole_archive_flag_spec right for Solaris. The whole issue is pretty simple to really solve though: no `$wl' for Solaris cc/CC/f77/f90/f95 compilers, always `-Wl,' for GCC. To increase the chance of being correct this time, I have tested these compilers:[1]. And I have reread most threads of the last 18 months that dealt with Solaris, to make sure there was no report that disproved this solution. OK to apply to both branches? I guess I should have done more testing with my original patch :) http://lists.gnu.org/archive/html/libtool-patches/2004-02/msg00138.html Good work. Thanks. -- albert chin ([EMAIL PROTECTED])
Re: per-deplib static/dynamic flags
On Wed, Feb 01, 2006 at 12:47:51AM -0600, Bob Friesenhahn wrote: On Tue, 31 Jan 2006, Albert Chin wrote: On Mon, Jan 30, 2006 at 10:28:52PM +0100, Ralf Wildenhues wrote: - Should the corresponding libtool flags be named `-Bstatic' resp. `-Bdynamic'? Those were the most common names I could find, but IMHO they are not very self-explanatory for users not used to them. -prefer-static, -prefer-dynamic/-prefer-shared? The -Bxxx doesn't seem similar with current libtool options. At least for the static case, I would prefer the link to entirely fail if a static library is requested but one can not be found. Usually there is a very important reason to use a static library if it has specifically been requested. So the wording should not be 'prefer' for the static case. I agree that the -B syntax does not fit the style of other libtool options (but does match many linkers). Fine. -Bstatic on Linux means Do not link against shared libraries. anyway. -- albert chin ([EMAIL PROTECTED])
Re: per-deplib static/dynamic flags
On Wed, Feb 01, 2006 at 05:40:51PM -0600, Bob Friesenhahn wrote:
On Wed, 1 Feb 2006, Albert Chin wrote:
Fine. -Bstatic on Linux means Do not link against shared libraries.
anyway.
Good. GCC uses -B to mean something else. So -Bstatic is a
linker-only option. It is likely useful to use something new which
won't be confusing due the different meaning between GCC and ld.
How about -static-only and -shared-only?
Note though that Ralf has -Bstatic defined as:
If @var{output-file} is a program, prefer linking statically
^^
This is not -Bstatic under Linux according to ld(1). If this is what
is intended, then -prefer-static is back :)
--
albert chin ([EMAIL PROTECTED])
Re: per-deplib static/dynamic flags
On Mon, Jan 30, 2006 at 10:28:52PM +0100, Ralf Wildenhues wrote: - Should the corresponding libtool flags be named `-Bstatic' resp. `-Bdynamic'? Those were the most common names I could find, but IMHO they are not very self-explanatory for users not used to them. -prefer-static, -prefer-dynamic/-prefer-shared? The -Bxxx doesn't seem similar with current libtool options. -- albert chin ([EMAIL PROTECTED])
Re: per-deplib static/dynamic flags
On Mon, Jan 30, 2006 at 10:28:52PM +0100, Ralf Wildenhues wrote: - Should the corresponding libtool flags be named `-Bstatic' resp. `-Bdynamic'? Those were the most common names I could find, but IMHO they are not very self-explanatory for users not used to them. -prefer-static, -prefer-dynamic/-prefer-shared? The -Bxxx doesn't seem similar with current libtool options. -- albert chin ([EMAIL PROTECTED]) ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: FYI: update years
On Wed, Jan 11, 2006 at 06:25:06PM +0100, Ralf Wildenhues wrote: The other half of the annual change. Applied to HEAD and branch-1-5, respectively (also fixing some past missing years in branch-1-5). For those asking about changes to year without other changes: in some cases we generate `--version' output from this, so it's really needed. And anyway, we'll likely make changes anyway till the next release; some other files still needed updates for last year. Isn't this a question of Copyright law, which easily trounces --version? -- albert chin ([EMAIL PROTECTED])
On HP-UX 11.x, link with cc, not ld (sync with HEAD)
On HEAD, we link with cc rather than ld on HP-UX 11.x. Backport to
1.5. Dunno why I didn't do this long time ago when I submitted the cc
linking patches for Solaris, IRIX, etc.
2005-11-10 Albert Chin-A-Young [EMAIL PROTECTED]
* libtool.m4 (AC_LIBTOOL_PROG_LD_SHLIBS) [ hpux10 ]:
Link with cc rather than ld (backport from HEAD).
--
albert chin ([EMAIL PROTECTED])
Index: libtool.m4
===
RCS file: /cvsroot/libtool/libtool/Attic/libtool.m4,v
retrieving revision 1.314.2.128
diff -u -3 -p -r1.314.2.128 libtool.m4
--- libtool.m4 10 Nov 2005 18:29:38 - 1.314.2.128
+++ libtool.m4 11 Nov 2005 03:44:03 -
@@ -5792,7 +5792,26 @@ EOF
_LT_AC_TAGVAR(export_dynamic_flag_spec, $1)='${wl}-E'
;;
-hpux10* | hpux11*)
+hpux10*)
+ if test $GCC = yes; then
+ _LT_AC_TAGVAR(archive_cmds, $1)='$CC -shared -fPIC ${wl}+h ${wl}$soname
${wl}+b ${wl}$install_libdir -o $lib $libobjs $deplibs $compiler_flags'
+ else
+ _LT_AC_TAGVAR(archive_cmds, $1)='$LD -b +h $soname +b $install_libdir
-o $lib $libobjs $deplibs $linker_flags'
+ fi
+ if test $with_gnu_ld = no; then
+ _LT_AC_TAGVAR(hardcode_libdir_flag_spec, $1)='${wl}+b ${wl}$libdir'
+ _LT_AC_TAGVAR(hardcode_libdir_separator, $1)=:
+
+ _LT_AC_TAGVAR(hardcode_direct, $1)=yes
+ _LT_AC_TAGVAR(export_dynamic_flag_spec, $1)='${wl}-E'
+
+ # hardcode_minus_L: Not really in the search PATH,
+ # but as the default location of the library.
+ _LT_AC_TAGVAR(hardcode_minus_L, $1)=yes
+ fi
+ ;;
+
+hpux11*)
if test $GCC = yes -a $with_gnu_ld = no; then
case $host_cpu in
hppa*64*|ia64*)
@@ -5805,10 +5824,10 @@ EOF
else
case $host_cpu in
hppa*64*|ia64*)
- _LT_AC_TAGVAR(archive_cmds, $1)='$LD -b +h $soname -o $lib $libobjs
$deplibs $linker_flags'
+ _LT_AC_TAGVAR(archive_cmds, $1)='$CC -b ${wl}+h ${wl}$soname -o $lib
$libobjs $deplibs $compiler_flags'
;;
*)
- _LT_AC_TAGVAR(archive_cmds, $1)='$LD -b +h $soname +b $install_libdir
-o $lib $libobjs $deplibs $linker_flags'
+ _LT_AC_TAGVAR(archive_cmds, $1)='$CC -b ${wl}+h ${wl}$soname ${wl}+b
${wl}$install_libdir -o $lib $libobjs $deplibs $compiler_flags'
;;
esac
fi
Sync C++ linking on HEAD with branch-1-5
When linking C++ libraries/programs, link with the compiler, not the
linker. Syncs with branch-1-5.
--
albert chin ([EMAIL PROTECTED])
-- snip snip
2005-11-09 Albert Chin-A-Young [EMAIL PROTECTED]
* libltdl/m4/libtool.m4 (_LT_LANG_CXX_CONFIG): Sync C++
linking on HP-UX with branch-1-5. Use C++ compiler for
linking rather than ld.
Index: libltdl/m4/libtool.m4
===
RCS file: /cvsroot/libtool/libtool/libltdl/m4/libtool.m4,v
retrieving revision 1.36
diff -u -3 -p -r1.36 libtool.m4
--- libltdl/m4/libtool.m4 7 Nov 2005 18:28:25 - 1.36
+++ libltdl/m4/libtool.m4 9 Nov 2005 16:06:29 -
@@ -5429,7 +5430,7 @@ if test $_lt_caught_CXX_error != yes;
aCC*)
case $host_cpu in
hppa*64*|ia64*)
- _LT_TAGVAR(archive_cmds, $1)='$LD -b +h $soname -o $lib
$linker_flags $libobjs $deplibs'
+ _LT_TAGVAR(archive_cmds, $1)='$CC -b ${wl}+h ${wl}$soname -o
$lib $predep_objects $libobjs $deplibs $postdep_objects $compiler_flags'
;;
*)
_LT_TAGVAR(archive_cmds, $1)='$CC -b ${wl}+h ${wl}$soname
${wl}+b ${wl}$install_libdir -o $lib $predep_objects $libobjs $deplibs
$postdep_objects $compiler_flags'
@@ -5450,7 +5451,7 @@ if test $_lt_caught_CXX_error != yes;
if test $with_gnu_ld = no; then
case $host_cpu in
ia64*|hppa*64*)
- _LT_TAGVAR(archive_cmds, $1)='$LD -b +h $soname -o $lib
$linker_flags $libobjs $deplibs'
+ _LT_TAGVAR(archive_cmds, $1)='$CC -shared -nostdlib -fPIC
${wl}+h ${wl}$soname -o $lib $predep_objects $libobjs $deplibs $postdep_objects
$compiler_flags'
;;
*)
_LT_TAGVAR(archive_cmds, $1)='$CC -shared -nostdlib -fPIC
${wl}+h ${wl}$soname ${wl}+b ${wl}$install_libdir -o $lib $predep_objects
$libobjs $deplibs $postdep_objects $compiler_flags'
Re: Sync C++ linking on HEAD with branch-1-5
On Wed, Nov 09, 2005 at 09:51:12PM +0100, Ralf Wildenhues wrote: * Albert Chin wrote on Wed, Nov 09, 2005 at 05:11:09PM CET: When linking C++ libraries/programs, link with the compiler, not the linker. Syncs with branch-1-5. Erm, I can't see this in branch-1-5. Oops. My fault. It isn't. I was looking at our patched version. It's hpux10*|hpux11*, and hppa*64*|ia64*, and aCC|g++, right? I can vouch for it on hpux11*, hppa*64*, and ia64*, for aCC and g++. We don't have hpux10* to test it on. Does something fail without the patch (what)? Should I apply it to branch-1-5 as well? The recommended way to create shared libraries on HP-UX 11.x with aCC is 'CC -b'. This is a similar change to using 'cc -b' to create shared libraries on HP-UX 11.x rather than ld. Want me to factor out hpux10 like we did for the cc case? -- albert chin ([EMAIL PROTECTED])
Re: Sync C++ linking on HEAD with branch-1-5
On Wed, Nov 09, 2005 at 08:23:05PM -0600, Albert Chin wrote: On Wed, Nov 09, 2005 at 09:51:12PM +0100, Ralf Wildenhues wrote: * Albert Chin wrote on Wed, Nov 09, 2005 at 05:11:09PM CET: It's hpux10*|hpux11*, and hppa*64*|ia64*, and aCC|g++, right? I can vouch for it on hpux11*, hppa*64*, and ia64*, for aCC and g++. We don't have hpux10* to test it on. Documentation for the old C++ compiler on HP (aCC): http://docs.hp.com/en/1314/options.htm It documents use of '-b' to create a shared library: http://docs.hp.com/en/1314/options.htm#option-b From this documentation: CAUTION: You must use the aCC command to link your HP aC++ programs and libraries. This ensures that all libraries and other files needed by the linker are available. This URL also documents using aCC to create shared libraries: http://docs.hp.com/en/1314/libs.htm#shlib Want me to factor out hpux10 like we did for the cc case? Looks like this is not needed. Actually, looking at my patch, it only changes it for hppa*64, ia64*. aCC, on these platforms, is always the correct method to link shared libraries. -- albert chin ([EMAIL PROTECTED])
Re: AM_FCFLAGS not working as I expect...
On Wed, Nov 09, 2005 at 11:10:26AM -0700, Ed Hartnett wrote: Albert Chin [EMAIL PROTECTED] writes: On Tue, Nov 08, 2005 at 06:43:43AM -0700, Ed Hartnett wrote: Ralf Wildenhues [EMAIL PROTECTED] writes: The Makefile.am does include: .f90.o: $(FCCOMPILE) -c -o $@ $(AM_FCFLAGS) $(FCFLAGS_f90) $ .f90.obj: $(FCCOMPILE) -c -o $@ $(AM_FCFLAGS) $(FCFLAGS_f90) `$(CYGPATH_W) '$'` .f90.lo: $(LTFCCOMPILE) -c -o $@ $(FCFLAGS_f90) $ as you suggested. Unfortunately, that didn't seem to help libtools tag problem. If --tag=F77 works, add it to the above. But where? If I put it after $(LTFCCOMPILE) I get: /bin/sh ../libtool --mode=compile mpxlf_r -I../libsrc -I. -g --tag=F77 -c -o netcdf.lo netcdf.f90 libtool: compile: unable to infer tagged configuration libtool: compile: specify a tag with `--tag' make: *** [netcdf.lo] Error 1 It looks like it has to go inside LTFCCOMPILE. How do I do that? See Ralf's email. -- albert chin ([EMAIL PROTECTED]) ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: AM_FCFLAGS not working as I expect...
On Tue, Nov 08, 2005 at 06:43:43AM -0700, Ed Hartnett wrote: Ralf Wildenhues [EMAIL PROTECTED] writes: I forgot one thing: If you're trying to use libtool with the FC (Fortran 90/95) interface, you are likely to have to go through hoops with libtool-1.5.x, since it doesn't support it. Current CVS Libtool, which will hopefully soon be Libtool-2.0, does support FC. I am now using 1.5.20 everywhere, which is the most recent release, I believe. I am getting make distcheck working in the hopes that by doing so, I might in some way fix my libtool problems on AIX. Show the issues, please. Here it is, still can't get f95 code to compile... Making all in f90 make[2]: Entering directory `/home/bluesky/edh/netcdf-3/f90' /bin/sh ../libtool --mode=compile xlf90 -I../libsrc -I. -g -c -o typeSizes.lo typeSizes.f90 libtool: compile: unable to infer tagged configuration libtool: compile: specify a tag with `--tag' make[2]: *** [typeSizes.lo] Error 1 make[2]: Leaving directory `/home/bluesky/edh/netcdf-3/f90' Just means libtool doesn't know that xlf90 == Fortran. Does this work: $ cd /home/bluesky/edh/netcdf-3/f90 $ /bin/sh ../libtool --tag=F77 --mode=compile xlf90 -I../libsrc -I. \ -g -c -o typeSizes.lo typeSizes.f90 The Makefile.am does include: .f90.o: $(FCCOMPILE) -c -o $@ $(AM_FCFLAGS) $(FCFLAGS_f90) $ .f90.obj: $(FCCOMPILE) -c -o $@ $(AM_FCFLAGS) $(FCFLAGS_f90) `$(CYGPATH_W) '$'` .f90.lo: $(LTFCCOMPILE) -c -o $@ $(FCFLAGS_f90) $ as you suggested. Unfortunately, that didn't seem to help libtools tag problem. If --tag=F77 works, add it to the above. -- albert chin ([EMAIL PROTECTED]) ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: SCO/bugfix patch 5 of 10: ltmain.in: exclude -lc on SCO platforms
On Fri, Nov 04, 2005 at 05:56:24PM +0100, Ralf Wildenhues wrote: Hi Tim, Kean, * Tim Rice wrote on Thu, Nov 03, 2005 at 05:25:02PM CET: On Sun, 30 Oct 2005, Kean Johnston wrote: Kean Johnston wrote: Patch 5 of 10 attached ... Tim caught a small ommission. A corrected patch is attached. Hmm. We're pretty wary of adding system-specifics to ltmain, and I do agree with Albert that this ugly. OTOH, I do see the given negative consequences, too. They are rather unacceptable. Is gettext the only package that exposes this? Could you be bothered to write a bug report (or have already done so)? Well, Tim said we do it for other platforms so I say we accept the patch: *-*-os2*) # These systems don't actually have a C library (as such) test X$arg = X-lc continue ;; -- albert chin ([EMAIL PROTECTED])
Re: hardcode_minus_L on HP-UX 11.23/IA-64
On Fri, Nov 04, 2005 at 05:38:20PM +0100, Ralf Wildenhues wrote: * Albert Chin wrote on Thu, Nov 03, 2005 at 04:09:03AM CET: From ld(1) on HP-UX 11.23/IA-64: +[no]defaultrpath +defaultrpath is the default. Include any paths that are specified with -L in the embedded path, unless you specify the +b option. If you use +b, only the path list specified by +b is in the embedded path. The +nodefaultrpath option removes all library paths that were specified with the -L option from the embedded path. The linker searches the library paths specified by the -L option at link time. At run time, the only library paths searched are those specified by the environment variables LD_LIBRARY_PATH and SHLIB_PATH, library paths specified by the +b linker option, and finally the default library paths. So, hardcode_minus_L=yes is incorrect on this platform if +nodefaultrpath is in LDFLAGS. ACK. Or when we put at least one +b in the command line. Hmm, when creating a library, we use +b anyway. Yes. But, if the LDFLAGS=-L[path], we're screwed without +nodefaultrpath. I've submitted a patch so that on ia64*, we use +nodefaultrpath when creating libraries. Is it guaranteed that we already use -L for each directory in question when creating a program? Ie., there don't appear any +b, right? Should we set hardcode_minus_L=yes only when there is no +nodefaultrpath (similar to how we set aix_use_runtimelinking=yes when LDFLAGS has -brtl in it)? Probably a good idea. Do you have access to HP-UX 11 (how about 9, 10?) to test? 11.23/PA ld(1) doesn't document +nodefaultrpath, 11.00/PA documents it for 32-bit SOM, and 11.11/PA documents it for 64-bit ELF. Probably a new feature that requires an updated linker patch. We should probably do this only when the compiler and linker driver are the same. Erm, why? Where does the compiler driver come into play here? Forgot what I was thinking here :) -- albert chin ([EMAIL PROTECTED]) ___ http://lists.gnu.org/mailman/listinfo/libtool
hardcode_minus_L on HP-UX 11.23/IA-64
From ld(1) on HP-UX 11.23/IA-64: +[no]defaultrpath +defaultrpath is the default. Include any paths that are specified with -L in the embedded path, unless you specify the +b option. If you use +b, only the path list specified by +b is in the embedded path. The +nodefaultrpath option removes all library paths that were specified with the -L option from the embedded path. The linker searches the library paths specified by the -L option at link time. At run time, the only library paths searched are those specified by the environment variables LD_LIBRARY_PATH and SHLIB_PATH, library paths specified by the +b linker option, and finally the default library paths. So, hardcode_minus_L=yes is incorrect on this platform if +nodefaultrpath is in LDFLAGS. Should we set hardcode_minus_L=yes only when there is no +nodefaultrpath (similar to how we set aix_use_runtimelinking=yes when LDFLAGS has -brtl in it)? We should probably do this only when the compiler and linker driver are the same. -- albert chin ([EMAIL PROTECTED]) ___ http://lists.gnu.org/mailman/listinfo/libtool
Remove duplicate settion of archive_expsym_cmds=yes on AIX
always_export_symbols is set before the if statement enclosing the
code below so remove duplicates.
Patch against branch-1-5.
2005-10-30 Albert Chin-A-Young [EMAIL PROTECTED]
* libtool.m4 (AC_LIBTOOL_LANG_CXX_CONFIG,
AC_LIBTOOL_PROG_LD_SHLIBS): Remove duplicate
always_export_symbols=yes for AIX.
--
albert chin ([EMAIL PROTECTED])
-- snip snip
Index: libtool.m4
===
RCS file: /cvsroot/libtool/libtool/Attic/libtool.m4,v
retrieving revision 1.314.2.115
diff -u -3 -p -r1.314.2.115 libtool.m4
--- libtool.m4 9 Oct 2005 06:26:21 - 1.314.2.115
+++ libtool.m4 31 Oct 2005 06:13:28 -
@@ -2930,8 +2930,6 @@ case $host_os in
# -berok will link without error, but may produce a broken library.
_LT_AC_TAGVAR(no_undefined_flag, $1)=' ${wl}-bernotok'
_LT_AC_TAGVAR(allow_undefined_flag, $1)=' ${wl}-berok'
- # -bexpall does not export symbols beginning with underscore (_)
- _LT_AC_TAGVAR(always_export_symbols, $1)=yes
# Exported symbols can be pulled into shared objects from archives
_LT_AC_TAGVAR(whole_archive_flag_spec, $1)=' '
_LT_AC_TAGVAR(archive_cmds_need_lc, $1)=yes
@@ -5626,8 +5624,6 @@ EOF
# -berok will link without error, but may produce a broken library.
_LT_AC_TAGVAR(no_undefined_flag, $1)=' ${wl}-bernotok'
_LT_AC_TAGVAR(allow_undefined_flag, $1)=' ${wl}-berok'
- # -bexpall does not export symbols beginning with underscore (_)
- _LT_AC_TAGVAR(always_export_symbols, $1)=yes
# Exported symbols can be pulled into shared objects from archives
_LT_AC_TAGVAR(whole_archive_flag_spec, $1)=' '
_LT_AC_TAGVAR(archive_cmds_need_lc, $1)=yes
Re: -dlopen self on AIX
On Sun, Oct 30, 2005 at 12:16:01PM -0600, Albert Chin wrote: On Sun, Oct 30, 2005 at 11:56:30AM -0600, Albert Chin wrote: On Sun, Oct 30, 2005 at 11:14:14AM -0600, Albert Chin wrote: [snip ...] This means the method libtool uses to support -dlopen self on AIX won't work (by building a list of symbols into some xxS.o file and linking it with the executable). The real solution is to -bE the symbol list. What's the cleanest way to do this? Dynamic module support in openldap-2.3.x isn't working on AIX for the above reason. Using -bexpall or -bE when linking the main binary does work though. While the main binary, slapd, doesn't dlopen itself, modules it dlopen()'s cannot resolve symbols in slapd because they weren't exported. Seems the openldap folks should really use -export-dynamic, which isn't defined for AIX. We could make it -bexpall but as documented in the previous mail, it doesn't export everything. So, should we create a new variable, export_dynamic_cmds? If so, and temporary files are created by it, how do we clean up? Related to this, if always_export_symbols=yes, shouldn't we run $export_symbols_cmds against programs as well? export_symbols_cmds=yes only on AIX but it's equally important for programs and libraries. I finished a patch for this but it's not robust. There's nothing we can do. If a program links against an archive library in the build process, the linker will pull in whatever symbols it needs from the archive library. If we export a full set of symbols from both the program and the library, we might get unresolved symbols from the linker because we've included symbols in the export list that the linker wouldn't pull in from the archive library because the program never references them. Oh well. -- albert chin ([EMAIL PROTECTED]) ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: -dlopen self on AIX
On Sun, Oct 30, 2005 at 12:10:23PM -0800, Howard Chu wrote: Albert Chin wrote: [snip ...] Dynamic module support in openldap-2.3.x isn't working on AIX for the above reason. Using -bexpall or -bE when linking the main binary does work though. While the main binary, slapd, doesn't dlopen itself, modules it dlopen()'s cannot resolve symbols in slapd because they weren't exported. I don't recall what particular hacks we've done to libtool for this on AIX, but Symas builds everything as dynamic modules on all of our platforms, and mostly It Just Works. (Including IBM AIX and z/OS, as well as Solaris, HPUX, Linux, Windows, etc.) In general the only thing I've hacked was to prevent build directories from being embedded into the generated files, and to eliminate all relinking. I've submitted most of our changes back to this list in the past; a lot may have fallen on the floor since those were patches against libtool 1.4. I'll follow up on the OpenLDAP mailing list. I can reproduce my error with a virgin build/install of 2.3.11. -- albert chin ([EMAIL PROTECTED]) ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: bootstrap warning
On Fri, Oct 28, 2005 at 10:05:07AM +0200, Ralf Wildenhues wrote: * Albert Chin wrote on Thu, Oct 27, 2005 at 11:56:31PM CEST: On Wed, Oct 26, 2005 at 06:55:11AM -0600, Eric Blake wrote: - diff vcl.tmp $(srcdir)/stamp-vcl /dev/null \ + diff vcl.tmp $(srcdir)/stamp-vcl /dev/null 2/dev/null \ Rather than /dev/null 2/dev/null, use /dev/null 21. Yep, will change on my next commit. Curious though, is there a non-asthetical reason to do this? No. -- albert chin ([EMAIL PROTECTED])
If -xarch passed in, don't set compiler_flags _only_ for GCC
HEAD sets compiler_flags in the code below regardless of whether or not GCC is the compiler. Why does branch-1-5 do it differently? If someone is building a 64-bit library with the Sun C++ compiler, -xarch=v9 won't get passed through and ld will try to create a 32-bit library, resulting in an error. 2005-10-17 Albert Chin-A-Young [EMAIL PROTECTED] * ltmain.in: When accepting -64, -mips[0-9], et. al. compiler flags, don't set compiler_flags only for GCC as the vendor compiler also requires this flag. Sync with HEAD. Reported by Donald Anderson [EMAIL PROTECTED]. -- albert chin ([EMAIL PROTECTED]) -- snip snip Index: ltmain.in === RCS file: /cvsroot/libtool/libtool/Attic/ltmain.in,v retrieving revision 1.334.2.90 diff -u -3 -p -r1.334.2.90 ltmain.in --- ltmain.in 17 Oct 2005 14:06:26 - 1.334.2.90 +++ ltmain.in 17 Oct 2005 20:57:59 - @@ -1550,9 +1550,7 @@ EOF esac compile_command=$compile_command $arg finalize_command=$finalize_command $arg -if test $with_gcc = yes ; then - compiler_flags=$compiler_flags $arg -fi +compiler_flags=$compiler_flags $arg continue ;;
Re: UnixWare -lc fixes
On Mon, Oct 17, 2005 at 09:53:29PM -0700, Tim Rice wrote: After looking over some stuff in http://gcc.gnu.org/ml/gcc-patches/2005-10/msg00839.html that related to libtool and some off list emails with Kean Johnston (the author of the gcc patch) and Ralf Wildenhues, I realize my UnixWare patch was incomplete. On UnixWare and OpenServer 56 we never want -lc on the command line. cc / CC takes care of that for us (and always gets it right). Setting build_libtool_need_lc=no takes care of most of it but that doesn't account for Makefiles adding -lc. Like this snip from gettext-0.14.5/gettext-runtime/intl/Makefile.in .. libintl.la libgnuintl.la: $(OBJECTS) $(LIBTOOL) --mode=link \ $(CC) $(CPPFLAGS) $(CFLAGS) $(XCFLAGS) $(LDFLAGS) -o $@ \ $(OBJECTS) @LTLIBICONV@ @INTL_MACOSX_LIBS@ $(LIBS) -lc \ -version-info $(LTV_CURRENT):$(LTV_REVISION):$(LTV_AGE) \ -rpath $(libdir) \ -no-undefined .. I had been patching Makefiles (post configure) in packages to strip out -lc. Now I realize libtool can do that for me. I've attached patches to branch-1-5 and HEAD. Ick. Packages like gettext need to be fixed, not libtool. Garbage in = Garbage out. -- albert chin ([EMAIL PROTECTED])
Re: problem linking with shared library
On Wed, Oct 12, 2005 at 01:03:12PM -0500, Nitesh Soni (NC/TNT) wrote: The error linker is giving is: ... libY.so: undefined reference to 'Z' Also, this symbol is not used anywhere in any source code required to build application X ( i mean if X depends on x.c y.c z.c and library libY .. none of the sources x.c y.c and z.c use this symbol) That's ok. libY might be dependent on another library where Z is defined. I am using gcc version 3.3.1 ( MontaVista ) building for x86. Odd that static linking works. You can extract the object files from libY.a to determine which one has Z undefined. As you have the source to libY, you can find out why the symbol is undefined. -Original Message- From: Albert Chin [mailto:[EMAIL PROTECTED] Sent: Wednesday, October 12, 2005 1:25 PM To: Nitesh Soni (NC/TNT) Cc: libtool@gnu.org Subject: Re: problem linking with shared library On Wed, Oct 12, 2005 at 11:22:42AM -0500, Nitesh Soni (NC/TNT) wrote: I am trying to build an executable X which links with libY. I am using libtool to build this library libY; so I have a static version libY.a and libY.so When I link the static version libY.a, i am able to build the application X But when I link against the shared version libY.so I am not able to build the application; it fails with some undefined reference to (lets say) Z Now I did nm libY.a and nm libY.so Both these versions have symbol Z as U Is symbol Z defined in executable X? What specific error is the linker giving? What platform? -- albert chin ([EMAIL PROTECTED]) -- albert chin ([EMAIL PROTECTED]) ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: problem linking with shared library
On Wed, Oct 12, 2005 at 01:56:39PM -0500, Nitesh Soni (NC/TNT) wrote: Now I dont understand one basic thing: Since both static and shared library versions of libY have this symbol as U when I link application X with static version it works but not with shared. Also, point to be noted is X is not using this symbol at all. How does shared and static libraries treat the symbols which are undefined.? When you link against a static library, only those symbols required by X are linked in. Thanks -Original Message- From: Albert Chin [mailto:[EMAIL PROTECTED] Sent: Wednesday, October 12, 2005 2:19 PM To: Nitesh Soni (NC/TNT) Cc: 'libtool@gnu.org' Subject: Re: problem linking with shared library On Wed, Oct 12, 2005 at 01:03:12PM -0500, Nitesh Soni (NC/TNT) wrote: The error linker is giving is: ... libY.so: undefined reference to 'Z' Also, this symbol is not used anywhere in any source code required to build application X ( i mean if X depends on x.c y.c z.c and library libY .. none of the sources x.c y.c and z.c use this symbol) That's ok. libY might be dependent on another library where Z is defined. I am using gcc version 3.3.1 ( MontaVista ) building for x86. Odd that static linking works. You can extract the object files from libY.a to determine which one has Z undefined. As you have the source to libY, you can find out why the symbol is undefined. -Original Message- From: Albert Chin [mailto:[EMAIL PROTECTED] Sent: Wednesday, October 12, 2005 1:25 PM To: Nitesh Soni (NC/TNT) Cc: libtool@gnu.org Subject: Re: problem linking with shared library On Wed, Oct 12, 2005 at 11:22:42AM -0500, Nitesh Soni (NC/TNT) wrote: I am trying to build an executable X which links with libY. I am using libtool to build this library libY; so I have a static version libY.a and libY.so When I link the static version libY.a, i am able to build the application X But when I link against the shared version libY.so I am not able to build the application; it fails with some undefined reference to (lets say) Z Now I did nm libY.a and nm libY.so Both these versions have symbol Z as U Is symbol Z defined in executable X? What specific error is the linker giving? What platform? -- albert chin ([EMAIL PROTECTED]) -- albert chin ([EMAIL PROTECTED]) ___ http://lists.gnu.org/mailman/listinfo/libtool -- albert chin ([EMAIL PROTECTED]) ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: [rfc] keep LD_LIBRARY_PATH from tromping on libtool wrapped files
On Wed, Sep 14, 2005 at 11:50:05PM -0400, Mike Frysinger wrote: On Wednesday 14 September 2005 11:36 pm, Albert Chin wrote: If gcc/ld was used to build the new 'file' program, they would have the same error as that generated by libtool. Shouldn't libtool then try to mimic this behavior, not correct it? not sure what you mean by this. the wrapped 'file' program (src/file) is a libtool script whose purpose is to make sure that you can execute the wrapped program until all dependent libraries are installed into the normal library search path. since libtool already goes to lengths to make sure that the wrapped program finds and uses the local build libraries (src/.libs/), why not this one more sanity check ? If the new 'file' program was installed, the user would have the same problem. The wrapper script should simply run the program as if it was installed. -- albert chin ([EMAIL PROTECTED]) ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: [rfc] keep LD_LIBRARY_PATH from tromping on libtool wrapped files
On Wed, Sep 14, 2005 at 08:32:12PM -0400, Mike Frysinger wrote: normally this is no problem for libtool ... it installs a wrapper in src/file which runs src/.libs/lt-file which is compiled with RUNPATH tags so that the libmagic.so.1 in src/.libs/ is used. the trouble is when the user has LD_LIBRARY_PATH set such that it points to the older libmagic.so.1. if the system library loader searches LD_LIBRARY_PATH before RUNPATH elf tags, the older libmagic.so.1 will be loaded instead of the one which has the newer functionality. the new file tries to use that functionality and the whole process fails. for example, the dynamic loader from glibc respects LD_LIBRARY_PATH before elf RUNPATH tags. ive attached a patch against libtool-1.5.20 which checks to see if LD_LIBRARY_PATH is set, and if it is, will add the .libs dir to the head of the searchpath. i have a passing familiarity with libtool internals so i doubt this patch is perfect, but i'd like feedback/comments/etc... from people who know more than i ;) This seems to be a workaround for a user-generated problem. If gcc/ld was used to build the new 'file' program, they would have the same error as that generated by libtool. Shouldn't libtool then try to mimic this behavior, not correct it? Setting LD_LIBRARY_PATH to one of the default search paths is just wrong anyway. -- albert chin ([EMAIL PROTECTED]) ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Use of compiler_lib_search_path when cross-compiling
On Tue, Sep 06, 2005 at 04:22:03PM -0700, Marc Singer wrote: [ snip snip ] So, the question is this. Do I need to build a special version of libtool for cross compiling which is separate from the version used to build native packages? Yes. However, libtool is usually part of the native package build process so it gets customized to whatever flags used during the build. It's generally a bad idea to use the installed libtool unless you're using the same flags used to build the installed libtool. You could also LDFLAGS=-L[path you your cross-compiled libs] and libtool should look in LDFLAGS first. -- albert chin ([EMAIL PROTECTED]) ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Use of compiler_lib_search_path when cross-compiling
On Tue, Sep 06, 2005 at 07:06:13PM -0700, Marc Singer wrote: On Tue, Sep 06, 2005 at 08:57:24PM -0500, Albert Chin wrote: On Tue, Sep 06, 2005 at 04:22:03PM -0700, Marc Singer wrote: [ snip snip ] So, the question is this. Do I need to build a special version of libtool for cross compiling which is separate from the version used to build native packages? Yes. However, libtool is usually part of the native package build process so it gets customized to whatever flags used during the build. It's generally a bad idea to use the installed libtool unless you're using the same flags used to build the installed libtool. No. I'm not using the installed libtool. I'm building it as part of the cross-development environment. Now, I know that I have to build two version: one for native packages and one for cross-compiled packages. If CC=[cross-compile gcc], then shouldn't $CC -print-search-dirs set $compiler_lib_search_path correctly? -- albert chin ([EMAIL PROTECTED]) ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: how to link with installed libltdl?
On Thu, Sep 01, 2005 at 08:28:24PM +0200, Andreas Jellinghaus wrote: On Thursday 01 September 2005 16:52, Bob Friesenhahn wrote: So it seems that a libtool-provided macro should be used in configure.ac to test for an installed libltdl. Testing for it in a simple way could well indeed result in false negatives due to libltdl depending on some other library (e.g. -ldl). It is not necessary for a package to include its own copy of libtool in order to make use of it. Libtool may already be installed in a standard location. I may be missing something, but all the libltdl-related macros I see are for the case of when libltdl is bundled with the package. I don't see one for simply testing for an already installed libltdl. thanks bob, that is exactly the problem I'm facing. now I wonder: if the libtool *.la files contain all information about the dependencies etc, then shouldn't there be some macro that searches for that *.la files, gets the dependencies from it, does the compile and link test and sets up CFLAGS and LIBS to include whatever is necessary? is there something that works like AC_CHECK_LIB, except that AC_CHECK_LIB seems to have no clue about *.la files, so is there some alternative that does? Why don't we install a pkg-config .pc file for ltdl? That would solve your problem easily. -- albert chin ([EMAIL PROTECTED]) ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: libtool 1.5 -static and installed libraries
On Mon, Aug 29, 2005 at 03:34:17AM -0700, Howard Chu wrote: Ralf Wildenhues wrote: Should we discuss this and decide about what's best? Maybe we'd need another switch to link statically against all non-system libs (in the sense that libc is one, but libdb is not)? Or would implementing per- deplib static/shared switches be the only solution? That may work best, though it sounds tedious. A lot of linkers allow -static/-dynamic to be specified multiple times on a command line, toggling the choice until the next switch occurs in the options. Yeah, I think this is really the only sane way. Multiple static flags is too hard. Unfortunately, -static and -all-static are taken. From ld(1) on Redhat: -Bstatic -dn -non_shared -static Do not link against shared libraries. This is only meaningful on platforms for which shared libraries are supported. The different variants of this option are for compatibility with various systems. You may use this option multiple times on the command line: it affects library searching for -l options which follow it. -- albert chin ([EMAIL PROTECTED]) ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: CVS branch-2-0 R.I.P.
On Fri, Aug 26, 2005 at 04:26:57PM +0200, Ralf Wildenhues wrote: * Peter Ekberg wrote on Fri, Aug 26, 2005 at 04:06:05PM CEST: What is the requirements on the autotools for a libtoolized package from HEAD? I heard a rumor that cvs versions were required, at least at some point, is that really the case or was it just a rumor? At the moment they are required after a cvs checkout of Libtool HEAD for building itself. When will HEAD be able to bootstrap with the latest released autoconf/automake? -- albert chin ([EMAIL PROTECTED]) ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Libtool: Microsoft dumpbin as name lister
On Mon, Aug 22, 2005 at 03:39:19PM +0200, Tim Van Holder wrote: FYI, the dumpbin.exe provided by Visual C++ is really just a stub that calls link.exe (rather like symlinking unzip as zipinfo). Running link /dump has the same effect as running dumpbin; so perhaps checking for MS Link is enough - if you have identified the MS linker, you can use it to list symbols (and I imagine libtool may need to know about the linker anyway). If dumpbin is an alias for link with some args, how about scrapping use of dumpbin and replacing with the appropriate link command-line? -- albert chin ([EMAIL PROTECTED])
Re: Libtool: Microsoft dumpbin as name lister
On Tue, Aug 23, 2005 at 09:53:58AM +0200, Peter Ekberg wrote:
Albert Chin wrote:
Running link /dump has the same effect as running dumpbin; so
perhaps checking for MS Link is enough - if you have identified
the MS linker, you can use it to list symbols (and I imagine
libtool may need to know about the linker anyway).
If dumpbin is an alias for link with some args, how about scrapping
use of dumpbin and replacing with the appropriate link command-line?
As the same is true for lib == link -lib I have had the same
thought. The problem is that link is most likely shadowed on the
PATH on Cygwin. So, some care has to be taken to avoid the use
of the wrong link program.
So, if link appears in multiple places in $PATH, we just need to
pick the correct one? Libtool does something similar for grep and
sed (i.e. pick the best one in $PATH that supports the longest
command-line).
I dreamed up something like this:
1. Check if $CC is cl with a test compile to see if $CC
defines _MSC_VER, if not bail.
2. If (first word of) $CC contains / or \, replace last
path component (should be cl or cl.exe) with link.
3. If (first word of) $CC does not contain / or \, use
which(1) (or, if which should not be used for some reason,
search the path manually) to locate the full path of
$CC and replace last path component with link.
You now have good input for $LD.
: ${NM=$LD -dump -symbols}
: ${AR=$LD -lib}
Any faults in the above? Comments?
Ick. Why not just test all available link programs in $PATH for the
features we want and pick the winner?
--
albert chin ([EMAIL PROTECTED])
Re: branch-2-0 vs CVS HEAD
On Tue, Aug 23, 2005 at 08:11:48AM +0200, Ralf Wildenhues wrote: * Albert Chin wrote on Tue, Aug 23, 2005 at 04:41:58AM CEST: On Mon, Aug 22, 2005 at 07:54:59PM +0100, Gary V. Vaughan wrote: Ralf Wildenhues wrote on libtool-patches: I kept quiet a while ago when Bob first suggested ditching the CVS branch-2-0 and releasing CVS HEAD as 2.0 after a bit of stabilization. The showstopper for this plan is that libtool is holding up the next release of all the other autotools[1], so we can't release HEAD as is without causing headaches for everyone else, because it relies on unreleased versions of the tools that are waiting for another libtool release. libtool-2.0 should not rely on newer autoconf/automake. People simply won't adopt it. RHEL 4 ships with autoconf-2.59 and automake-1.9.2. I'm not against requiring the latest, as of now, autoconf/automake, but relying on autoconf-2.60 and automake-1.10 seems way too aggressive. ... So my point is: get HEAD stable now, then branch off and make 2.59/1.9.6 compatible there. Then bootstrap the release with the couple of naughty system-dependent fixes we know of in those autotools versions. Seems fine to me. -- albert chin ([EMAIL PROTECTED]) ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Libtool API suggestion: LTDL_SHLIB_PRE and/or char* ltdl_map_shared_name(const char* name)
On Tue, Aug 23, 2005 at 08:20:42PM +0200, Dalibor Topic wrote:
It would be nice if libtool provided a way to either map a short dynamic
library name to a full name (say, something - libsomething.so) or
offered an autoconfish way to get the platform-specifc shared library
prefix, like it does for the suffix.
I've seen that a similar problem occured for GNU readline on cygwin[1],
and they went for a platform-specific set of properties in the
makefiles. I guess it would be more efficient if libtool provided a
central API for that, rather than to see projects reinventing the wheel.
It also seems that ltdl.c uses the lib prefix specifically in one case
[2] , where it may or may not make sense to use a hypothetical
LTDL_SHLIB_PRE.
so:
if x$need_lib_prefix = xno; then
LTDL_SHLIB_PRE=
else
LTDL_SHLIB_PRE=lib
fi
[2] ltdl.c from HEAD:
812 if (strncmp(p, -l, 2) == 0)
813 {
814 size_t name_len = 3+ /* lib */ LT_STRLEN (p
+ 2);
815 name = MALLOC (char, 1+ name_len);
816 if (name)
817 sprintf (name, lib%s, p+2);
818 }
From inspection, this appears wrong. It doesn't honor
$need_lib_prefix. Should we have a separate prefix variable like
$shrext_cmds so we don't have to do things like:
case $host_os in
cygwin*)
# Cygwin DLLs use 'cyg' prefix rather than 'lib'
soname_spec='`echo ${libname} | sed -e 's/^lib/cyg/'``echo ${release} |
$SED -e 's/[[.]]/-/g'`${versuffix}${shared_ext}'
;;
--
albert chin ([EMAIL PROTECTED])
___
http://lists.gnu.org/mailman/listinfo/libtool
Re: Call for help: Solaris C++ and Sun CC
On Sun, Aug 21, 2005 at 03:46:13PM +0200, Ralf Wildenhues wrote: So I looked around. I've found this documentation http://docs-pdf.sun.com/806-7982/806-7982.pdf (page 21): | The Sun WorkShop 6 update 2 C++ compiler (5.3) includes a shared | version of the libCstd library. | To use the shared version of libCstd, do the following: | 1. As superuser, manually create the following symbolic links. | | example% ln -s /usr/lib/libCstd.so.1 \ | /opt/SUNWSpro/lib/libCstd.so | example% ln -s /usr/lib/libCstd.so.1 \ | /opt/SUNWSpro/lib/v8plus/libCstd.so | example% ln -s /usr/lib/sparcv9/libCstd.so.1 \ | /opt/SUNWSpro/lib/v9/libCstd.so We have this compiler on a Solaris 2.6 system and none of /opt/SUNWSpro/lib/libCstd.so, /opt/SUNWSpro/lib/v8plus/libCstd.so, and /opt/SUNWSpro/lib/v9/libCstd.so exist. There is no libCstd.so anywhere in /opt/SUNWspro/lib. Other bits of useful info: http://forum.sun.com/thread.jspa?threadID=25908 I'd like any feedback about possible solutions, general ideas about the issue, or just how *your* Sun CC is set up (with or without these links etc.). Unfortunately, we don't have CC v5.4 to test against. However, everything about 5.5 works with the patch. I say we gamble and ignore everything below CC v5.4 for this patch. -- albert chin ([EMAIL PROTECTED]) ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Cope with weird AIX chmod behavior
On Sun, Aug 21, 2005 at 04:21:08PM +0200, Ralf Wildenhues wrote: This, on an AIX 5.1 below some /tmp-like directory: $ ls -ld .. . drwx--S--- 15 username sys1024 Aug 21 09:01 .. drwx--S--- 2 username sys 512 Aug 21 09:07 . $ chmod u+w . 0481-014 chmod: not all requested changes were made to . $ chmod u-w . $ ls -la dr-x-- 2 username sys 512 Aug 21 09:07 . Works fine on our AIX 5.1 system with v5.1.0.35 of bos.rte.commands (package containing /usr/bin/chmod). leads to this in configure output: | checking if xlf supports -c -o file.o... chmod: not all requested changes were made to . | yes OK to apply this cleanup (all branches)? Does it hurt when we just kill the g+s (then we would be in more trouble, as there are other places which do this, too)? Should be ok. Considering our chmod works, it means IBM fixed a bug in it. So, if it's decided that g+s is bad, we could ask the user to upgrade. -- albert chin ([EMAIL PROTECTED])
Re: function-local variables in ltmain
On Tue, Aug 16, 2005 at 12:29:13PM +0100, Gary V. Vaughan wrote: Ralf Wildenhues wrote: * Albert Chin wrote on Sat, Aug 13, 2005 at 09:56:43PM CEST: On Sat, Aug 13, 2005 at 10:40:01AM +0200, Ralf Wildenhues wrote: 2) This looks somewhat ugly in the output, but to a certain extent, it is possible to emulate local variables with m4sh: see below. Way ugly. Yep. That doesn't matter. The output of gcc is ugly too! We should be maintaining the source files (.m4sh), and anything that makes them easier to read and edit is a good thing. Just seems to make libtool harder to maintain. Au contraire. Once any such mechanism has been debugged, it makes libtool easier to maintain... as has been the case with several of the refactorings I've done as we progress towards 2.0. But debugging libtool occurs with the _generated_ libtool script. Making the output sane should help debugging, not hinder it. Is this so much of a problem that we need such a big hammer to solve it? I don't recall seeing enough PRs to consider it. -- albert chin ([EMAIL PROTECTED])
Re: function-local variables in ltmain
On Sat, Aug 13, 2005 at 10:40:01AM +0200, Ralf Wildenhues wrote: Gary once mentioned a plan to emulate local variables in m4sh. (Or was it return values? I can't find it now). I have two ideas: 1) Since we do assume the shell has functions, can we maybe also assume the shell has /some/ way of declaring local variables? If so, the CONFIG_COMMANDS to generate `libtool' could put it in: local or typeset Issue may arise if different semantics are employed by different shells, e.g.: are local visible to functions called, how or whether to access the global shadowing the local. Implicitly, branch-2-0 and HEAD already assume that the positional parameters are function-local and restored after returning. 2) This looks somewhat ugly in the output, but to a certain extent, it is possible to emulate local variables with m4sh: see below. Way ugly. Just seems to make libtool harder to maintain. What's the point anyway? To keep function-specific variables from being clobbered? Was this so much of a problem before libtool had functions and everything was global? Seems like a solution looking for a problem. -- albert chin ([EMAIL PROTECTED])
Re: : libtool-1.9f: Added option quiet - only errors and warnings go through, now
On Sat, Aug 06, 2005 at 08:31:31AM +0200, Ralf Wildenhues wrote: Hi Juergen, Juergen Leising writes: On Tue, Aug 02, 2005 at 05:29:54PM +0200, Ralf Wildenhues wrote: OTOH, there is a different, and IMHO orthogonal component: even with --silent, libtool outputs a little bit of information (which I believe your patch works on as well). The question is: Should we add another option to be completely silent, or maybe just make --silent be completely silent? What do you/the others think? ..., exactly, this is what my patch was meant to be about: Complete silence. It's really useful when you try and find errors in third party software you are not too much familiar with. I would probably be inclined to accept a patch enforcing complete silence. Nobody has stepped up to argue whether or not a new switch should be necessary for this, I am pretty indifferent to this myself. Rather than another switch, how about if --silent is given more than one, libtool becomes really silent. Kinda like --verbose being given more than once for some programs being more verbose. -- albert chin ([EMAIL PROTECTED])
