Re: libtool.texi: copyright notice patch
Hello Christophe, * Christophe Jarry wrote on Sun, Sep 04, 2011 at 12:07:23PM CEST: I found that the copyright notice of the file doc/libtool.texi does not follow Information for Maintainers of GNU Software at http://www.gnu.org/prep/maintain/html_node/Copyright-Notices.html#Copyright-Notices. This documents states: Don’t delete old year numbers, though; they are significant since they indicate when older versions might theoretically go into the public domain, if the movie companies don’t continue buying laws to further extend copyright. If you copy a file into the package from some other program, keep the copyright years that come with the file. You can use a range (‘2008-2010’) instead of listing individual years (‘2008, 2009, 2010’) if and only if: 1) every year in the range, inclusive, really is a “copyrightable” year that would be listed individually; and 2) you make an explicit statement in a ‘README’ file about this usage. I have seen no such explici statement in the file README so I send you the patch for doc/libtool.texi. I'm sure you would agree that an explicit statement would be more maintainable though, no? Thanks, Ralf -Copyright (C) 1996-2011 Free Software Foundation, Inc. +Copyright (C) 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005, 2006, +2007, 2008, 2009, 2010, 2011 Free Software Foundation, Inc. [...]
Re: Bug 9210: fix to replace Linux with GNU/Linux where needed
Hello Christophe, * Christophe Jarry wrote on Sun, Sep 04, 2011 at 12:55:37PM CEST: --- libtool.orig/libltdl/config/ltmain.m4sh 2011-08-31 21:50:53.0 +0200 +++ libtool.new/libltdl/config/ltmain.m4sh2011-09-04 12:27:53.0 +0200 Please learn to use git for sending patches; thanks! @@ -6605,7 +6605,7 @@ none) ;; darwin) - # Like Linux, but with the current version available in + # Like GNU/Linux, but with the current version available in This should be Like linux, because it speaks about version_type names. # verstring for coding it into the library header func_arith $current - $age major=.$func_arith_result --- libtool.orig/libltdl/m4/libtool.m42011-08-31 21:50:53.0 +0200 +++ libtool.new/libltdl/m4/libtool.m4 2011-09-04 12:27:36.0 +0200 @@ -2633,12 +2633,12 @@ hardcode_into_libs=yes ;; -# No shared lib support for Linux oldld, aout, or coff. +# No shared lib support for GNU/Linux oldld, aout, or coff. Ugh. What is oldld? Is it Linux or GNU specific (or both)? Because the urge to call something GNU/Linux is definitely only valid for things that are, in fact, not just one of the two. linux*oldld* | linux*aout* | linux*coff*) dynamic_linker=no ;; -# This must be Linux ELF. +# This must be GNU/Linux ELF. The comment does not match the code below it, see the following line. Not your fault, and generally I don't want to take patches hostage on unrelated bugs, but *please* make this # This must be GNU userland with ELF and linux* | k*bsd*-gnu | kopensolaris*-gnu) version_type=linux need_lib_prefix=no @@ -3284,7 +3284,7 @@ lt_cv_deplibs_check_method=pass_all ;; -# This must be Linux ELF. +# This must be GNU/Linux ELF. Ditto. linux* | k*bsd*-gnu | kopensolaris*-gnu) lt_cv_deplibs_check_method=pass_all ;; @@ -4066,7 +4066,7 @@ cxx*) # Compaq C++ # Make sure the PIC flag is empty. It appears that all Alpha - # Linux and Compaq Tru64 Unix objects are PIC. + # GNU/Linux and Compaq Tru64 Unix objects are PIC. An object compiled with Compaq C++ bears no connection a priori with GNU. I think the statement before is wrong on more grounds, but I'm too lazy to dig history now; please just leave it as it is. Thanks. _LT_TAGVAR(lt_prog_compiler_pic, $1)= _LT_TAGVAR(lt_prog_compiler_static, $1)='-non_shared' ;; @@ -4121,7 +4121,7 @@ # Digital/Compaq C++ _LT_TAGVAR(lt_prog_compiler_wl, $1)='-Wl,' # Make sure the PIC flag is empty. It appears that all Alpha - # Linux and Compaq Tru64 Unix objects are PIC. + # GNU/Linux and Compaq Tru64 Unix objects are PIC. Ditto. _LT_TAGVAR(lt_prog_compiler_pic, $1)= _LT_TAGVAR(lt_prog_compiler_static, $1)='-non_shared' ;; Thanks, Ralf
Re: [PATCH] Correctly concat commands when export_symbols_cmds starts with some 'word'.
Hi Michael,
* Michael Haubenwallner wrote on Mon, Jun 27, 2011 at 04:28:38PM CEST:
Concatening commands breaks when export_symbols_cmds starts with something
like dump, which does not need another shell expansion step. Instead, it
is merged with \$concat_cmds to $concat_cmdsdump for within the eval.
While this isn't a problem right now, it hits me when experimenting with
shared library versioning support for AIX.
How can that be?
+ Correctly concat commands when export_symbols_cmds starts with 'word'.
+ * libltdl/config/ltmain.m4sh: When export_symbols_cmd starts with some
+ 'word', 'word' is joined with 'concat_cmds' to 'concat_cmdsword' due to
+ different expansion time: Need to embrace concat_cmds variable for
+ export_symbols_cmds too as for reload_cmds and old_archive_cmds.
When $concat_cmds is nonempty, it gets a '~' at the end. That can never
be part of a shell word, if I see correctly. Can you give an example?
--- a/libltdl/config/ltmain.m4sh
+++ b/libltdl/config/ltmain.m4sh
@@ -7636,7 +7636,7 @@ EOF
libobjs=$output
# Append the command to create the export file.
test -z $concat_cmds || concat_cmds=$concat_cmds~
- eval concat_cmds=\\$concat_cmds$export_symbols_cmds\
+ eval concat_cmds=\\${concat_cmds}$export_symbols_cmds\
if test -n $last_robj; then
eval concat_cmds=\\$concat_cmds~\$RM $last_robj\
fi
Thanks,
Ralf
Re: libtool mingw cross compile problems
* Ralf Wildenhues wrote on Wed, May 18, 2011 at 09:13:32PM CEST: * Erik de Castro Lopo wrote on Tue, May 17, 2011 at 12:21:35PM CEST: The problem is the generation of a test program in a sub-directory. The test program that should be generated is: G72x/g72x_test.$(EXEEXT) which executes a a wrapper script in G72x/.libs/ . Unfortunately for Linux - windows cross compiles, the G72x/g72x_test.$(EXEEXT) executable isn't being generated. There is however a bash script G72x/.libs/g72x_test_ltshwrapper. Please provide more details. For example a small Makefile.am snippet that reproduces the problem for you. Aw darn, now that I sent this mail I see you already sent this to the automake list. Please don't send to two lists without at least hinting that you've already sent things elsewhere, or better a URL or Xpost with Followup. In this case I would like to see the output of make clean make; make g72x_test Thanks, Ralf ___ https://lists.gnu.org/mailman/listinfo/libtool
Re: [PATCH 01/10] Add -shortname option.
Hello, * Eric Blake wrote on Fri, Apr 15, 2011 at 03:46:33PM CEST: On 04/15/2011 06:59 AM, KO Myung-Hun wrote: OS/2 limits a length of a DLL base name up to 8 characters. If a name of a shared library is longer than 8 characters, OS/2 cannot load it. So the option to specify a short name is needed. --- a/NEWS +++ b/NEWS @@ -7,6 +7,7 @@ New in 2.4.2 2011-??-??: git version 2.4.1a, Libtool team: - The --with-pic configure option now supports a list of comma-separated package names. This can be used to build some static libraries with PIC objects while building others with non-PIC objects. + - Added -shortname option to specify a short name for a DLL (OS/2 only) Long options should start with --, not -, per GNU coding conventions (gcc is an exception, but libtool should not be). libtool traditionally has been an exception too, however. I'm not sure it's worthwhile moving from that at this point. Other than that, sorry about my lack of review; now that the copyright issue has been pending-cleared I should put it higher up in my todo list ... Thanks, Ralf
Re: QNX6 patch
Hello Sean,
* Sean Boudreau wrote on Mon, Apr 11, 2011 at 05:32:25PM CEST:
Here's a patch for qnx that I've been using for a while.
I'd like to try to get it integrated.
Thank you for the patch. Unfortunately, we cannot take it as it is,
because there are several bits of information missing, and some things
look problematic.
First off, the patch needs a GNU-style ChangeLog entry (see the
ChangeLog file for existing entries). We can write it if you have
problems with it, but you should at least try. Did you write the
patch? Were others also involved?
Then, we'd like to see how both the old and the new Libtool testsuites
fare with this patch on QNX6 (and maybe older releases if relevant?),
and whether the patch fixes any test failures that were present
previously (and it would be good to see verbose test logs for those as
well).
More comments inline.
--- libtool-2.4~/libltdl/m4/libtool.m42010-09-22 04:41:19.0
-0400
+++ libtool-2.4/libltdl/m4/libtool.m4 2011-04-11 11:13:24.0 -0400
@@ -2651,9 +2651,10 @@
;;
*nto* | *qnx*)
- version_type=qnx
+ version_type=linux
Whoa, this is a very heavy change. This has the chance to break
virtually all existing QNX setups, turn installed libraries that have
been built without this change incompatible to libraries that use the
change.
Such a change needs a very good rationale, usually including a pointer
to system documentation for why the old version semantics are not
adequate (any more?), for why maybe a newer system release changed
semantics, or some other reason. If we do this change for a new system
version, that can be acceptable, but then older versions should not be
affected.
That said, I have no idea how large the user base for Libtool and
Libtool-using packages on QNX is. You might be the only person building
packages there, I cannot tell. Please share such information, as much
as you have it.
Jasons remark about this being different from the QNX style makes me
doubt the validity of this change even more. libtool should be
emulating the native shared library semantics as much as possible in
order to fit in.
need_lib_prefix=no
need_version=no
+ sys_lib_search_path_spec=/lib /usr/lib
This looks benign.
library_names_spec='${libname}${release}${shared_ext}$versuffix
${libname}${release}${shared_ext}$major $libname${shared_ext}'
soname_spec='${libname}${release}${shared_ext}$major'
shlibpath_var=LD_LIBRARY_PATH
@@ -3245,7 +3246,7 @@
;;
*nto* | *qnx*)
- lt_cv_deplibs_check_method=pass_all
+ 'match_pattern /lib[[^/]]+(\.so|S\.a)$'
This looks like a typo. The resulting shell code is erroneous
(tries to execute a program named match_pattern /
You meant to assign the contents of the added line to the variable
named in the removed line.
;;
openbsd*)
@@ -5289,6 +5290,8 @@
;;
*nto* | *qnx*)
+ _LT_TAGVAR(archive_cmds, $1)='$CC -shared $libobjs $deplibs
$compiler_flags ${wl}-soname $wl$soname -o $lib'
+ _LT_TAGVAR(archive_expsym_cmds, $1)='$CC -shared $libobjs $deplibs
$compiler_flags ${wl}-soname $wl$soname ${wl}-retain-symbols-file
$wl$export_symbols -o $lib'
Please check whether adding $pic_flag to both added commands lets them
still work.
;;
openbsd*)
@@ -6495,7 +6498,12 @@
;;
*nto* | *qnx*)
-_LT_TAGVAR(ld_shlibs, $1)=yes
+_LT_TAGVAR(archive_cmds, $1)='$CC -shared $libobjs $deplibs
$compiler_flags ${wl}-soname $wl$soname -o $lib'
+_LT_TAGVAR(archive_expsym_cmds, $1)='$CC -shared $libobjs $deplibs
$compiler_flags ${wl}-soname $wl$soname ${wl}-retain-symbols-file
$wl$export_symbols -o $lib'
Likewise.
+_LT_TAGVAR(hardcode_libdir_flag_spec, $1)='-R$libdir'
+_LT_TAGVAR(hardcode_direct, $1)=yes
+_LT_TAGVAR(hardcode_shlibpath_var, $1)=no
+output_verbose_link_cmd='echo'
These additions look OK to me.
;;
openbsd2*)
Thanks again,
Ralf
___
http://lists.gnu.org/mailman/listinfo/libtool
[SCM] GNU Libtool branch, master, updated. v2.4-52-g1ea9302
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project GNU Libtool.
The branch, master has been updated
via 1ea9302bd1eadf25b466fcd7e8697e4bef111493 (commit)
from 1b76054f4763a28ae1b01fbeee86ba0c524d1923 (commit)
Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.
- Log -
commit 1ea9302bd1eadf25b466fcd7e8697e4bef111493
Author: Svante Signell s...@kth.se
Date: Sun Apr 10 10:17:21 2011 +0200
Set shlibpath_overrides_runpath for the Hurd.
* libltdl/m4/libtool.m4 (_LT_SYS_DYNAMIC_LINKER) [gnu]
shlibpath_overrides_runpath: Set to no.
* THANKS: Update.
Signed-off-by: Ralf Wildenhues ralf.wildenh...@gmx.de
---
Summary of changes:
ChangeLog |7 +++
THANKS|4 +++-
libltdl/m4/libtool.m4 |1 +
3 files changed, 11 insertions(+), 1 deletions(-)
diff --git a/ChangeLog b/ChangeLog
index bc7c2af..ff936ae 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,10 @@
+2011-04-10 Svante Signell s...@kth.se (tiny change)
+
+ Set shlibpath_overrides_runpath for the Hurd.
+ * libltdl/m4/libtool.m4 (_LT_SYS_DYNAMIC_LINKER) [gnu]
+ shlibpath_overrides_runpath: Set to no.
+ * THANKS: Update.
+
2011-03-22 Justin Lecher j...@gentoo.org (tiny change)
Rhys Ulerich rhys.uler...@gmail.com (tiny change)
diff --git a/THANKS b/THANKS
index 08d7077..da43e65 100644
--- a/THANKS
+++ b/THANKS
@@ -180,6 +180,7 @@
Stephan Kulowco...@kde.org
Steve Ellcey s...@cup.hp.com
Steven M. Schultzs...@wlv.iipo.gtegsc.com
+ Svante Signell s...@kth.se
Sven Verdoolaege sk...@liacs.nl
Terry D. Dontje terry.don...@sun.com
Tim Mooney moo...@dogbert.cc.ndsu.nodak.edu
@@ -202,7 +203,8 @@
--
Copyright (C) 1996, 1998, 1999, 2001, 2002, 2003, 2004, 2005, 2006,
-2007, 2008 Free Software Foundation, Inc.
+2007, 2008, 2009, 2010, 2011 Free Software Foundation,
+Inc.
Written by Gord Matzigkeit, 1996
This file is part of GNU Libtool.
diff --git a/libltdl/m4/libtool.m4 b/libltdl/m4/libtool.m4
index 5cc027b..2ed41b7 100644
--- a/libltdl/m4/libtool.m4
+++ b/libltdl/m4/libtool.m4
@@ -2519,6 +2519,7 @@ gnu*)
library_names_spec='${libname}${release}${shared_ext}$versuffix
${libname}${release}${shared_ext}${major} ${libname}${shared_ext}'
soname_spec='${libname}${release}${shared_ext}$major'
shlibpath_var=LD_LIBRARY_PATH
+ shlibpath_overrides_runpath=no
hardcode_into_libs=yes
;;
hooks/post-receive
--
GNU Libtool
[SCM] GNU Libtool branch, master, updated. v2.4-53-gd5d35c4
This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project GNU Libtool. The branch, master has been updated via d5d35c47e16b18158bf4984cc4371366d373bb2f (commit) from 1ea9302bd1eadf25b466fcd7e8697e4bef111493 (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log - commit d5d35c47e16b18158bf4984cc4371366d373bb2f Author: Kurt Roeckx k...@roeckx.be Date: Sun Apr 10 10:22:43 2011 +0200 tagdemo: do not rely on picking up symbols from indirect deps. * tests/tagdemo/Makefile.am: Link to all libraries that the demo application uses. Signed-off-by: Ralf Wildenhues ralf.wildenh...@gmx.de --- Summary of changes: ChangeLog |6 ++ tests/tagdemo/Makefile.am |4 ++-- 2 files changed, 8 insertions(+), 2 deletions(-) diff --git a/ChangeLog b/ChangeLog index ff936ae..dcfab26 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,3 +1,9 @@ +2011-04-10 Kurt Roeckx k...@roeckx.be + + tagdemo: do not rely on picking up symbols from indirect deps. + * tests/tagdemo/Makefile.am: Link to all libraries that the + demo application uses. + 2011-04-10 Svante Signell s...@kth.se (tiny change) Set shlibpath_overrides_runpath for the Hurd. diff --git a/tests/tagdemo/Makefile.am b/tests/tagdemo/Makefile.am index e945c25..295e7b6 100644 --- a/tests/tagdemo/Makefile.am +++ b/tests/tagdemo/Makefile.am @@ -1,6 +1,6 @@ ## Makefile.am -- Process this file with automake to produce Makefile.in ## -## Copyright (C) 2003, 2004, 2005 Free Software Foundation +## Copyright (C) 2003, 2004, 2005, 2011 Free Software Foundation ## Written by Gary V. Vaughan, 2003 ## ## This file is part of GNU Libtool. @@ -47,7 +47,7 @@ noinst_HEADERS = foo.h baz.h conv.h bin_PROGRAMS = tagdemo tagdemo_SOURCES = main.cpp -tagdemo_LDADD = libbaz.la +tagdemo_LDADD = libbaz.la libfoo.la libtool: $(LIBTOOL_DEPS) $(SHELL) ./config.status --recheck hooks/post-receive -- GNU Libtool
Re: Updated patches: Re: bug#8441: Patches making libtool-2.4-1 build under GNU/Hurd
* Svante Signell wrote on Fri, Apr 08, 2011 at 09:01:56AM CEST:
# shlibpath_overrides_runpath is set to 'unknown' in libtool.m4
# and not defined under $host_os =gnu
# This patch make the tests/*demo* run.
--- libtool-2.4/libltdt/m4/libtool.m4.orig2011-02-03 21:33:56.0
+0100
+++ libtool-2.4/libltdl/m4/libtool.m4 2011-02-03 21:43:46.0 +0100
@@ -2325,6 +2325,7 @@
library_names_spec='${libname}${release}${shared_ext}$versuffix
${libname}${release}${shared_ext}${major} ${libname}${shared_ext}'
soname_spec='${libname}${release}${shared_ext}$major'
shlibpath_var=LD_LIBRARY_PATH
+ shlibpath_overrides_runpath=no
hardcode_into_libs=yes
;;
Thank you. This should let the low-cmdline test pass as well, so it
need not be disabled any more (except for non coffee drinking purposes
at least ;-)
I'm pushing the patch below in your name and adding you to THANKS.
The '(tiny change)' annotation is just to denote that you haven't
exchanged copyright papers with the FSF yet.
Cheers,
Ralf
2011-04-10 Svante Signell ... (tiny change)
Set shlibpath_overrides_runpath for the Hurd.
* libltdl/m4/libtool.m4 (_LT_SYS_DYNAMIC_LINKER) [gnu]
shlibpath_overrides_runpath: Set to no.
* THANKS: Update.
diff --git a/libltdl/m4/libtool.m4 b/libltdl/m4/libtool.m4
index 5cc027b..2ed41b7 100644
--- a/libltdl/m4/libtool.m4
+++ b/libltdl/m4/libtool.m4
@@ -2519,6 +2519,7 @@ gnu*)
library_names_spec='${libname}${release}${shared_ext}$versuffix
${libname}${release}${shared_ext}${major} ${libname}${shared_ext}'
soname_spec='${libname}${release}${shared_ext}$major'
shlibpath_var=LD_LIBRARY_PATH
+ shlibpath_overrides_runpath=no
hardcode_into_libs=yes
;;
Re: [PATCH] tagdemo: Link to libfoo
Hi Kurt, * Kurt Roeckx wrote on Sat, Apr 02, 2011 at 09:06:05PM CEST: * tests/tagdemo/Makefile.am: Link to all libraries that the demo application uses. Thanks, I'm pushing that patch in your name. Cheers, Ralf 2011-04-10 Kurt Roeckx ... tagdemo: do not rely on picking up symbols from indirect deps. * tests/tagdemo/Makefile.am: Link to all libraries that the demo application uses. diff --git a/tests/tagdemo/Makefile.am b/tests/tagdemo/Makefile.am index e945c25..295e7b6 100644 --- a/tests/tagdemo/Makefile.am +++ b/tests/tagdemo/Makefile.am @@ -1,6 +1,6 @@ ## Makefile.am -- Process this file with automake to produce Makefile.in ## -## Copyright (C) 2003, 2004, 2005 Free Software Foundation +## Copyright (C) 2003, 2004, 2005, 2011 Free Software Foundation ## Written by Gary V. Vaughan, 2003 ## ## This file is part of GNU Libtool. @@ -47,7 +47,7 @@ noinst_HEADERS = foo.h baz.h conv.h bin_PROGRAMS = tagdemo tagdemo_SOURCES = main.cpp -tagdemo_LDADD = libbaz.la +tagdemo_LDADD = libbaz.la libfoo.la libtool: $(LIBTOOL_DEPS) $(SHELL) ./config.status --recheck
Re: Example in libtool manual gives wrong dependencies w/ automake.
Hello Nick, * Nick Bowler wrote on Fri, Apr 01, 2011 at 04:04:21PM CEST: I'm working on a project which uses libltdl to load modules, and I've set it up in a manner pretty similar to what's described in the libtool manual (10.3 Linking with dlopened modules, http://xrl.us/bjk9e5). In that section, the manual recommends to use a weak library interface. However, the example given in the manual does not work because the generated makefile lacks dependencies from libloader.la to libinterface.la's objects. Indeed. The reference to the internal *_OBJECTS variable is surprising. It would be cleaner to have a libfoo_conv.la convenience (noinst_LTLIBRARIES) archive that had the same sources as libfoo.la and add that to libbar_la_LIBADD. A patch to fix libtool.texi to this end would be appreciated. Here's a simplified and complete version of the example in the libtool manual: % cat Makefile.am 'EOF' lib_LTLIBRARIES = libbar.la libfoo.la libfoo_la_SOURCES = foo.c libbar_la_SOURCES = bar.c libbar_la_LDFLAGS = -weak libfoo.la libbar_la_LIBADD = $(libfoo_la_OBJECTS) EOF % ./configure -q make CC bar.lo CCLD libbar.la libtool: link: `foo.lo' is not a valid libtool object make: *** [libbar.la] Error 1 Looking at the generated Makefile.in, we see this is because libbar.la doesn't have any dependency on foo.lo. We can add it to the Makefile.am: libbar_la = libbar.la $(libbar_la): $(libfoo_la_OBJECTS) and now it will build. So, should automake support the example in the libtool manual, or does the libtool manual need to be fixed? If the latter, is the above workaround a good one? I see several workarounds. The one I described above is clean. Another would be to compute libbar_la_DEPENDENCIES manually, e.g.: libbar_la_DEPENDENCIES = $(libfoo_la_OBJECTS) In a real-life situation, there are other dependencies, so you'd prefer to use EXTRA_libbar_la_DEPENDENCIES = $(libfoo_la_OBJECTS) so automake will still compute libbar_la_DEPENDENCIES (available only in git Automake, will be in 1.12; sorry). One thing that I wonder about is why you actually need the foo code to be both in libfoo and libbar. If possible, then code should only ever exist in one shared library. (I may be missing details from the dlpreopen machinery here now, it's been a while ... feedback as to what worked for you appreciated.) As to whether automake should be able to look through $(*_OBJECTS) references in _LIBADD and add them to _DEPENDENCIES: yes that too seems like a viable idea. 'info Automake Program and Library Variables' is currently vague about this case (but it can be, since _OBJECTS are supposed to be internal details). So there really are two issues here, one in libtool.texi and one in Automake. Thanks for reporting them. Cheers, Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: debbugs, and a FAQ, for Autotools
Let's pick this up again, but for Libtool only for now. [ http://lists.gnu.org/archive/html/automake/2011-02/msg00025.html ] * Ralf Wildenhues wrote on Sun, Feb 13, 2011 at 07:12:02PM CET: [ Cross post; Reply-To and Mail-Followup-To set. Please followup to the automake list only, to avoid excessive spammage. Thank you. ] I've been advertising debbugs before, I think we should be a good example. So, two proposals: 1) Autoconf and Libtool should also use debbugs. bug-automake has switched a few months ago, and I find it helpful to avoid losing reports. Given that we never have enough time on our hands, it becomes more important to not lose track. Do any Libtool developers or regulars have any issue with this? We do keep forgetting about bug reports, and we do have contributors that only work every once in a while, and for both it would seem to be useful to have a list of open issues. Eric had concerns that it would be difficult to tell which package a bug was against. The Sender: header shows this, however, so I don't see it as a big problem (unless your MUA cannot be configured to show this particular header). Or we could modify debbugs to provide some more hints. If there is no disagreement by, let's say Monday, Glenn could you then set up debbugs for the bug-libtool list? Thanks, Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: libtool relinks all shared libraries when make install is performed
Hello Markus, * Markus Franke wrote on Wed, Mar 23, 2011 at 05:18:53PM CET: we have a large C++ project containing of several modules which each get compiled into seperate shared libraries. Our directory structure looks somehow as follows: [...] When performing the make install step all the libraries and binaries get installed to our prefix directory /opt/kmt. This currently takes very long (~20 minutes) as libtool relinks all libraries. [...] Wow. That's terrible. How can I avoid this additional relinking step during make install? Generally, --enable-fast-install should be the switch to avoid it. However, it is not possible to do on every system, and not fully optimized on all systems where it could be made to work. Unfortunately, GNU/Linux is one of the latter ones where Libtool still needs a bit of work. Thanks for the bug report, Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: About libtool supporting parallel make install
* Dan Nicholson wrote on Thu, Mar 17, 2011 at 11:47:38PM CET: On Thu, Mar 17, 2011 at 3:08 AM, Pacho Ramos pa...@gentoo.org wrote: https://bugzilla.gnome.org/show_bug.cgi?id=644896#c2 This seems more legitimate. I looked at the Makefile.am's and they look reasonable to me. You have two libraries, one is in lib_LTLIBRARIES and the other is in pkglib_LTLIBRARIES. The pkglib one depends on the lib one. It seems that make is running install-libLTLIBRARIES and install-pkglibLTLIBRARIES in parallel. Each one of these these rules installs the libraries serially in a loop. However, if libtool is relinking the libraries, it really needs to wait until the prerequisite libraries from _other_ rules are installed. I'd bet if you do this: echo install-pkglibLTLIBRARIES: install-libLTLIBRARIES src/backend/xml/Makefile it will work again. This seems like a bug in automake's libtool support to me, but I don't know how to fix it. Yes, it's a bug in Automake/Libtool, but the workaround isn't quite correct: you'd need something like install-pkglibLTLIBRARIES = install-pkglibLTLIBRARIES $(install-pkglibLTLIBRARIES): install-libLTLIBRARIES because your proposed workaround will cause automake to not emit its install-pkglibLTLIBRARIES rule at all. Yes, depending on automake not seeing through variables when determining target names is ugly, I know. (It's also so widespread by now that we can't easily change that issue.) I've posted some ideas to fix the original bug before, on an automake or libtool list; but nothing finished. :-/ Cheers, Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: About libtool supporting parallel make install
Hello Pacho, * Pacho Ramos wrote on Fri, Mar 18, 2011 at 11:48:51AM CET: We have some downstream opened bugs with similar cases, would you mind asking for help with them here in the future once their respective upstream refuse to fix the issues? Feel free to come to this mailing list for help about Libtool issues. Cheers, Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: About libtool supporting parallel make install
Pacho, hope you're reading the list. Mail from me to you bounces because some MTA near your end is over-eagerly using SPF to reject legitimate mail. Rakf * Ralf Wildenhues wrote on Fri, Mar 18, 2011 at 08:43:21PM CET: Hello Pacho, * Pacho Ramos wrote on Fri, Mar 18, 2011 at 11:48:51AM CET: We have some downstream opened bugs with similar cases, would you mind asking for help with them here in the future once their respective upstream refuse to fix the issues? Feel free to come to this mailing list for help about Libtool issues. Cheers, Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool
[SCM] GNU Libtool branch, master, updated. v2.4-50-g39f84c6
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project GNU Libtool.
The branch, master has been updated
via 39f84c6eba7557d73e6dacae3afb40a164c62ba1 (commit)
from 6a6de36e4c652fd0eba739c209a3b43ae7a41a5b (commit)
Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.
- Log -
commit 39f84c6eba7557d73e6dacae3afb40a164c62ba1
Author: Ralf Wildenhues ralf.wildenh...@gmx.de
Date: Mon Mar 14 07:30:53 2011 +0100
libtoolize: detect -Idir (without space) in ACLOCAL_AMFLAGS.
* libtoolize.m4sh (func_scan_files): Also accept -Idir
(without intervening space) in ACLOCAL_AMFLAGS.
* THANKS: Update.
Report from Jan Engelhardt.
Signed-off-by: Ralf Wildenhues ralf.wildenh...@gmx.de
---
Summary of changes:
ChangeLog |8
THANKS |1 +
libtoolize.m4sh | 17 ++---
3 files changed, 19 insertions(+), 7 deletions(-)
diff --git a/ChangeLog b/ChangeLog
index 528e404..4ed09a3 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,11 @@
+2011-03-14 Ralf Wildenhues ralf.wildenh...@gmx.de
+
+ libtoolize: detect -Idir (without space) in ACLOCAL_AMFLAGS.
+ * libtoolize.m4sh (func_scan_files): Also accept -Idir
+ (without intervening space) in ACLOCAL_AMFLAGS.
+ * THANKS: Update.
+ Report from Jan Engelhardt.
+
2011-03-04 Peter O'Gorman pe...@pogma.com
On Mac OS X try .dylib as well as .so with lt_dlopenext
diff --git a/THANKS b/THANKS
index 0b03320..08d7077 100644
--- a/THANKS
+++ b/THANKS
@@ -109,6 +109,7 @@
Jakub Bogusz qbo...@pld-linux.org
Jacob Meuser jake...@jakemsr.com
James Su james...@gmail.com
+ Jan Engelhardt jeng...@medozas.de
Jay Krelljay.kr...@cornell.edu
Jeff Squyres jsquy...@lam-mpi.org
Jeremy C. Reed r...@reedmedia.net
diff --git a/libtoolize.m4sh b/libtoolize.m4sh
index 844698c..cd15c58 100644
--- a/libtoolize.m4sh
+++ b/libtoolize.m4sh
@@ -556,8 +556,8 @@ func_scan_files ()
# Hunt for ACLOCAL_AMFLAGS in `Makefile.am' for a `-I' argument.
my_sed_aclocal_flags='
-/^[ ]*ACLOCAL_[A-Z_]*FLAGS[ ]*=/ {
- s,^[^=]*=[ ]*\(.*\), \1,
+/^[ ]*ACLOCAL_[A-Z_]*FLAGS[ ]*=[]*/ {
+ s,,,
q
}
d'
@@ -568,11 +568,14 @@ func_scan_files ()
am_macrodir=$arg
break
else
- if test X$arg = X-I; then
-my_macrodir_is_next=:
- else
-my_macrodir_is_next=false
- fi
+ case $arg in
+ -I) my_macrodir_is_next=: ;;
+ -I*)
+ am_macrodir=`$ECHO $arg | sed 's,^-I,,'`
+ break
+ ;;
+ *) my_macrodir_is_next=false ;;
+ esac
fi
done
fi
hooks/post-receive
--
GNU Libtool
Re: Consider adding -I $macrodir
Hi Jan,
* Jan Engelhardt wrote on Sun, Mar 13, 2011 at 03:31:40PM CET:
I have seen one project where Makefile.am used
ACLOCAL_AMFLAGS = -Im4
and libtool 2.2.6b still threw the warning
Consider adding -I m4 to Makefile.am
which is because libtool does not seem to handle bundled arguments.
Thanks. I'm pushing the patch below and adding you to THANKS.
Cheers,
Ralf
libtoolize: detect -Idir (without space) in ACLOCAL_AMFLAGS.
* libtoolize.m4sh (func_scan_files): Also accept -Idir
(without intervening space) in ACLOCAL_AMFLAGS.
* THANKS: Update.
Report from Jan Engelhardt.
diff --git a/libtoolize.m4sh b/libtoolize.m4sh
index 844698c..cd15c58 100644
--- a/libtoolize.m4sh
+++ b/libtoolize.m4sh
@@ -556,8 +556,8 @@ func_scan_files ()
# Hunt for ACLOCAL_AMFLAGS in `Makefile.am' for a `-I' argument.
my_sed_aclocal_flags='
-/^[ ]*ACLOCAL_[A-Z_]*FLAGS[ ]*=/ {
- s,^[^=]*=[ ]*\(.*\), \1,
+/^[ ]*ACLOCAL_[A-Z_]*FLAGS[ ]*=[]*/ {
+ s,,,
q
}
d'
@@ -568,11 +568,14 @@ func_scan_files ()
am_macrodir=$arg
break
else
- if test X$arg = X-I; then
-my_macrodir_is_next=:
- else
-my_macrodir_is_next=false
- fi
+ case $arg in
+ -I) my_macrodir_is_next=: ;;
+ -I*)
+ am_macrodir=`$ECHO $arg | sed 's,^-I,,'`
+ break
+ ;;
+ *) my_macrodir_is_next=false ;;
+ esac
fi
done
fi
Re: Consider adding -I $macrodir
Hi Jan,
* Jan Engelhardt wrote on Sun, Mar 13, 2011 at 03:31:40PM CET:
I have seen one project where Makefile.am used
ACLOCAL_AMFLAGS = -Im4
and libtool 2.2.6b still threw the warning
Consider adding -I m4 to Makefile.am
which is because libtool does not seem to handle bundled arguments.
Thanks. I'm pushing the patch below and adding you to THANKS.
Cheers,
Ralf
libtoolize: detect -Idir (without space) in ACLOCAL_AMFLAGS.
* libtoolize.m4sh (func_scan_files): Also accept -Idir
(without intervening space) in ACLOCAL_AMFLAGS.
* THANKS: Update.
Report from Jan Engelhardt.
diff --git a/libtoolize.m4sh b/libtoolize.m4sh
index 844698c..cd15c58 100644
--- a/libtoolize.m4sh
+++ b/libtoolize.m4sh
@@ -556,8 +556,8 @@ func_scan_files ()
# Hunt for ACLOCAL_AMFLAGS in `Makefile.am' for a `-I' argument.
my_sed_aclocal_flags='
-/^[ ]*ACLOCAL_[A-Z_]*FLAGS[ ]*=/ {
- s,^[^=]*=[ ]*\(.*\), \1,
+/^[ ]*ACLOCAL_[A-Z_]*FLAGS[ ]*=[]*/ {
+ s,,,
q
}
d'
@@ -568,11 +568,14 @@ func_scan_files ()
am_macrodir=$arg
break
else
- if test X$arg = X-I; then
-my_macrodir_is_next=:
- else
-my_macrodir_is_next=false
- fi
+ case $arg in
+ -I) my_macrodir_is_next=: ;;
+ -I*)
+ am_macrodir=`$ECHO $arg | sed 's,^-I,,'`
+ break
+ ;;
+ *) my_macrodir_is_next=false ;;
+ esac
fi
done
fi
___
http://lists.gnu.org/mailman/listinfo/libtool
Re: Mac OS X .dylib not working
[ dropping bug-libtool ]
Hi Peter,
* Peter O'Gorman wrote on Fri, Mar 04, 2011 at 07:07:30PM CET:
Ok?
A few copyright year bumps are missing.
Some minor nits inline below.
Thank you,
Ralf
Subject: [PATCH] On Mac OS X try .dylib as well as .so with lt_dlopenext
* libltdl/m4/ltdl.m4: Define extra extension if module extension
differs from shared lib extension.
* libltdl/ltdl.c: Use it.
* tests/darwin.at: Test it.
Reported by Hans Aberg, Michael Ellis, and others.
--- a/tests/darwin.at
+++ b/tests/darwin.at
@@ -228,3 +228,224 @@ mv stdout expout
LT_AT_CONFIGURE([LDFLAGS=-L/there/is/no/dir/here])
AT_CHECK([./libtool --config],[ignore],[expout],[ignore])
AT_CLEANUP
+
+AT_SETUP(darwin can lt_dlopen .dylib and .so files)
Missing m4 quotes (for style only)
+AT_KEYWORDS([libltdl dylib])
+
+# This test requires shared library support.
+AT_CHECK([$LIBTOOL --features | grep 'enable shared libraries' || exit 77],
+ [], [ignore])
+
+
+eval `$LIBTOOL --config | $EGREP '^(shlibpath_var|shrext_cmds)='`
+
+module=no
+eval shared_ext=\$shrext_cmds\
+module=yes
+eval module_ext=\$shrext_cmds\
+
+# Only bother with this test if module extension is different from
+# shared extension
+AT_CHECK([test $shared_ext != $module_ext || exit 77],
+ [], [ignore])
You can drop arguments two and three here.
+# This code is copied from the Autobook:
+# http://sources.redhat.com/autobook/autobook/autobook_169.html
+# so if it needs changes, be sure to notify the Autobook authors
+# about them.
+int
+main (int argc, const char *argv[])
+{
+ char *errormsg = NULL;
+ lt_dlhandle module = NULL;
+ entrypoint *run = NULL;
+ int errors = 0;
Isn't this lacking
LTDL_SET_PRELOADED_SYMBOLS();
or was that needed only for static libs (which you've excluded earlier)?
+ if (argc != 3)
+{
+ fprintf (stderr, USAGE: main MODULENAME ARGUMENT\n);
+ exit (EXIT_FAILURE);
+}
+
+ /* Initialise libltdl. */
+ errors = lt_dlinit ();
+
+ /* Set the module search path. */
+ if (!errors)
+{
+ const char *path = getenv (MODULE_PATH_ENV);
+
+ if (path != NULL)
+errors = lt_dlsetsearchpath (path);
+}
+
+ /* Load the module. */
+ if (!errors)
+module = lt_dlopenext (argv[1]);
+
+ /* Find the entry point. */
+ if (module)
+{
+ run = (entrypoint *) lt_dlsym (module, run);
+
+ /* In principle, run might legitimately be NULL, so
+ I don't use run == NULL as an error indicator
+ in general. */
+ errormsg = dlerrordup (errormsg);
+ if (errormsg != NULL)
+{
+ errors = lt_dlclose (module);
+ module = NULL;
+}
+}
+ else
+errors = 1;
+
+ /* Call the entry point function. */
+ if (!errors)
+{
+ int result = (*run) (argv[2]);
+ if (result 0)
+errormsg = strdup (module entry point execution failed);
+ else
+printf (\t= %d\n, result);
+}
+
+ /* Unload the module, now that we are done with it. */
+ if (!errors)
+errors = lt_dlclose (module);
+
+ if (errors)
+{
+ /* Diagnose the encountered error. */
+ errormsg = dlerrordup (errormsg);
+
+ if (!errormsg)
+{
+ fprintf (stderr, %s: dlerror() failed.\n, argv[0]);
+ return EXIT_FAILURE;
+}
+}
+
+ /* Finished with ltdl now. */
+ if (!errors)
+if (lt_dlexit () != 0)
+ errormsg = dlerrordup (errormsg);
I'm not particularly fond of this coding style, where ownership
information essentially gets lots once an error occurs in any
of the commands. Might be ok for a test like this, but not such
a good example for users. lt_dlexit could be warranted even if
some error occurred before. Anyway, I won't reject the patch for
this.
+ if (errormsg)
+{
+ fprintf (stderr, %s: %s.\n, argv[0], errormsg);
+ free (errormsg);
+ exit (EXIT_FAILURE);
+}
+
+ return EXIT_SUCCESS;
+}
+
+/* Be careful to save a copy of the error message,
+ since the next API call may overwrite the original. */
+static char *
+dlerrordup (char *errormsg)
+{
+ char *error = (char *) lt_dlerror ();
+ if (error !errormsg)
+errormsg = strdup (error);
+ return errormsg;
+}
+]])
+if test $shlibpath_var = PATH; then
This looks wrong; shouldn't it be != here? Otherwise, ...
+ $unset shlibpath_var || shlibpath_var=
+fi
+rm $libdir/simple-module.la
... this has only a small chance of succeeding.
+rm $libdir/libsimple-dylib.la
+
+for dir in inst/lib $libdir; do
+ LT_AT_EXEC_CHECK([./ltdl-loader], [], [stdout], [ignore],
+ [$dir/simple-module World])
+ AT_CHECK([grep Hello, World stdout], [], [ignore])
+ LT_AT_EXEC_CHECK([./ltdl-loader], [], [stdout], [ignore],
+ [$dir/libsimple-dylib World])
+ AT_CHECK([grep Hello, World stdout], [], [ignore])
+done
+
+AT_CLEANUP
Re: Patches for libtool support on NAG Fortran compiler for Darwin OS
Hello, * Jürgen Reuter wrote on Tue, Mar 01, 2011 at 12:24:39PM CET: as discussed with Peter I send to you a diff (compared to the 2.4 official version of libtool) to support the NAG Fortran compiler on Darwin 64bit machines. --- libtool.m4 2010-10-01 20:57:54.0 +0200 +++ ../../nag_trunk/m4/libtool.m4 2011-02-28 09:44:50.0 +0100 @@ -1053,7 +1053,7 @@ _LT_TAGVAR(link_all_deplibs, $1)=yes _LT_TAGVAR(allow_undefined_flag, $1)=$_lt_dar_allow_undefined case $cc_basename in - ifort*) _lt_dar_can_shared=yes ;; + ifort*|nagfor*) _lt_dar_can_shared=yes ;; The issue is not new with your patch, but if we can distinguish compilers based on something like '$CC -V' output or similar, then these code bits can reliably keep working even with MPI (or other) wrappers to the compilers. We've moved this way for a couple of other compilers recently. Since this is typically a strict improvement, a patch to add support is fine even without it, but while you're testing anyway, you might be interested to fix it right away. Your choice. Thanks, Ralf
Re: -soname passed directly to the compiler
* tom fogal wrote on Tue, Feb 15, 2011 at 06:34:44PM CET: Hi, sorry for the slow response. No worries. Ralf Wildenhues writes: Hmm, even libtool 1.5.26 should be detecting mpicc as gcc but apparently it isn't. You could look in config.log to find out why. I'd really really suggest using a newer Libtool though [. . .] Just wanted to follow up for the archives. I upgraded libtool but hit lots of strange issues. Ended up upgrading both autoconf and automake too, which of course were also a few years old. I was still hitting issues, now with libtool trying to execute X--gcc or something like that; it seemed to be a common problem, from google searches, yet nobody had a concrete answer. I'm afraid I don't either: my solution was to stash my current changes and `git clean -df'. I don't version control configure, aclocal.m4, config.* etc., and so this got me a virgin tree. At that point 'libtoolize --copy --force autoreconf -vi' got me a working build system. There must have been some sort of state which was not getting overwritten from the above w/o cleaning out the whole tree, but I do not know what it was, exactly. I want to add this to the to-be-written FAQ. I have half an idea of where that bug comes from but would like to make sure. Please specify exactly which Autoconf, Automake, and Libtool versions you used before upgrading, and then, in which order you upgraded which tool to what newer version. Thanks, Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool
debbugs, and a FAQ, for Autotools
[ Cross post; Reply-To and Mail-Followup-To set. Please followup to the automake list only, to avoid excessive spammage. Thank you. ] Hello everyone, I've been advertising debbugs before, I think we should be a good example. So, two proposals: 1) Autoconf and Libtool should also use debbugs. bug-automake has switched a few months ago, and I find it helpful to avoid losing reports. Given that we never have enough time on our hands, it becomes more important to not lose track. See http://debbugs.gnu.org/ and linked pages for details. 2) Autotools should have a FAQ document. Not of the sort of the FAQ chapter that answers seven random questions and that has a 1 year+ latency until it is updated, but one that answers both totally-newbie kinds of questions that get asked over and over again, or cross-tool bug questions like the infamous libtool echo problem (which was due to an incompatible m4sugar change). A document that, ideally, eventually obsoletes many of the third-party here's how autotools work, in quick kinds of pages. See e.g., this most recent thread which made the need so clear again: http://thread.gmane.org/gmane.comp.sysutils.automake.patches/5672 For (2) I'd suggest a wiki if we GNU the infrastructure, but something like a new page http://www.gnu.org/software/automake/Autotools-FAQ.html would certainly be good. (And yes, I've been arguing against wikis in the past. I was wrong. Sue me.) Now, I have very little spare time on my hands. Any volunteers on managing such a document? Any people interested in contributing answers or even only questions? I wouldn't mind handing out commit privs to any of the regulars on these lists. Thanks for feedback, Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: -soname passed directly to the compiler
Hello Tom, * tom fogal wrote on Sun, Feb 13, 2011 at 10:23:30PM CET: A package we're converting to the autotools is having an issue building a library; it seems to think gcc supports a -soname option. /bin/sh ../libtool --tag=CC --mode=link mpicc -I/home/tfogal/sw/include -L/home/tfogal/sw/lib -o libH5Part.la -rpath /home/tfogal/dev/install-h5part/lib H5Part.lo H5PartAttrib.lo H5Block.lo H5BlockReadWrite.lo H5MultiBlock.lo H5MultiBlockReadWrite.lo -lhdf5 mpicc -shared .libs/H5Part.o .libs/H5PartAttrib.o .libs/H5Block.o .libs/H5BlockReadWrite.o .libs/H5MultiBlock.o .libs/H5MultiBlockReadWrite.o -L/home/tfogal/sw/lib /home/tfogal/shigeru/lib/libhdf5.a -lc -soname libH5Part.so.0 -o .libs/libH5Part.so.0.0.0 gcc: libH5Part.so.0: No such file or directory gcc: unrecognized option '-soname' ltmain.sh (GNU libtool) 1.5.26 Debian 1.5.26-4+lenny1 (1.1220.2.493 2008/02/01 16:58:18) Hmm, even libtool 1.5.26 should be detecting mpicc as gcc but apparently it isn't. You could look in config.log to find out why. I'd really really suggest using a newer Libtool though, 2.4 is the current version, and I'm not eager to debug issues in the 1.5 branch (which has been dead for almost three years now) any more. Thanks, Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool
[SCM] GNU Libtool branch, master, updated. v2.4-47-gd6f69ef
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project GNU Libtool.
The branch, master has been updated
via d6f69ef647cb09d1baed104e769377f743a8aa8f (commit)
from 86562ff7358179df2c44669c53525a86b3723312 (commit)
Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.
- Log -
commit d6f69ef647cb09d1baed104e769377f743a8aa8f
Author: Ralf Wildenhues ralf.wildenh...@gmx.de
Date: Mon Feb 7 07:40:17 2011 +0100
docs: fix copyright years in PDF version of the manual.
* doc/libtool.texi: Fix copyright years.
---
Summary of changes:
ChangeLog|5 +
doc/libtool.texi |2 +-
2 files changed, 6 insertions(+), 1 deletions(-)
diff --git a/ChangeLog b/ChangeLog
index 7165e8a..6e89fa8 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,8 @@
+2011-02-07 Ralf Wildenhues ralf.wildenh...@gmx.de
+
+ docs: fix copyright years in PDF version of the manual.
+ * doc/libtool.texi: Fix copyright years.
+
2011-02-01 Rainer Orth r...@cebitec.uni-bielefeld.de (tiny change)
Fix LD setting for 64-bit Solaris 2/x86.
diff --git a/doc/libtool.texi b/doc/libtool.texi
index 727a03d..72bb0fc 100644
--- a/doc/libtool.texi
+++ b/doc/libtool.texi
@@ -53,7 +53,7 @@ identical to this one except for the removal of this paragraph
@page
@vskip 0pt plus 1filll
-Copyright @copyright{} 2011 Free Software Foundation, Inc.
+Copyright @copyright{} 1996-2011 Free Software Foundation, Inc.
Permission is granted to copy, distribute and/or modify this document
under the terms of the GNU Free Documentation License, Version 1.3
hooks/post-receive
--
GNU Libtool
docs: fix copyright years in PDF version of the manual.
libtool.pdf was showing only the current year in the copyright
statement. This patch fixes it, applied to master.
Cheers,
Ralf
docs: fix copyright years in PDF version of the manual.
* doc/libtool.texi: Fix copyright years.
diff --git a/doc/libtool.texi b/doc/libtool.texi
index 070bc9b..3c7ff49 100644
--- a/doc/libtool.texi
+++ b/doc/libtool.texi
@@ -53,7 +53,7 @@ identical to this one except for the removal of this paragraph
@page
@vskip 0pt plus 1filll
-Copyright @copyright{} 2011 Free Software Foundation, Inc.
+Copyright @copyright{} 1996-2011 Free Software Foundation, Inc.
Permission is granted to copy, distribute and/or modify this document
under the terms of the GNU Free Documentation License, Version 1.3
Re: MirBSD support and a question
Hello Benny,
first off, thanks for your patch, and sorry for the delay.
* Benny Siegert wrote on Sat, Jan 29, 2011 at 04:50:04PM CET:
I would like to add MirBSD support to upstream libtool. MirBSD (or
MirOS BSD) is an OS derived from OpenBSD. I want to use
version_type=linux instead of sunos because it works much better,
from several years experience with our own patched version of
libtool 1.5.
Do I understand correctly that your patched libtool used in MirBSD also
uses version_type=linux?
Are there users out there who use some libtool on MirBSD that uses a
different version_type? This is very important to know, as when we add
support, for they might need a flag day when their old libraries and
programs start breaking.
A notable idiosyncrasy of our runtime linker is that shared
libraries _must_ have a two-digit version (libfoo.so.0.0 for
example) to be able to link against them. In the attached patch, I
solved it like this:
library_names_spec='${libname}${release}${shared_ext}${major}.${age}
${libname}${shared_ext}${major}.${age}'
Is this okay or should it be done differently?
Well, that's really hard to answer without knowing the exact semantics of
your link editor and runtime linker. What gets encoded as DT_SONAME,
and as DT_NEEDED? How are symlinks set usually, if any? Does the
runtime linker consider libraries with some sets of numbers as
compatible upgrades (like GNU ld.so does), and if so, how is the
encoding of the numbers? Which numbers are allowed where (zero or only
greater ones)?
However, there is one case where this breaks: When a -release is
given but no -version-info, the $major variable is reset. In
ltmain.m4sh, line 6705, $major is reset to an empty string:
# Clear the version info if we defaulted, and they specified
a release.
if test -z $vinfo test -n $release; then
major=
Why is this so? Can this line be safely removed?
I don't think it can. Don't you just need to set need_version=yes?
See the dozen or so lines below this.
Other than the points above, your patch looks ok to me. It still needs
a proper ChangeLog entry and a NEWS entry, but we can write that. Do
you mind being added to THANKS?
Thanks,
Ralf
[SCM] GNU Libtool branch, master, updated. v2.4-45-g9196966
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project GNU Libtool.
The branch, master has been updated
via 9196966580f6853a31187a7a3c7e7ff36ef08982 (commit)
from 286e87b1030c353d9cfc89dbb72d59e0391cb693 (commit)
Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.
- Log -
commit 9196966580f6853a31187a7a3c7e7ff36ef08982
Author: Rainer Orth r...@cebitec.uni-bielefeld.de
Date: Tue Feb 1 07:34:26 2011 +0100
Fix LD setting for 64-bit Solaris 2/x86.
* libltdl/m4/libtool.m4 (_LT_ENABLE_LOCK) [*-*-solaris*):
Determine GNU ld options for 64-bit Solaris 2/x86. Detect gld
2.21 _sol2 emulations.
Signed-off-by: Ralf Wildenhues ralf.wildenh...@gmx.de
---
Summary of changes:
ChangeLog |7 +++
libltdl/m4/libtool.m4 | 17 +++--
2 files changed, 22 insertions(+), 2 deletions(-)
diff --git a/ChangeLog b/ChangeLog
index 8ff779b..ef4c27c 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,10 @@
+2011-02-01 Rainer Orth r...@cebitec.uni-bielefeld.de (tiny change)
+
+ Fix LD setting for 64-bit Solaris 2/x86.
+ * libltdl/m4/libtool.m4 (_LT_ENABLE_LOCK) [*-*-solaris*):
+ Determine GNU ld options for 64-bit Solaris 2/x86. Detect gld
+ 2.21 _sol2 emulations.
+
2011-01-27 Peter O'Gorman pe...@pogma.com
Don't loop through wrapper script arguments unnecessarily.
diff --git a/libltdl/m4/libtool.m4 b/libltdl/m4/libtool.m4
index 033c9a0..5cc027b 100644
--- a/libltdl/m4/libtool.m4
+++ b/libltdl/m4/libtool.m4
@@ -1374,14 +1374,27 @@ s390*-*linux*|s390*-*tpf*|sparc*-*linux*)
CFLAGS=$SAVE_CFLAGS
fi
;;
-sparc*-*solaris*)
+*-*solaris*)
# Find out which ABI we are using.
echo 'int i;' conftest.$ac_ext
if AC_TRY_EVAL(ac_compile); then
case `/usr/bin/file conftest.o` in
*64-bit*)
case $lt_cv_prog_gnu_ld in
- yes*) LD=${LD-ld} -m elf64_sparc ;;
+ yes*)
+case $host in
+i?86-*-solaris*)
+ LD=${LD-ld} -m elf_x86_64
+ ;;
+sparc*-*-solaris*)
+ LD=${LD-ld} -m elf64_sparc
+ ;;
+esac
+# GNU ld 2.21 introduced _sol2 emulations. Use them if available.
+if ${LD-ld} -V | grep _sol2 /dev/null 21; then
+ LD=${LD-ld}_sol2
+fi
+;;
*)
if ${LD-ld} -64 -r -o conftest2.o conftest.o /dev/null 21; then
LD=${LD-ld} -64
hooks/post-receive
--
GNU Libtool
[SCM] GNU Libtool branch, master, updated. v2.4-46-g86562ff
This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project GNU Libtool. The branch, master has been updated via 86562ff7358179df2c44669c53525a86b3723312 (commit) from 9196966580f6853a31187a7a3c7e7ff36ef08982 (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log - commit 86562ff7358179df2c44669c53525a86b3723312 Author: Ralf Wildenhues ralf.wildenh...@gmx.de Date: Tue Feb 1 07:48:39 2011 +0100 fix typo in ChangeLog --- Summary of changes: ChangeLog |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/ChangeLog b/ChangeLog index ef4c27c..7165e8a 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,7 +1,7 @@ 2011-02-01 Rainer Orth r...@cebitec.uni-bielefeld.de (tiny change) Fix LD setting for 64-bit Solaris 2/x86. - * libltdl/m4/libtool.m4 (_LT_ENABLE_LOCK) [*-*-solaris*): + * libltdl/m4/libtool.m4 (_LT_ENABLE_LOCK) [*-*-solaris*]: Determine GNU ld options for 64-bit Solaris 2/x86. Detect gld 2.21 _sol2 emulations. hooks/post-receive -- GNU Libtool
Re: [libgo, build] Use convenience libraries to create .gox files
[ adding libtool-patches ]
* Rainer Orth wrote on Mon, Jan 31, 2011 at 03:54:29PM CET:
GNU ld testing failed initially for the 64-bit multilib:
libtool: link:
/vol/gcc/obj/gcc-4.6.0-20110128/11-gcc-gas-gld-go/./gcc/collect-ld -r -o
crypto/libsubtle.o--whole-archive crypto/.libs/libsubtle.a
--no-whole-archive
/vol/gcc/bin/gld-2.21: Relocatable linking with relocations from format
elf64-x86-64-sol2 (sort/.libs/libsort.a(libsort.a.o)) to format
elf32-i386-sol2 (sort/libsort.o) is not supported
make[7]: *** [sort/libsort.lo] Error 1
Ultimately, this turned out to be a libtool issue: it doesn't handle
Solaris 2/x86 at all, and Solaris 2/SPARC with GNU ld is incomplete in
that it doesn't account for the new *_sol2 emulations in gld 2.21. All
this second-guessing the compiler suggests to me that it's a bad idea to
call the linker directly if gcc is in use.
I know libtool bashing is hitting an easy target, but IIRC we still had
user reports last year of (probably older) GCC installations where
partial linking did not work when using the gcc driver, as opposed to
using ld directly (note! for partial linking).
Anyway, I'm applying your patch to upstream Libtool, as below.
Thanks,
Ralf
2011-02-01 Rainer Orth ro@... (tiny change)
Fix LD setting for 64-bit Solaris 2/x86.
* libltdl/m4/libtool.m4 (_LT_ENABLE_LOCK) [*-*-solaris*):
Determine GNU ld options for 64-bit Solaris 2/x86. Detect gld
2.21 _sol2 emulations.
diff --git a/libltdl/m4/libtool.m4 b/libltdl/m4/libtool.m4
index 033c9a0..5cc027b 100644
--- a/libltdl/m4/libtool.m4
+++ b/libltdl/m4/libtool.m4
@@ -1374,14 +1374,27 @@ s390*-*linux*|s390*-*tpf*|sparc*-*linux*)
CFLAGS=$SAVE_CFLAGS
fi
;;
-sparc*-*solaris*)
+*-*solaris*)
# Find out which ABI we are using.
echo 'int i;' conftest.$ac_ext
if AC_TRY_EVAL(ac_compile); then
case `/usr/bin/file conftest.o` in
*64-bit*)
case $lt_cv_prog_gnu_ld in
- yes*) LD=${LD-ld} -m elf64_sparc ;;
+ yes*)
+case $host in
+i?86-*-solaris*)
+ LD=${LD-ld} -m elf_x86_64
+ ;;
+sparc*-*-solaris*)
+ LD=${LD-ld} -m elf64_sparc
+ ;;
+esac
+# GNU ld 2.21 introduced _sol2 emulations. Use them if available.
+if ${LD-ld} -V | grep _sol2 /dev/null 21; then
+ LD=${LD-ld}_sol2
+fi
+;;
*)
if ${LD-ld} -64 -r -o conftest2.o conftest.o /dev/null 21; then
LD=${LD-ld} -64
links between PDF manuals
FYI, I added .symlinks entries for the PDF manuals that the online
copies of {automake,libtool}.pdf link to, so that it should now be
possible to jump from one manual to the other in a decent PDF reader.
This was prompted by a report against Autoconf.
Cheers,
Ralf
Re: how to debug unexpected dependency
Hello Mirko, * Mirko Vukovic wrote on Thu, Jan 27, 2011 at 06:31:04PM CET: A build of mpc on 64-bit RHEL5 fails. I tracked down the cause to an entry in libmpc.la file: # Libraries that this one depends upon. dependency_libs=' /usr/local/lib/libmpfr.la/home/nini/OpenFOAM/ThirdParty-1.7.0/platforms/linux64/gmp-5.0.1/lib/ libgmp.la /usr/local/lib/libgmp.la' I am looking for ideas on how to debug this condition. Usually, by looking at the output of the 'libtool --mode=link' command that produces this library, with --debug added as first argument to libtool. In this (usually large!) trace output find out why this path is searched at all. That usually points to where the problem comes from. If you have the trace but cannot decipher it, feel free to post it here, gzip'ed. Hope that helps. Cheers, Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: How to create only executable files
* Sergio Belkin wrote on Mon, Jan 24, 2011 at 11:42:25AM CET: Let's say that you have a library libfoo.so and you have on build tree a source file fred.c. You've created a test target that creat (with -no-install flag) the ELF executable fred (note that has no extension). But libtool create also fred.o an ELF relocatable, is there a way that libtool create only the ELF excutable? What is the advantage of create an intermediate file? Simplicity of (Automake+Libtool) implementation. Absence of (non-esthetic) downsides for the user. Cheers, Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: pic-only option not working as expected
* John Calcote wrote on Sat, Jan 22, 2011 at 08:42:33PM CET: LT_INIT([disable-shared static pic-only]) ... While playing with these options, I noticed that the 'disable-shared' and 'static' options seem to have the desired effect, but the 'pic-only' option does not. Whether I use 'pic-only' or not, I get the following output from 'configure --help': I was just going to get to this patch tomorrow. I haven't retested it and am on a run now. Can you try it? Jose reported this to me off-list. Thanks, Ralf Fix LT_INIT([pic-only]) semantics. * libltdl/m4/ltoptions.m4 (_LT_WITH_PIC): Use the macro argument for setting the default for pic_mode. * tests/pic.at: New file, new test. * Makefile.am (TESTSUITE_AT): Update. Reports by Jose Marchesi, Luke Mewburn, and John Calcote. diff --git a/Makefile.am b/Makefile.am index 15d9404..3c8f213 100644 --- a/Makefile.am +++ b/Makefile.am @@ -510,6 +510,7 @@ TESTSUITE_AT= tests/testsuite.at \ tests/stresstest.at \ tests/cmdline_wrap.at \ tests/pic_flag.at \ + tests/pic.at \ tests/old-autotools.at \ tests/darwin.at \ tests/dumpbin-symbols.at \ diff --git a/libltdl/m4/ltoptions.m4 b/libltdl/m4/ltoptions.m4 index 5d9acd8..91876f0 100644 --- a/libltdl/m4/ltoptions.m4 +++ b/libltdl/m4/ltoptions.m4 @@ -344,7 +344,7 @@ m4_define([_LT_WITH_PIC], IFS=$lt_save_ifs ;; esac], -[pic_mode=default]) +[pic_mode=m4_default([$1], [default])]) test -z $pic_mode pic_mode=m4_default([$1], [default]) diff --git a/tests/pic.at b/tests/pic.at new file mode 100644 index 000..545d9cc --- /dev/null +++ b/tests/pic.at @@ -0,0 +1,38 @@ +# pic.at -- LT_INIT(pic) -*- Autotest -*- + +# Copyright (C) 2010 Free Software Foundation, Inc. +# +# This file is part of GNU Libtool. +# +# GNU Libtool is free software; you can redistribute it and/or +# modify it under the terms of the GNU General Public License as +# published by the Free Software Foundation; either version 2 of +# the License, or (at your option) any later version. +# +# GNU Libtool is distributed in the hope that it will be useful, +# but WITHOUT ANY WARRANTY; without even the implied warranty of +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +# GNU General Public License for more details. +# +# You should have received a copy of the GNU General Public License +# along with GNU Libtool; see the file COPYING. If not, a copy +# can be downloaded from http://www.gnu.org/licenses/gpl.html, +# or obtained by writing to the Free Software Foundation, Inc., +# 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA. + + +AT_SETUP([pic-only]) + +AT_DATA([configure.ac], +[[AC_INIT +AC_CONFIG_MACRO_DIR([m4]) +LT_INIT([pic-only]) +AC_OUTPUT +]]) + +mkdir m4 +LT_AT_BOOTSTRAP([--install], [], [ignore], [ignore], [], [], [ignore]) +AT_CHECK([./libtool --config | grep pic_mode], [], [pic_mode=yes +]) + +AT_CLEANUP ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: [PATCH] libtool.m4: remove (incorrect) handling of FreeBSD 1.x
Hi Gerald,
* Gerald Pfeifer wrote on Thu, Jan 20, 2011 at 12:01:58AM CET:
FreeBSD has been dead for way over a decade (FreeBSD 2.0 was released
in 1994) and without support for dynamic linking and shared libraries
I doubt there's a lot of software that would build at all.
In anycase, libtool's handling code to handle it is buggy and will soon
also match FreeBSD 10.0 and later which do support dynamic linking.
Good point.
I think it's best to simplify libtool.m4 per the patch below.
I do not have libtool write access, so appreciate help.
I am committing it in your name to Libtool git master, as below,
including a NEWS update, and adding you to THANKS. Note that you also
need to send a patch for toplevel config.rpath to upstream bug-gnulib.
Let me know how to handle this for GCC, where this should go to HEAD,
4.5 and 4.4 at least.
If you are willing to do this, so I don't have to, that would be great!
After you change toplevel libtool.m4 in GCC (and src), you need to
ensure all affected configure scripts are rebuilt; running autoconf
in each directory containing a configure should suffice. If you do
a full build of all languages and --enable-maintainer-mode, then an
incremental build should do as well, but the former is much faster
and more reliable.
With the 4.4 branch, I'm not totally sure whether all aclocal.m4 files
were already correct in m4_include'ing libtool.m4 instead of containing
copies of the libtool.m4 code; a quick check shows that not to be the
case, so above strategy should be safe.
You might need to look at libjava/{classpath,libltdl} separately.
Unless you send a patch to classpath, their next update might undo the
change (I'm not sure about this).
Hope that helps.
Cheers,
Ralf
2011-01-20 Gerald Pfeifer ger...@pfeifer.com (tiny change)
Remove support for FreeBSD 1.x.
* libltdl/m4/libtool.m4 (_LT_LINKER_SHLIBS)
(_LT_SYS_DYNAMIC_LINKER): Remove handling of freebsd1* which
soon would incorrectly match FreeBSD 10.0.
* NEWS, THANKS: Update.
diff --git a/NEWS b/NEWS
index 39eb771..dbad2ae 100644
--- a/NEWS
+++ b/NEWS
@@ -28,6 +28,7 @@ New in 2.4.2 2011-??-??: git version 2.4.1a, Libtool team:
* Changes in supported systems or compilers:
- Fixes for gfortran on Darwin, XL Fortran on GNU/Linux.
+ - Support for FreeBSD 1.x (outdated since 1994) has been removed.
New in 2.4 2010-09-22: git version 2.2.11a, Libtool team:
diff --git a/libltdl/m4/libtool.m4 b/libltdl/m4/libtool.m4
index ba2d5e4..033c9a0 100644
--- a/libltdl/m4/libtool.m4
+++ b/libltdl/m4/libtool.m4
@@ -2455,10 +2455,6 @@ dgux*)
shlibpath_var=LD_LIBRARY_PATH
;;
-freebsd1*)
- dynamic_linker=no
- ;;
-
freebsd* | dragonfly*)
# DragonFly does not have aout. When/if they implement a new
# versioning mechanism, adjust this.
@@ -5178,10 +5174,6 @@ _LT_EOF
_LT_TAGVAR(hardcode_shlibpath_var, $1)=no
;;
-freebsd1*)
- _LT_TAGVAR(ld_shlibs, $1)=no
- ;;
-
# FreeBSD 2.2.[012] allows us to include c++rt0.o to get C++ constructor
# support. Future versions do this automatically, but an explicit c++rt0.o
# does not break anything, and helps significantly (at the cost of a little
Re: [PATCH] Darwin - verbose linker messages influence configure results.
Hi Peter, * Peter O'Gorman wrote on Wed, Jan 19, 2011 at 05:26:26PM CET: Patch Ok? If it turns the testsuite addition from failing to passing, yes, with a couple of nits below fixed. Thanks, Ralf Subject: [PATCH] Don't let verbose linker messages influence test results. * libltdl/m4/libtool.m4 (_LT_REQUIRED_DARWIN_CHECKS): Ignore stderr during tests for -flag unless it contains flag. * tests/darwin.at: Add test. Reported by Jeremy Huddleston and also by David Fang. --- a/libltdl/m4/libtool.m4 +++ b/libltdl/m4/libtool.m4 @@ -986,7 +986,13 @@ m4_defun_once([_LT_REQUIRED_DARWIN_CHECKS],[ $LTCC $LTCFLAGS $LDFLAGS -o libconftest.dylib \ -dynamiclib -Wl,-single_module conftest.c 2conftest.err _lt_result=$? - if test -f libconftest.dylib test ! -s conftest.err test $_lt_result = 0; then + # If there is a non-empty error log, and single_module + # appears in it, assume the flag caused a linker warning +if test -s conftest.err $GREP single_module conftest.err; then + cat conftest.err AS_MESSAGE_LOG_FD + # Otherwise, if the output was created with a 0 exit code from + # the compiler, it worked. + elif test -f libconftest.dylib test $_lt_result = 0; then -eq instead of = lt_cv_apple_cc_single_mod=yes else cat conftest.err AS_MESSAGE_LOG_FD @@ -994,6 +1000,7 @@ m4_defun_once([_LT_REQUIRED_DARWIN_CHECKS],[ rm -rf libconftest.dylib* rm -f conftest.* fi]) + AC_CACHE_CHECK([for -exported_symbols_list linker flag], [lt_cv_ld_exported_symbols_list], [lt_cv_ld_exported_symbols_list=no @@ -1005,6 +1012,7 @@ m4_defun_once([_LT_REQUIRED_DARWIN_CHECKS],[ [lt_cv_ld_exported_symbols_list=no]) LDFLAGS=$save_LDFLAGS ]) + AC_CACHE_CHECK([for -force_load linker flag],[lt_cv_ld_force_load], [lt_cv_ld_force_load=no cat conftest.c _LT_EOF @@ -1022,7 +1030,9 @@ _LT_EOF echo $LTCC $LTCFLAGS $LDFLAGS -o conftest conftest.c -Wl,-force_load,./libconftest.a AS_MESSAGE_LOG_FD $LTCC $LTCFLAGS $LDFLAGS -o conftest conftest.c -Wl,-force_load,./libconftest.a 2conftest.err _lt_result=$? - if test -f conftest test ! -s conftest.err test $_lt_result = 0 $GREP forced_load conftest 21 /dev/null; then + if test -s conftest.err $GREP force_load conftest.err; then + cat conftest.err AS_MESSAGE_LOG_FD + elif test -f conftest test $_lt_result = 0 $GREP forced_load conftest 21 /dev/null; then Likewise. Also, /dev/null 21 (order matters!) Are you really grepping the binary intentionally here, rather than the .err file? lt_cv_ld_force_load=yes else cat conftest.err AS_MESSAGE_LOG_FD
Re: Stop relink searching host directory when installation prefix provided
Hello Martin, * Martin Panter wrote on Sun, Jan 16, 2011 at 01:04:00PM CET: Don't search host directory during relink if $inst_prefix is provided --- libtool-2.4.orig/libltdl/config/ltmain.m4sh +++ libtool-2.4/libltdl/config/ltmain.m4sh @@ -6122,12 +6122,14 @@ func_mode_link () fi else # We cannot seem to hardcode it, guess we'll fake it. - add_dir=-L$libdir - # Try looking first in the location we're being installed to. + + # Default if $libdir is not relative to the prefix: + add_dir=-L$libdir + if test -n $inst_prefix_dir; then case $libdir in [\\/]*) - func_append add_dir -L$inst_prefix_dir$libdir + add_dir=-L$inst_prefix_dir$libdir ;; esac fi Wouldn't it also suffice to just prepend instead of append -L$inst_prefix_dir$libdir? If no, why not? Asking because I'm fairly sure not everybody uses DESTDIR for cross compilation and assumes that the target directory is no-go land for us. (I for one often do 'make install DESTDIR=/tmp/dest' merely to tar up the installation tree to be scp'ed to another machine where the NFS share is mounted rw.) I haven't looked into this in detail yet, but thanks for the good writeup and the many references. We need testsuite exposure for this. Cheers, Ralf
Re: Libtool sysroot RPATH problems
Hello Richard,
* Richard Purdie wrote on Wed, Jan 12, 2011 at 12:06:13AM CET:
Firstly, for the first time ever for us, it appears libtool is no longer
relinking our libraries at install time.
That's weird, I don't think the sysroot feature should've caused this
change. Not quite sure though.
This is welcome as we're cross
compiling to a sysroot and we'd never want to actually run them in situ
so this could probably save us some build time. It does however mean we
never go for a relink step so we're hitting codepaths and issues that
I've never seen. For reference, we always used to set installed=no in
our staged libraries prior to sysroot support since this let us hack
around the lack of sysroot support easier.
Anyhow, the problem I'm seeing is that the final library has an RPATH
including the sysroot prefix when make is calling libtool with
-rpath /usr/lib at link time. I looked at the code in ltmain.m4sh
starting at line 7240 (see the end of the email for a quotation) and
firstly, I don't understand why the func_replace_sysroot call is inside
the $hardcode_libdir_separator test? Surely it should be outside it and
happen whenever $hardcode_libdir_flag_spec is set?
Please show the --mode={link,install} commands plus all of their output,
also './libtool --config'. Please also show how exactly you invoke
configure. Thanks.
Changing that helps a bit and I end up with an RPATH of =/usr/lib so
the sysroot prefix is gone but the = is there. I suspect that isn't
valid so I added the following code after the func_replace_sysroot call
func_stripname '=' '' $libdir
libdir=$func_stripname_result
and then I get an RPATH of /usr/lib which is ok to a point.
The replacing of '=' can be achieved by running 'libtool --mode=finish
LIB' later, although I see we don't document this everywhere yet.
Of course this is listed in $sys_lib_dlsearch_path_spec so shouldn't be
getting added at all. Its coming to this function via $compile_rpath
which is being set around line 5939 which in turn is coming from absdir.
absdir is being compared against $sys_lib_dlsearch_path_spec but without
adding/removing any sysroot prefixes.
Hmm, that sounds like a bug indeed.
I'd really therefore like to ask what behaviour to be expecting from
libtool before I try and write patches to fix any of this. To summarise
some of my questions:
I can answer them only with more information, sorry.
Thanks,
Ralf
___
http://lists.gnu.org/mailman/listinfo/libtool
[SCM] GNU Libtool branch, master, updated. v2.4-40-ga55208d
This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project GNU Libtool. The branch, master has been updated via a55208d56bf723f68b245c6ea03ce3f36a2e23ba (commit) from ce87974b8e4315c296629578f9abd089fda60412 (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log - commit a55208d56bf723f68b245c6ea03ce3f36a2e23ba Author: Ralf Wildenhues ralf.wildenh...@gmx.de Date: Sun Jan 9 17:55:17 2011 +0100 Fix $wl setting for Solaris Studio 12.2 f90 on GNU/Linux. * libltdl/m4/libtool.m4 (_LT_COMPILER_PIC) [linux] lt_prog_compiler_wl: Set to '-Qoption ld ' if we detect Sun Fortran version 8.4 or newer. Report by Terry Dontje. Signed-off-by: Ralf Wildenhues ralf.wildenh...@gmx.de --- Summary of changes: ChangeLog |8 libltdl/m4/libtool.m4 |7 ++- 2 files changed, 14 insertions(+), 1 deletions(-) diff --git a/ChangeLog b/ChangeLog index bcbc448..186ccc3 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,3 +1,11 @@ +2011-01-09 Ralf Wildenhues ralf.wildenh...@gmx.de + + Fix $wl setting for Solaris Studio 12.2 f90 on GNU/Linux. + * libltdl/m4/libtool.m4 (_LT_COMPILER_PIC) [linux] + lt_prog_compiler_wl: Set to '-Qoption ld ' if we + detect Sun Fortran version 8.4 or newer. + Report by Terry Dontje. + 2011-01-07 Peter Rosin p...@lysator.liu.se Convert file name to toolchain format when blessing archives. diff --git a/libltdl/m4/libtool.m4 b/libltdl/m4/libtool.m4 index c144755..fd79dcf 100644 --- a/libltdl/m4/libtool.m4 +++ b/libltdl/m4/libtool.m4 @@ -4363,12 +4363,17 @@ m4_if([$1], [CXX], [ ;; *) case `$CC -V 21 | sed 5q` in - *Sun\ F* | *Sun*Fortran*) + *Sun\ Ceres\ Fortran* | *Sun*Fortran*\ [[1-7]].* | *Sun*Fortran*\ 8.[[0-3]]*) # Sun Fortran 8.3 passes all unrecognized flags to the linker _LT_TAGVAR(lt_prog_compiler_pic, $1)='-KPIC' _LT_TAGVAR(lt_prog_compiler_static, $1)='-Bstatic' _LT_TAGVAR(lt_prog_compiler_wl, $1)='' ;; + *Sun\ F* | *Sun*Fortran*) + _LT_TAGVAR(lt_prog_compiler_pic, $1)='-KPIC' + _LT_TAGVAR(lt_prog_compiler_static, $1)='-Bstatic' + _LT_TAGVAR(lt_prog_compiler_wl, $1)='-Qoption ld ' + ;; *Sun\ C*) # Sun C 5.9 _LT_TAGVAR(lt_prog_compiler_pic, $1)='-KPIC' hooks/post-receive -- GNU Libtool
[SCM] GNU Libtool branch, master, updated. v2.4-41-g9167aec
This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project GNU Libtool. The branch, master has been updated via 9167aecabd12c5afe7a65d45dc73f8c92ab42f05 (commit) from a55208d56bf723f68b245c6ea03ce3f36a2e23ba (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log - commit 9167aecabd12c5afe7a65d45dc73f8c92ab42f05 Author: John David Anglin dave.ang...@nrc-cnrc.gc.ca Date: Sun Jan 9 19:51:28 2011 +0100 Fix relink mode to use absolute path if hardcode_minus_L. * libltdl/config/ltmain.m4sh (func_mode_link): Use absolute path when hardcoding with -L. Signed-off-by: Ralf Wildenhues ralf.wildenh...@gmx.de --- Summary of changes: ChangeLog |6 ++ libltdl/config/ltmain.m4sh |2 +- 2 files changed, 7 insertions(+), 1 deletions(-) diff --git a/ChangeLog b/ChangeLog index 186ccc3..1ad3741 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,3 +1,9 @@ +2011-01-09 John David Anglin dave.ang...@nrc-cnrc.gc.ca (tiny change) + + Fix relink mode to use absolute path if hardcode_minus_L. + * libltdl/config/ltmain.m4sh (func_mode_link): Use absolute path + when hardcoding with -L. + 2011-01-09 Ralf Wildenhues ralf.wildenh...@gmx.de Fix $wl setting for Solaris Studio 12.2 f90 on GNU/Linux. diff --git a/libltdl/config/ltmain.m4sh b/libltdl/config/ltmain.m4sh index d9e1cd2..7baa6aa 100644 --- a/libltdl/config/ltmain.m4sh +++ b/libltdl/config/ltmain.m4sh @@ -6050,7 +6050,7 @@ func_mode_link () test $hardcode_direct_absolute = no; then add=$dir/$linklib elif test $hardcode_minus_L = yes; then - add_dir=-L$dir + add_dir=-L$absdir # Try looking first in the location we're being installed to. if test -n $inst_prefix_dir; then case $libdir in hooks/post-receive -- GNU Libtool
Re: Oracle Solaris Studio 12.2 compiler incompatibility with libtool
* Ethan Mallove wrote on Mon, Dec 20, 2010 at 03:29:01PM CET: On Mon, Dec/20/2010 08:06:27AM, Ralf Wildenhues wrote: Ping! Tested. Looks good! Thanks, and apologies for the delay on my side now. Pushed. Cheers, Ralf 2010-11-18 Ralf Wildenhues... Fix $wl setting for Solaris Studio 12.2 f90 on GNU/Linux. * libltdl/m4/libtool.m4 (_LT_COMPILER_PIC) [linux] lt_prog_compiler_wl: Set to '-Qoption ld ' if we detect Sun Fortran version 8.4 or newer. Report by Terry Dontje.
Re: [patch libgfortran] path to libquadmath
* John David Anglin wrote on Fri, Dec 10, 2010 at 05:58:26PM CET: The attached change to ltmain.sh fixes the above problem on on 32-bit hppa*-*hpux*. Tested on hppa2.0w-hp-hpux11.11 and hppa64-hp-hpux11.11. Would you please apply if ok to libtool, gcc and sourceware? Sorry for the long delay. I'm applying this to Libtool. I don't have a good test case yet, unfortunately, but I do think that it is the right change to make within the current set of semantics Libtool provides. We need some facilities in the Libtool testsuite to generate binary incompatible libraries more or less portably. As to GCC, that's for another mail ... Cheers, Ralf 2010-12-10 John David Anglin dave.ang...@nrc-cnrc.gc.ca * ltmain.sh (relink): Use absolute path when hardcoding with -L. 2011-01-09 John David Anglin dave.ang...@nrc-cnrc.gc.ca (tiny change) Fix relink mode to use absolute path if hardcode_minus_L. * libltdl/config/ltmain.m4sh (func_mode_link): Use absolute path when hardcoding with -L. diff --git a/libltdl/config/ltmain.m4sh b/libltdl/config/ltmain.m4sh index d9e1cd2..7baa6aa 100644 --- a/libltdl/config/ltmain.m4sh +++ b/libltdl/config/ltmain.m4sh @@ -6050,7 +6050,7 @@ func_mode_link () test $hardcode_direct_absolute = no; then add=$dir/$linklib elif test $hardcode_minus_L = yes; then - add_dir=-L$dir + add_dir=-L$absdir # Try looking first in the location we're being installed to. if test -n $inst_prefix_dir; then case $libdir in
Re: func_convert_file_cygwin_to_w32 woes
Hi Peter, * Peter Rosin wrote on Fri, Jan 07, 2011 at 09:35:08PM CET: Below is a patch that changes all old_archive_cmds assignments. That patch looks actually fairly safe to me; still, at least some testing on at least one relevant system would be nice. Feel free to push when you feel comfortable with it. I think a NEWS item for this might be in order; codesearch didn't reveal any packages using $old_archive_cmds in their configure scripts but I didn't bother to check more than half a dozen result pages or so, and if there are any, they might break because of not having set $tool_oldlib. Something like this maybe? Static library creation copes better with output file names that require w32 path translation; the default value for old_archive_cmds has been changed accordingly. Hmm, I realize that due to the earlier ranlib change this was true before already. Thanks, Ralf From: Peter Rosin p...@lysator.liu.se Date: Fri, 7 Jan 2011 21:22:10 +0100 Subject: [PATCH] Convert to toolchain format when invoking the archiver.
Re: func_convert_file_cygwin_to_w32 woes
Hi Charles, * Charles Wilson wrote on Fri, Jan 07, 2011 at 05:55:50PM CET: On 1/7/2011 3:02 AM, Peter Rosin wrote: Den 2011-01-06 21:29 skrev Ralf Wildenhues: * Peter Rosin wrote on Tue, Jan 04, 2011 at 05:44:58PM CET: Before I tie up the lose ends with this patch, I wonder if Ralf (or someone else) could tell me if I should also fix the other assignments of old_archive_cmds -- such as in the below snippet -- or is that completely irrelevant? I wouldn't change them without being sure that the changes are necessary. Well, they are necessary, but in cases which are, errhm, convoluted... Such as: win32-hosted cross-tools (I mean native win32 here, not dependent on Cygwin or MSYS) for targeting irix (or whatever) and running them from Cygwin (or Wine) instead of MSYS. I think I'll skip the extra changes, as someone doing the above needs a clue-bat anyway. Err...that's not really uncommon. [...] OK, but I still would accept those kinds of changes to code for little-used system only when someone has actually *tested* them in that particular situation, and found the code to be erroneous prior patch and working afterwards. We've been pestering other users to try out our patches for a good reason, I don't see why this should be treated less strict. Thanks, Ralf
Re: func_convert_file_cygwin_to_w32 woes
[ dropping libtool@ ] Hi Peter, thanks for working on this! * Peter Rosin wrote on Tue, Jan 04, 2011 at 05:44:58PM CET: Subject: [PATCH] Convert ranlib argument to toolchain format. --- a/libltdl/config/ltmain.m4sh +++ b/libltdl/config/ltmain.m4sh @@ -2412,6 +2412,8 @@ func_mode_install () # Set up the ranlib parameters. oldlib=$destdir/$name + func_to_tool_file $oldlib func_convert_file_msys_to_w32 + tool_oldlib=$func_to_tool_file_result Why does the $old_striplib command a few lines below this one not need to use $tool_oldlib? Dan, can you try 'make install-strip'? func_show_eval $install_prog \$file \$oldlib 'exit $?' @@ -8370,6 +8372,8 @@ EOF esac done fi + func_to_tool_file $oldlib func_convert_file_msys_to_w32 + tool_oldlib=$func_to_tool_file_result eval cmds=\$old_archive_cmds\ func_len $cmds [...] * Peter Rosin wrote on Wed, Jan 05, 2011 at 11:06:09AM CET: Den 2011-01-05 05:30 skrev Dan McMahill: On 1/4/2011 11:44 AM, Peter Rosin wrote: Ok, I found a couple of minutes to look at this. Can you check if this patch helps? (It still needs a ChangeLog etc...) The patch is OK with me if you fix the missing bits, and address the above. Before I tie up the lose ends with this patch, I wonder if Ralf (or someone else) could tell me if I should also fix the other assignments of old_archive_cmds -- such as in the below snippet -- or is that completely irrelevant? I wouldn't change them without being sure that the changes are necessary. Thanks, Ralf
Re: Libtool library used but `LIBTOOL' is undefined??
Hello, * kknd1233 wrote on Wed, Jan 05, 2011 at 12:14:20AM CET: And then when I run the command 'autoreconf --install', it said an error message like lib/Makefile.am:1: Libtool library used but `LIBTOOL' is undefined lib/Makefile.am:1: The usual way to define `LIBTOOL' is to add `AC_PROG_LIBTOOL' lib/Makefile.am:1: to `configure.ac' and run `aclocal' and `autoconf' again. lib/Makefile.am:1: If `AC_PROG_LIBTOOL' is in `configure.ac', make sure lib/Makefile.am:1: its definition is in aclocal's search path. (LT_INIT is a synonym of AC_PROG_LIBTOOL.) I presume your Automake and your Libtool are not installed below the same prefix, thus aclocal doesn't find the Libtool macros to install. One solution is to install both below the same prefix; or write a dirlist file in $automake_prefix/share/aclocal with a line containing $libtool_prefix/share/aclocal. Or the error has a different reason, in which case please post output of autoreconf --verbose --install Hope that helps. Cheers, Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool
Happy New Year!
All the best to you and GNU for the new year!
I'm pushing the patch below and rotating ChangeLog files, after running
the test suite. This time I remembered to also bump libtool.texi right
away.
Thanks,
Ralf
Bump copyright years.
* ChangeLog.2010: New, rotated from ...
* ChangeLog: ... here.
* Makefile.am (EXTRA_DIST): Add ChangeLog.2010.
* NEWS, libltdl/config/ltmain.m4sh: Bump copyright years.
* libltdl/m4/libtool.m4 (_LT_COPYING, LT_OUTPUT): Likewise.
* libtoolize.m4sh: Likewise.
* doc/libtool.texi: Likewise.
diff --git a/Makefile.am b/Makefile.am
index 4be353c..f0590a8 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -1,7 +1,7 @@
## Makefile.am -- Process this file with automake to produce Makefile.in
##
-## Copyright (C) 2003, 2004, 2005, 2006, 2007, 2008, 2009, 2010 Free
-## Software Foundation, Inc.
+## Copyright (C) 2003, 2004, 2005, 2006, 2007, 2008, 2009, 2010, 2011
+## Free Software Foundation, Inc.
## Written by Gary V. Vaughan, 2003
##
## This file is part of GNU Libtool.
@@ -71,7 +71,7 @@ EXTRA_DIST += bootstrap $(srcdir)/libtoolize.in
$(auxdir)/ltmain.m4sh \
ChangeLog.1999 ChangeLog.2000 ChangeLog.2001 \
ChangeLog.2002 ChangeLog.2003 ChangeLog.2004 \
ChangeLog.2005 ChangeLog.2006 ChangeLog.2007 \
- ChangeLog.2008 ChangeLog.2009
+ ChangeLog.2008 ChangeLog.2009 ChangeLog.2010
CLEANFILES += libtool libtoolize libtoolize.tmp \
$(auxdir)/ltmain.tmp $(m4dir)/ltversion.tmp
diff --git a/NEWS b/NEWS
index 96c9723..39eb771 100644
--- a/NEWS
+++ b/NEWS
@@ -1,6 +1,6 @@
NEWS - list of user-visible changes between releases of GNU Libtool
-New in 2.4.2 2010-12-??: git version 2.4.1a, Libtool team:
+New in 2.4.2 2011-??-??: git version 2.4.1a, Libtool team:
* New features:
diff --git a/doc/libtool.texi b/doc/libtool.texi
index 4823ab8..727a03d 100644
--- a/doc/libtool.texi
+++ b/doc/libtool.texi
@@ -26,7 +26,7 @@
@ifnottex
This file documents GNU Libtool @value{VERSION}
-Copyright (C) 1996-2010 Free Software Foundation, Inc.
+Copyright (C) 1996-2011 Free Software Foundation, Inc.
Permission is granted to copy, distribute and/or modify this document
under the terms of the GNU Free Documentation License, Version 1.3
@@ -53,7 +53,7 @@ identical to this one except for the removal of this paragraph
@page
@vskip 0pt plus 1filll
-Copyright @copyright{} 2010 Free Software Foundation, Inc.
+Copyright @copyright{} 2011 Free Software Foundation, Inc.
Permission is granted to copy, distribute and/or modify this document
under the terms of the GNU Free Documentation License, Version 1.3
@@ -7183,7 +7183,7 @@ trick$ chmod +x libtool
trick$ libtool --version
ltmain.sh (GNU @@PACKAGETIMESTAMP@@) @@VERSION@@
-Copyright (C) 2010 Free Software Foundation, Inc.
+Copyright (C) 2011 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
trick$
diff --git a/libltdl/config/ltmain.m4sh b/libltdl/config/ltmain.m4sh
index 8c37f88..336d97b 100644
--- a/libltdl/config/ltmain.m4sh
+++ b/libltdl/config/ltmain.m4sh
@@ -4,7 +4,7 @@ m4_divert_push([SCRIPT])
# Written by Gordon Matzigkeit g...@gnu.ai.mit.edu, 1996
# Copyright (C) 1996, 1997, 1998, 1999, 2000, 2001, 2003, 2004, 2005, 2006,
-# 2007, 2008, 2009, 2010 Free Software Foundation, Inc.
+# 2007, 2008, 2009, 2010, 2011 Free Software Foundation, Inc.
# This is free software; see the source for copying conditions. There is NO
# warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
diff --git a/libltdl/m4/libtool.m4 b/libltdl/m4/libtool.m4
index 8e88917..4239395 100644
--- a/libltdl/m4/libtool.m4
+++ b/libltdl/m4/libtool.m4
@@ -1,8 +1,8 @@
# libtool.m4 - Configure libtool for the host system. -*-Autoconf-*-
#
# Copyright (C) 1996, 1997, 1998, 1999, 2000, 2001, 2003, 2004, 2005,
-# 2006, 2007, 2008, 2009, 2010 Free Software Foundation,
-# Inc.
+# 2006, 2007, 2008, 2009, 2010, 2011 Free Software
+# Foundation, Inc.
# Written by Gordon Matzigkeit, 1996
#
# This file is free software; the Free Software Foundation gives
@@ -11,8 +11,8 @@
m4_define([_LT_COPYING], [dnl
# Copyright (C) 1996, 1997, 1998, 1999, 2000, 2001, 2003, 2004, 2005,
-# 2006, 2007, 2008, 2009, 2010 Free Software Foundation,
-# Inc.
+# 2006, 2007, 2008, 2009, 2010, 2011 Free Software
+# Foundation, Inc.
# Written by Gordon Matzigkeit, 1996
#
# This file is part of GNU Libtool.
@@ -639,7 +639,7 @@ m4_ifset([AC_PACKAGE_NAME], [AC_PACKAGE_NAME
])config.lt[]dnl
m4_ifset([AC_PACKAGE_VERSION], [ AC_PACKAGE_VERSION])
configured by $[0], generated by m4_PACKAGE_STRING.
-Copyright (C) 2010 Free Software Foundation, Inc.
Re: func_convert_file_cygwin_to_w32 woes
Hi Dan,
* Dan McMahill wrote on Sat, Jan 01, 2011 at 04:53:25AM CET:
I am trying to build a program under cygwin but using the mingw tool
chain in a fake cross build way. In my configure environment, I have:
export lt_cv_to_tool_file_cmd=func_convert_file_cygwin_to_w32
as suggested by the libtool manual. I'm using libtool 2.4.
Everything goes smoothly until install time when libtool calls ranlib
(the mingw one) on an absolute path and of course the cygwin absolute
path doesn't make sense to the mingw ranlib. I thought that's what the
func_convert... bit was for.
Please copy and paste 'libtool --mode={link,relink,install}' commands
for the libraries and programs involved. We may provide better help
then.
Cheers,
Ralf
___
http://lists.gnu.org/mailman/listinfo/libtool
Re: How does one specify linking to 64 bit libraries when there is a choice?
* Bruce Korb wrote on Mon, Dec 20, 2010 at 09:37:58PM CET: On 12/20/10 11:20, Ralf Wildenhues wrote: One crucial part is that libtool gets confused whenever it has directories with the wrong ABI in the search path (unlike ld or ld.so, both are in some cases smart enough to skip wrong ABI), which means that either no instance of the build system machineries may introduce such paths, or libtool needs to get smarter to ignore wrong ABI dirs. The other crucial part is that libtool doesn't get the sys_lib_search_path_spec and sys_lib_dlsearch_path_spec settings right on several distros, introducing such wrong directories itself (not to speak of cross setups). There have been several proposed patches to address this, e.g. http://thread.gmane.org/gmane.comp.gnu.libtool.patches/10625 http://thread.gmane.org/gmane.comp.gnu.libtool.patches/9931 but I have yet to see one that solves it. At least with current Libtool you can override wrong settings with the lt_cv_sys_lib_search_path_spec and lt_cv_sys_lib_dlsearch_path_spec cache variables. Addressing things in reverse order: 1. lt_cv_sys_lib... It is true that authors of packages need to be more knowledgeable than the hapless builder, still they should not have to fiddle with undocumented internals; and cached variable values seem like grody internals to me. I fully agree that such knowledge /should/ not be required. It's a bug that libtool doesn't get the right setting by default. 2. Way back at the beginning, with a default installation of RHEL for amd-64/x86-64, these commands fail: $ cd $guile_build_dir $ $guile_src/configure make sudo make install $ cd $autogen_build_dir $ $autogen_src/configure make sudo make install and it fails because `guile-config link` produces output that libtool interprets and then passes, as a full path name, a library listed as ``-lXXX'' in the guile-config output. The full path, of course, is to a 32 bit shared obj in a 64 bit link command. Oops. So this means that if ld could have identified a 32 bit shared obj and gone on to look in another directory, all would have been well. Instead, ld saw a full path and tried to do what it was told, but said, no, I won't do that. 3. CF: One crucial part is that libtool gets confused whenever it has directories with the wrong ABI in the search path (unlike ld or ld.so, both are in some cases smart enough to skip wrong ABI), So DO NOT REPLACE ``-lgmp'' with ``/usr/local/lib/libgmp.so''!!! libtool did this and triggered the whole thread. Again: the replacement of -lgmp with /usr/local/lib/libgmp.so might be the thing that makes the failure visible, but it is not the underlying cause, and trying to avoid the replacement is like trying to make someone go away by closing your eyes. The error happened earlier: at the time /usr/local/lib was introduced into the libtool search path. The replacement of -lfoo with /abs/path/to/libfoo.so on some systems, notably GNU/Linux, is very helpful in being able to reliably link against uninstalled libraries even in the presence of -L/some/inst/path early on the link command line. Crying against this will not fix the issue (as there are other places where libtool will get things wrong for you even if you inhibit this, once it looks in the wrong directories). See: http://lists.gnu.org/archive/html/libtool/2010-12/msg00041.html Just a note: if a distro puts 64 bit SOs in /usr/lib64, then it is reasonable to put add-on 64 bit SOs into /usr/local/lib64. In fact, I would consider it peculiar to put 'em into /usr/local/lib. Sure, that's what you would expect. What can libtool expect though? I don't think /usr/local can be treated as necessarily having the same policy as /usr has, one coming from the distro and the other containing all kinds of non-adapted (even non-GNU standards using) junk. The difference should just be $prefix (i.e. /usr vs. /usr/local). If my sloppiness regarding distinguishing /usr/lib from /usr/local/lib caused any confusion, my apologies. The final lib directory name should be consistent. I fail to see how it would be possible to ingrain this rule into all of our users, overnight. Cheers, Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: How does one specify linking to 64 bit libraries when there is a choice?
* Bruce Korb wrote on Mon, Dec 20, 2010 at 03:09:48PM CET:
How much understanding of the machinery should be expected
of the hapless project builder?
I've skimmed most of the conversation in this thread now.
The crucial part, I think, is *not* the --libdir setting. Distros
usually get that consistent between their packages, and users should not
be using any of /usr/lib{,32,64} but rather something below /usr/local.
One crucial part is that libtool gets confused whenever it has
directories with the wrong ABI in the search path (unlike ld or ld.so,
both are in some cases smart enough to skip wrong ABI), which means that
either no instance of the build system machineries may introduce such
paths, or libtool needs to get smarter to ignore wrong ABI dirs.
The other crucial part is that libtool doesn't get the
sys_lib_search_path_spec and sys_lib_dlsearch_path_spec settings
right on several distros, introducing such wrong directories itself (not
to speak of cross setups). There have been several proposed patches to
address this, e.g.
http://thread.gmane.org/gmane.comp.gnu.libtool.patches/10625
http://thread.gmane.org/gmane.comp.gnu.libtool.patches/9931
but I have yet to see one that solves it.
Thanks,
Ralf
___
http://lists.gnu.org/mailman/listinfo/libtool
Re: How does one specify linking to 64 bit libraries when there is a choice?
* Ralf Wildenhues wrote on Mon, Dec 20, 2010 at 08:20:25PM CET: The other crucial part is that libtool doesn't get the sys_lib_search_path_spec and sys_lib_dlsearch_path_spec settings right on several distros, introducing such wrong directories itself (not to speak of cross setups). There have been several proposed patches to address this, e.g. http://thread.gmane.org/gmane.comp.gnu.libtool.patches/10625 http://thread.gmane.org/gmane.comp.gnu.libtool.patches/9931 but I have yet to see one that solves it. ESENDTOOSOON, sorry. At least with current Libtool you can override wrong settings with the lt_cv_sys_lib_search_path_spec and lt_cv_sys_lib_dlsearch_path_spec cache variables. ___ http://lists.gnu.org/mailman/listinfo/libtool
[SCM] GNU Libtool branch, master, updated. v2.4-37-gb78075b
This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project GNU Libtool. The branch, master has been updated via b78075b8ae59ff68f6f9ece21be7c5c13fceabee (commit) via 7aabd35c4c78df9c94528c02eae29397bab65987 (commit) via e80566abb3ee6757ff6da59d65a874b3a5f706a1 (commit) via 39ba8c55de025805c69d46e76f1a352658e01382 (commit) from 92eb89aace9fd41e43eee33f5c392adf1bcf8963 (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log - commit b78075b8ae59ff68f6f9ece21be7c5c13fceabee Author: Ian Lance Taylor i...@google.com Date: Tue Oct 12 14:38:49 2010 -0700 Add Go support. * libltdl/m4/libtool.m4 (LT_LANG): Add Go. (AC_PROG_GO): Provide. (_LT_SYS_HIDDEN_LIBDEPS): Add Go case. (_LT_LANG_GO_CONFIG): Define. (LT_PROG_GO): Define. (AC_PROG_GO): Define if not defined. * libltdl/config/ltmain.m4sh: Match *.go. * doc/libtool.texi (LT_INIT): Mention Go. (Tags): Mention Go. * configure.ac: Enable Go. * NEWS: Update. Signed-off-by: Ralf Wildenhues ralf.wildenh...@gmx.de commit 7aabd35c4c78df9c94528c02eae29397bab65987 Author: Brice De Bruyne bric...@gmail.com Date: Mon Dec 20 04:16:12 2010 +0100 Also turn off -fuse-linker-plugin for postdep_objects computation. * libltdl/m4/libtool.m4 (_LT_SYS_HIDDEN_LIBDEPS): Add -fno-use-linker-plugin to temporary compile flags if necessary, to fix C++ postdep_objects setting with -flto -fuse-linker-plugin. * NEWS, THANKS: Update. Signed-off-by: Ralf Wildenhues ralf.wildenh...@gmx.de commit e80566abb3ee6757ff6da59d65a874b3a5f706a1 Author: KO Myung-Hun k...@chollian.net Date: Mon Dec 20 04:10:19 2010 +0100 Set command line length limit for OS/2. * libltdl/m4/libtool.m4 (LT_CMD_MAX_LEN) [os2] lt_cv_sys_max_cmd_len: Set to 8192 to avoid long test. Signed-off-by: Ralf Wildenhues ralf.wildenh...@gmx.de commit 39ba8c55de025805c69d46e76f1a352658e01382 Author: Ralf Wildenhues ralf.wildenh...@gmx.de Date: Fri Dec 17 20:30:53 2010 +0100 Fix PIC flags with mpif77 using ifort on GNU/Linux. * libltdl/m4/libtool.m4 (_LT_COMPILER_PIC) [linux]: Match Intel compiler also using $CC -V output, to avoid false negatives with compiler drivers like mpif77. Report by Christian Rössel. Signed-off-by: Ralf Wildenhues ralf.wildenh...@gmx.de --- Summary of changes: ChangeLog | 37 + NEWS |4 ++ THANKS |1 + configure.ac |1 + doc/libtool.texi |3 +- libltdl/config/ltmain.m4sh |2 +- libltdl/m4/libtool.m4 | 124 tests/suffix.test |2 +- 8 files changed, 171 insertions(+), 3 deletions(-) diff --git a/ChangeLog b/ChangeLog index cbb0262..4880098 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,3 +1,40 @@ +2010-12-20 Ian Lance Taylor i...@google.com + + * libltdl/m4/libtool.m4 (LT_LANG): Add Go. + (AC_PROG_GO): Provide. + (_LT_SYS_HIDDEN_LIBDEPS): Add Go case. + (_LT_LANG_GO_CONFIG): Define. + (LT_PROG_GO): Define. + (AC_PROG_GO): Define if not defined. + * libltdl/config/ltmain.m4sh: Match *.go. + * doc/libtool.texi (LT_INIT): Mention Go. + (Tags): Mention Go. + * configure.ac: Enable Go. + * NEWS: Update. + +2010-12-20 Brice De Bruyne bric...@gmail.com (tiny change) + + Also turn off -fuse-linker-plugin for postdep_objects computation. + * libltdl/m4/libtool.m4 (_LT_SYS_HIDDEN_LIBDEPS): Add + -fno-use-linker-plugin to temporary compile flags if necessary, + to fix C++ postdep_objects setting with -flto + -fuse-linker-plugin. + * NEWS, THANKS: Update. + +2010-12-20 KO Myung-Hun k...@chollian.net (tiny change) + + Set command line length limit for OS/2. + * libltdl/m4/libtool.m4 (LT_CMD_MAX_LEN) [os2] + lt_cv_sys_max_cmd_len: Set to 8192 to avoid long test. + +2010-12-20 Ralf Wildenhues ralf.wildenh...@gmx.de + + Fix PIC flags with mpif77 using ifort on GNU/Linux. + * libltdl/m4/libtool.m4 (_LT_COMPILER_PIC) [linux]: + Match Intel compiler also using $CC -V output, to avoid false + negatives with compiler drivers like mpif77. + Report by Christian Rössel. + 2010-12-16 Ralf Wildenhues ralf.wildenh...@gmx.de Fix PIC flags with MPI wrappers using Portland on GNU/Linux. diff --git a/NEWS b/NEWS index 0aeca57..96c9723 100644 --- a/NEWS +++ b/NEWS @@ -8,6 +8,8 @@ New in 2.4.2 2010-12-??: git version 2.4.1a, Libtool team
Re: ping: [PATCH libtool] hardcoded path to dependent shared libraries on 32-bit hpux (libquadmath)
* John David Anglin wrote on Sun, Dec 19, 2010 at 05:04:36PM CET: Ping. On Fri, 10 Dec 2010, John David Anglin wrote: The attached change to ltmain.sh fixes the above problem on on 32-bit hppa*-*hpux*. Tested on hppa2.0w-hp-hpux11.11 and hppa64-hp-hpux11.11. Would you please apply if ok to libtool, gcc and sourceware? Sorry for the delay, I really would like to test the patch on the Libtool tree on a couple of systems, and write a Libtool testsuite addition for it, so we don't regress in the future. I hope to get to it before the end of the calendar year. If you'd like to help, you can download the Libtool source tree (git or nightly tarball from the website), apply the patch, run 'make -k check' and send the log files the output tells to send, on the HP systems you have available for testing. Thanks, Ralf 2010-12-10 John David Anglin dave.ang...@nrc-cnrc.gc.ca * ltmain.sh (relink): Use absolute path when hardcoding with -L. Index: ltmain.sh === --- ltmain.sh (revision 167668) +++ ltmain.sh (working copy) @@ -5928,7 +5928,7 @@ test $hardcode_direct_absolute = no; then add=$dir/$linklib elif test $hardcode_minus_L = yes; then - add_dir=-L$dir + add_dir=-L$absdir # Try looking first in the location we're being installed to. if test -n $inst_prefix_dir; then case $libdir in
Re: PIC flags not found for mpif77(ifort)
* Christian Rössel wrote on Fri, Dec 17, 2010 at 01:25:45PM CET: On 12/16/2010 09:54 PM, Ralf Wildenhues wrote: And now I wonder why you are having problems with 'mpif77 -f77=ifort' because either it claims to be GNU (and then should accept -fPIC) or it doesn't claim to be GNU (and then my proposed patch, including the fix you spotted to double-quote the [CF]) should have worked. Can you show the config.log for the F77=mpif77 case that fails to detect the PIC flag? Thanks. I checked again and you are right, with the fixed patch it works out of the box. ifort 11.1 does not claim to be a GNU compiler (whereas icc and icpc do). I somehow mixed up the output of the different compilers as we use them all in our project. Sorry for the confusion. Ah, cool. I'm pushing the other patch then too. The setting of $archive_cmds still needs fixes for both Intel and PGI compilers too, and I think we should strive to remove duplicate entries for compilers: I'll post a followup cleanup patch. Thanks, Ralf
Re: wrong postdep_objects for CXX when using -flto -fuse-linker-plugin
* Ralf Wildenhues wrote on Sun, Dec 05, 2010 at 09:47:54PM CET: * Brice De Bruyne wrote on Sat, Dec 04, 2010 at 04:17:25PM CET: It seems the postdep_objects are set wrong when CXXFLAGS contains -fuse-linker-plugin. CFLAGS don't matter it seems... Following patch to libltdl/m4/libtool.m4 and then running ./bootstrap fixes this problem: CXXFLAGS shouldn't matter here, if it does then that is a bug. [...] I'm pushing the following in your name, and adding you to THANKS. Please report back if this patch is not sufficient. Thanks, Ralf 2010-12-20 Brice De Bruyne bric...@... (tiny change) Also turn off -fuse-linker-plugin for postdep_objects computation. * libltdl/m4/libtool.m4 (_LT_SYS_HIDDEN_LIBDEPS): Add -fno-use-linker-plugin to temporary compile flags if necessary, to fix C++ postdep_objects setting with -flto -fuse-linker-plugin. * NEWS, THANKS: Update. diff --git a/NEWS b/NEWS index 0aeca57..8d6965d 100644 --- a/NEWS +++ b/NEWS @@ -15,6 +15,8 @@ New in 2.4.2 2010-12-??: git version 2.4.1a, Libtool team: - The bug that leaked developer tool paths into the release tarballs from ./bootstrap is fixed. - Improved support for the Cuda Compiler Driver (nvcc) on Darwin. + - For GCC LTO support, the -fuse-linker-plugin switch is now also removed +when computing compiler postdeps. * Important incompatible changes: diff --git a/libltdl/m4/libtool.m4 b/libltdl/m4/libtool.m4 index 5e716b2..21b12fd 100644 --- a/libltdl/m4/libtool.m4 +++ b/libltdl/m4/libtool.m4 @@ -6922,6 +6922,7 @@ _lt_libdeps_save_CFLAGS=$CFLAGS case $CC $CFLAGS in #( *\ -flto*\ *) CFLAGS=$CFLAGS -fno-lto ;; *\ -fwhopr*\ *) CFLAGS=$CFLAGS -fno-whopr ;; +*\ -fuse-linker-plugin*\ *) CFLAGS=$CFLAGS -fno-use-linker-plugin ;; esac dnl Parse the compiler output and extract the necessary
Re: Oracle Solaris Studio 12.2 compiler incompatibility with libtool
* Terry Dontje wrote on Mon, Dec 06, 2010 at 06:58:28PM CET: On 12/05/2010 04:25 PM, Ralf Wildenhues wrote: * Ralf Wildenhues wrote on Thu, Nov 18, 2010 at 09:23:17PM CET: * Terry Dontje wrote on Wed, Nov 17, 2010 at 01:00:26PM CET: I've discussed this internally and yes we would like Ceres to be supported. Oh, no problem. Presumably that means you have some way to test the proposed patch then with all the interesting compilers. That would be very nice. :-) Erm, I haven't pushed this patch yet, assuming that some test feedback would be better than none at all. Any chance you could try it out sometime? Ok, Ethan and I just talked on the phone. He should be able to test this soon and tell you the results. Ping! 2010-11-18 Ralf Wildenhues... Fix $wl setting for Solaris Studio 12.2 f90 on GNU/Linux. * libltdl/m4/libtool.m4 (_LT_COMPILER_PIC) [linux] lt_prog_compiler_wl: Set to '-Qoption ld ' if we detect Sun Fortran version 8.4 or newer. Report by Terry Dontje. --- a/libltdl/m4/libtool.m4 +++ b/libltdl/m4/libtool.m4 @@ -4324,12 +4324,17 @@ m4_if([$1], [CXX], [ ;; *) case `$CC -V 21 | sed 5q` in - *Sun\ F* | *Sun*Fortran*) + *Sun\ Ceres\ Fortran* | *Sun*Fortran*\ [[1-7]].* | *Sun*Fortran*\ 8.[[0-3]]*) # Sun Fortran 8.3 passes all unrecognized flags to the linker _LT_TAGVAR(lt_prog_compiler_pic, $1)='-KPIC' _LT_TAGVAR(lt_prog_compiler_static, $1)='-Bstatic' _LT_TAGVAR(lt_prog_compiler_wl, $1)='' ;; + *Sun\ F* | *Sun*Fortran*) + _LT_TAGVAR(lt_prog_compiler_pic, $1)='-KPIC' + _LT_TAGVAR(lt_prog_compiler_static, $1)='-Bstatic' + _LT_TAGVAR(lt_prog_compiler_wl, $1)='-Qoption ld ' + ;; *Sun\ C*) # Sun C 5.9 _LT_TAGVAR(lt_prog_compiler_pic, $1)='-KPIC'
Re: PATCH RFA: Add Go support
Hello Ian,
I have pushed your patch to the Libtool git tree now, with GCCGO
replaced by GOC and some whitespace changes, and your two patches
squashed in one, as below. Sorry for the delay.
Thanks,
Ralf
2010-12-20 Ian Lance Taylor i...@google.com
* libltdl/m4/libtool.m4 (LT_LANG): Add Go.
(AC_PROG_GO): Provide.
(_LT_SYS_HIDDEN_LIBDEPS): Add Go case.
(_LT_LANG_GO_CONFIG): Define.
(LT_PROG_GO): Define.
(AC_PROG_GO): Define if not defined.
* libltdl/config/ltmain.m4sh: Match *.go.
* doc/libtool.texi (LT_INIT): Mention Go.
(Tags): Mention Go.
* configure.ac: Enable Go.
* NEWS: Update.
diff --git a/NEWS b/NEWS
index 8d6965d..96c9723 100644
--- a/NEWS
+++ b/NEWS
@@ -8,6 +8,8 @@ New in 2.4.2 2010-12-??: git version 2.4.1a, Libtool team:
package names. This can be used to build some static libraries with PIC
objects while building others with non-PIC objects.
+ - Initial support for Go, using the gccgo compiler.
+
* Bug fixes:
- The generic approximation of the command line length limit (when getconf is
diff --git a/configure.ac b/configure.ac
index 63ee8bf..0bad772 100644
--- a/configure.ac
+++ b/configure.ac
@@ -196,6 +196,7 @@ _LTDL_SETUP
LT_LANG(C++)
LT_LANG(Fortran 77)
LT_LANG(Fortran)
+LT_LANG(Go)
LT_LANG(Java)
LT_LANG(Windows Resource)
diff --git a/doc/libtool.texi b/doc/libtool.texi
index 04c5507..4823ab8 100644
--- a/doc/libtool.texi
+++ b/doc/libtool.texi
@@ -2250,7 +2250,7 @@ specifying @option{--with-pic} to @command{configure}.
@defmac LT_LANG (@var{language})
Enable @command{libtool} support for the language given if it
has not yet already been enabled. Languages accepted are ``C++'',
-``Fortran 77'', ``Java'' and ``Windows Resource''.
+``Fortran 77'', ``Java'', ``Go'', and ``Windows Resource''.
If Autoconf language support macros such as @code{AC_PROG_CXX} are
used in your @file{configure.ac}, Libtool language support will automatically
@@ -2849,6 +2849,7 @@ correspondence between language names and tags names.
@item Java @tab GCJ
@item Fortran 77 @tab F77
@item Fortran @tab FC
+...@item Go @tab GO
@item Windows Resource @tab RC
@end multitable
diff --git a/libltdl/config/ltmain.m4sh b/libltdl/config/ltmain.m4sh
index aff8a1c..8c37f88 100644
--- a/libltdl/config/ltmain.m4sh
+++ b/libltdl/config/ltmain.m4sh
@@ -1270,7 +1270,7 @@ func_mode_compile ()
*.[cCFSifmso] | \
*.ada | *.adb | *.ads | *.asm | \
*.c++ | *.cc | *.ii | *.class | *.cpp | *.cxx | \
-*.[fF][09]? | *.for | *.java | *.obj | *.sx | *.cu | *.cup)
+*.[fF][09]? | *.for | *.java | *.go | *.obj | *.sx | *.cu | *.cup)
func_xform $libobj
libobj=$func_xform_result
;;
diff --git a/libltdl/m4/libtool.m4 b/libltdl/m4/libtool.m4
index 21b12fd..8e88917 100644
--- a/libltdl/m4/libtool.m4
+++ b/libltdl/m4/libtool.m4
@@ -803,6 +803,7 @@ AC_DEFUN([LT_LANG],
m4_case([$1],
[C], [_LT_LANG(C)],
[C++], [_LT_LANG(CXX)],
+ [Go],[_LT_LANG(GO)],
[Java], [_LT_LANG(GCJ)],
[Fortran 77],[_LT_LANG(F77)],
[Fortran], [_LT_LANG(FC)],
@@ -824,6 +825,31 @@ m4_defun([_LT_LANG],
])# _LT_LANG
+m4_ifndef([AC_PROG_GO], [
+
+# NOTE: This macro has been submitted for inclusion into #
+# GNU Autoconf as AC_PROG_GO. When it is available in#
+# a released version of Autoconf we should remove this#
+# macro and use it instead. #
+
+m4_defun([AC_PROG_GO],
+[AC_LANG_PUSH(Go)dnl
+AC_ARG_VAR([GOC], [Go compiler command])dnl
+AC_ARG_VAR([GOFLAGS], [Go compiler flags])dnl
+_AC_ARG_VAR_LDFLAGS()dnl
+AC_CHECK_TOOL(GOC, gccgo)
+if test -z $GOC; then
+ if test -n $ac_tool_prefix; then
+AC_CHECK_PROG(GOC, [${ac_tool_prefix}gccgo], [${ac_tool_prefix}gccgo])
+ fi
+fi
+if test -z $GOC; then
+ AC_CHECK_PROG(GOC, gccgo, gccgo, false)
+fi
+])#m4_defun
+])#m4_ifndef
+
+
# _LT_LANG_DEFAULT_CONFIG
# ---
m4_defun([_LT_LANG_DEFAULT_CONFIG],
@@ -854,6 +880,10 @@ AC_PROVIDE_IFELSE([AC_PROG_GCJ],
m4_ifdef([LT_PROG_GCJ],
[m4_define([LT_PROG_GCJ], defn([LT_PROG_GCJ])[LT_LANG(GCJ)])])])])])
+AC_PROVIDE_IFELSE([AC_PROG_GO],
+ [LT_LANG(GO)],
+ [m4_define([AC_PROG_GO], defn([AC_PROG_GO])[LT_LANG(GO)])])
+
AC_PROVIDE_IFELSE([LT_PROG_RC],
[LT_LANG(RC)],
[m4_define([LT_PROG_RC], defn([LT_PROG_RC])[LT_LANG(RC)])])
@@ -6916,6 +6946,11 @@ public class foo {
}
};
_LT_EOF
+], [$1], [GO], [cat conftest.$ac_ext _LT_EOF
+package foo
+func foo() {
+}
+_LT_EOF
])
_lt_libdeps_save_CFLAGS=$CFLAGS
@@ -7437,6 +7472,77 @@ CFLAGS=$lt_save_CFLAGS
])# _LT_LANG_GCJ_CONFIG
+# _LT_LANG_GO_CONFIG([TAG])
+# --
+# Ensure that the configuration
Re: OS/2: command-line length limit
* KO Myung-Hun wrote on Sun, Dec 19, 2010 at 03:11:08AM CET: Ok. Please set lt_cv_sys_max_cmd_len to 8192 instead of -1. I've just realized that I can override it when configuring. Good. I'm pushing this in your name, reordering the case entry to be alphabetical in the list. I hope to get to the rest of your patch soon. Thanks, Ralf 2010-12-20 KO Myung-Hun k...@... (tiny change) Set command line length limit for OS/2. * libltdl/m4/libtool.m4 (LT_CMD_MAX_LEN) [os2] lt_cv_sys_max_cmd_len: Set to 8192 to avoid long test. diff --git a/libltdl/m4/libtool.m4 b/libltdl/m4/libtool.m4 index a1df87d..5e716b2 100644 --- a/libltdl/m4/libtool.m4 +++ b/libltdl/m4/libtool.m4 @@ -1604,6 +1604,11 @@ AC_CACHE_VAL([lt_cv_sys_max_cmd_len], [dnl lt_cv_sys_max_cmd_len=196608 ;; + os2*) +# The test takes a long time on OS/2. +lt_cv_sys_max_cmd_len=8192 +;; + osf*) # Dr. Hans Ekkehard Plesser reports seeing a kernel panic running configure # due to this test when exec_disable_arg_limit is 1 on Tru64. It is not
Re: OS/2: command-line length limit
* KO Myung-Hun wrote on Fri, Dec 17, 2010 at 01:20:38PM CET: Ralf Wildenhues wrote: * KO Myung-Hun wrote on Sun, Nov 28, 2010 at 07:20:32AM CET: --- libltdl/m4/libtool.m4.org 2010-09-22 17:41:18.0 +0900 +++ libltdl/m4/libtool.m4 2010-11-27 16:03:50.0 +0900 @@ -1624,6 +1624,9 @@ lt_cv_sys_max_cmd_len=32768 fi ;; + os2*) +lt_cv_sys_max_cmd_len=-1 +;; *) lt_cv_sys_max_cmd_len=`(getconf ARG_MAX) 2 /dev/null` if test -n $lt_cv_sys_max_cmd_len; then Is there really no maximum for the command line length on OS/2? It depends on a shell. I know, a default shell, cmd.exe, has 1024 length limit. But 4OS2.exe has other limit. In case of pdksh which is used really, it seems to have no limits. Although a computed length by libtool is 8192, it could handle a longer command line than 8192. Well, what the Libtool macros do is compute a limit (that depends on your current environment), and then only take a fraction of that, half or so, to cope with additional environment. If it computes 8192, then chances are that your actual limit is not all that much higher. Does the computation of the limit take very long? Because if not, then I'm inclined to leave it in and drop the above patch, as then a later improvement to the limit will help users immediately. When porting VLC to OS/2, qt4 module needed a very long command line. So libtool try to create a reload object. The maximum length was 8192 at that time. Setting it to -1 does not need a reload object. Does using the reload object work, or does it fail? Users get fairly annoyed if the build fails due to the command line length limit is actually exceeded. We also need to think about users of other packages, not just VLC, where the list may be much higher. Thanks, Ralf
[SCM] GNU Libtool branch, master, updated. v2.4-33-g92eb89a
This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project GNU Libtool. The branch, master has been updated via 92eb89aace9fd41e43eee33f5c392adf1bcf8963 (commit) from 738f282ab18923b0dce5fd1abb3e6aa0d2ae499f (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log - commit 92eb89aace9fd41e43eee33f5c392adf1bcf8963 Author: Ralf Wildenhues ralf.wildenh...@gmx.de Date: Thu Dec 16 21:41:27 2010 +0100 Fix PIC flags with MPI wrappers using Portland on GNU/Linux. * libltdl/m4/libtool.m4 (_LT_COMPILER_PIC) [linux]: Match Portland compilers also using $CC -V output, to avoid false negatives with MPI compiler drivers. Report by Christian Rössel. Signed-off-by: Ralf Wildenhues ralf.wildenh...@gmx.de --- Summary of changes: ChangeLog |6 ++ libltdl/m4/libtool.m4 |5 + 2 files changed, 11 insertions(+), 0 deletions(-) diff --git a/ChangeLog b/ChangeLog index 1dac768..cbb0262 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,5 +1,11 @@ 2010-12-16 Ralf Wildenhues ralf.wildenh...@gmx.de + Fix PIC flags with MPI wrappers using Portland on GNU/Linux. + * libltdl/m4/libtool.m4 (_LT_COMPILER_PIC) [linux]: + Match Portland compilers also using $CC -V output, to avoid + false negatives with MPI compiler drivers. + Report by Christian Rössel. + * libltdl/m4/libtool.m4 (_LT_SETUP): Fix quoting for PATH_SEPARATOR. diff --git a/libltdl/m4/libtool.m4 b/libltdl/m4/libtool.m4 index 59114b4..62f9040 100644 --- a/libltdl/m4/libtool.m4 +++ b/libltdl/m4/libtool.m4 @@ -4340,6 +4340,11 @@ m4_if([$1], [CXX], [ _LT_TAGVAR(lt_prog_compiler_static, $1)='-Bstatic' _LT_TAGVAR(lt_prog_compiler_wl, $1)='-Wl,' ;; + *Portland\ Group*) + _LT_TAGVAR(lt_prog_compiler_wl, $1)='-Wl,' + _LT_TAGVAR(lt_prog_compiler_pic, $1)='-fpic' + _LT_TAGVAR(lt_prog_compiler_static, $1)='-Bstatic' + ;; esac ;; esac hooks/post-receive -- GNU Libtool
OS/2: command-line length limit (was: Enhanced OS/2 port)
Hello again, * KO Myung-Hun wrote on Sun, Nov 28, 2010 at 07:20:32AM CET: --- libltdl/m4/libtool.m4.org 2010-09-22 17:41:18.0 +0900 +++ libltdl/m4/libtool.m4 2010-11-27 16:03:50.0 +0900 @@ -1624,6 +1624,9 @@ lt_cv_sys_max_cmd_len=32768 fi ;; + os2*) +lt_cv_sys_max_cmd_len=-1 +;; *) lt_cv_sys_max_cmd_len=`(getconf ARG_MAX) 2 /dev/null` if test -n $lt_cv_sys_max_cmd_len; then Is there really no maximum for the command line length on OS/2? That would be really surprising to me, on a system which limits it DLL basenames to 8 characters. ;-) But if it is so, then the patch is obviously ok. Or did you do this in order to avoid an expensive check? What does the check do without the above change? Does it finish? Does the machine hang or need a reboot? I couldn't find good information about this issue on the net. Thanks, Ralf
Re: PIC flags not found for mpif77(ifort)
Hello Christian, * Christian Rössel wrote on Thu, Dec 16, 2010 at 05:27:23PM CET: Am 12/16/2010 11:19 AM, schrieb Christian Rössel: Am 12/15/2010 9:21 PM, schrieb Ralf Wildenhues: Hmm. Is $GCC = yes for this compiler? That would be surprising. Why else would the new branch not be matched? yes, the Intel compiler claims to be a GNU compiler: checking for gcc... icc [...] checking whether we are using the GNU C compiler... yes I'm not sure how autoconf performs this check, but we came up with the following to distinguish Intel from GNU: Thanks. So far we've more or less fared well with the assumption that if the compiler claims it is GNU, then we just use the GCC settings. If that doesn't work, then it's the compiler's fault to claim being GNU. And now I wonder why you are having problems with 'mpif77 -f77=ifort' because either it claims to be GNU (and then should accept -fPIC) or it doesn't claim to be GNU (and then my proposed patch, including the fix you spotted to double-quote the [CF]) should have worked. Can you show the config.log for the F77=mpif77 case that fails to detect the PIC flag? Thanks. As far as I remember, the older ifort versions at least didn't claim to be GNU (unlike icc or icpc). #if defined(__GNUC__) ! (defined(__INTEL_COMPILER) || defined(__ICC)) /* using a gnu but not an intel compiler */ #endif to prevent configure to identify Intel compilers as GNU compiler you need to add following code to _AC_LANG_COMPILER_GNU: #if defined(__INTEL_COMPILER) || defined(__ICC) choke me #endif This is not a valid patch, I know. Can you please give me a hint where to find a how-to for providing autotools patches? Good question. The git[0] development trees[1] of Autoconf and Libtool have files named HACKING that explain some bits. Generalities are documented in the GNU Coding Standards[2]. Portability issues are documented in the portability sections of the Autoconf manual[3]. Patches posted as 'diff -u' output are fine however; 'git diff' or 'git format-patch' output is more convenient for us. [0] http://git-scm.com/ [1] http://savannah.gnu.org/git/?group=autoconf http://savannah.gnu.org/git/?group=libtool [2] http://www.gnu.org/prep/standards/html_node/index.html [3] http://www.gnu.org/software/autoconf/manual/html_node/Portable-Shell.html BTW, the same problem occurs for mpif77 and mpif90 using the PGI compilers. Called with -V they produce: pgf90 10.9-0 64-bit target on x86-64 Linux -tp core2-64 Copyright 1989-2000, The Portland Group, Inc. All Rights Reserved. Copyright 2000-2010, STMicroelectronics, Inc. All Rights Reserved. I suppose that could be fixed with the diff below on top (pending the fix for the issue above). The patch for PGI works! Great. I've pushed that patch to the git tree. Thanks, Ralf
[SCM] GNU Libtool branch, master, updated. v2.4-31-g8c00e12
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project GNU Libtool.
The branch, master has been updated
via 8c00e12df8c8a1cc82e411779b2009e88bd203c2 (commit)
from 82beb2a169ac1943df67be90675c3135ece03735 (commit)
Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.
- Log -
commit 8c00e12df8c8a1cc82e411779b2009e88bd203c2
Author: KO Myung-Hun k...@chollian.net
Date: Wed Dec 15 22:29:17 2010 +0100
Fix PATH_SEPARATOR handling for OS/2.
* Makefile.am (update_mans): Quote $(PATH_SEPARATOR).
* libltdl/m4/libtool.m4 (_LT_SETUP): Add _LT_DECL for
PATH_SEPARATOR.
* libltdl/config/general.m4sh: Use PATH_SEPARATOR when computing
$progpath.
* THANKS: Update.
---
Summary of changes:
ChangeLog | 11 +++
Makefile.am |2 +-
THANKS |1 +
libltdl/config/general.m4sh |2 +-
libltdl/m4/libtool.m4 |2 ++
5 files changed, 16 insertions(+), 2 deletions(-)
diff --git a/ChangeLog b/ChangeLog
index 8bc122e..0d49595 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,14 @@
+2010-12-15 KO Myung-Hun k...@chollian.net (tiny change)
+ Ralf Wildenhues ralf.wildenh...@gmx.de
+
+ Fix PATH_SEPARATOR handling for OS/2.
+ * Makefile.am (update_mans): Quote $(PATH_SEPARATOR).
+ * libltdl/m4/libtool.m4 (_LT_SETUP): Add _LT_DECL for
+ PATH_SEPARATOR.
+ * libltdl/config/general.m4sh: Use PATH_SEPARATOR when computing
+ $progpath.
+ * THANKS: Update.
+
2010-12-10 Ralf Wildenhues ralf.wildenh...@gmx.de
Fix nvcc PIC setting on darwin.
diff --git a/Makefile.am b/Makefile.am
index 66f38b1..4be353c 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -330,7 +330,7 @@ $(srcdir)/doc/notes.txt: $(srcdir)/doc/notes.texi
dist_man1_MANS = $(srcdir)/doc/libtool.1 $(srcdir)/doc/libtoolize.1
MAINTAINERCLEANFILES += $(dist_man1_MANS)
update_mans = \
- PATH=.$(PATH_SEPARATOR)$$PATH; export PATH; \
+ PATH=.$(PATH_SEPARATOR)$$PATH; export PATH; \
$(HELP2MAN) --output=$@
$(srcdir)/doc/libtool.1: $(srcdir)/$(auxdir)/ltmain.sh
$(update_mans) --help-option=--help-all libtool
diff --git a/THANKS b/THANKS
index 6dd8dd8..5260878 100644
--- a/THANKS
+++ b/THANKS
@@ -122,6 +122,7 @@
Kenneth Albanowski kja...@kjahds.com
Kevin Ryde use...@zip.com.au
Khem Raj raj.k...@gmail.com
+ KO Myung-Hun k...@chollian.net
Kurt D. Zeilenga k...@openldap.org
Lennart Poettering lenn...@poettering.net
Lionel Landwerlin llandwer...@gmail.com
diff --git a/libltdl/config/general.m4sh b/libltdl/config/general.m4sh
index 44a7ce9..40d5413 100644
--- a/libltdl/config/general.m4sh
+++ b/libltdl/config/general.m4sh
@@ -296,7 +296,7 @@ case $progpath in
;;
*)
save_IFS=$IFS
- IFS=:
+ IFS=${PATH_SEPARATOR-:}
for progdir in $PATH; do
IFS=$save_IFS
test -x $progdir/$progname break
diff --git a/libltdl/m4/libtool.m4 b/libltdl/m4/libtool.m4
index 1f61140..ab3e16f 100644
--- a/libltdl/m4/libtool.m4
+++ b/libltdl/m4/libtool.m4
@@ -146,6 +146,8 @@ AC_REQUIRE([AC_CANONICAL_BUILD])dnl
AC_REQUIRE([_LT_PREPARE_SED_QUOTE_VARS])dnl
AC_REQUIRE([_LT_PROG_ECHO_BACKSLASH])dnl
+_LT_DECL([], [PATH_SEPARATOR], [0], [The PATH separator for the build
system])dnl
+dnl
_LT_DECL([], [host_alias], [0], [The host system])dnl
_LT_DECL([], [host], [0])dnl
_LT_DECL([], [host_os], [0])dnl
hooks/post-receive
--
GNU Libtool
Re: PIC flags not found for mpif77(ifort)
* Christian Rössel wrote on Wed, Dec 15, 2010 at 04:38:13PM CET: Am 12/10/2010 6:55 PM, schrieb Ralf Wildenhues: Alternatively, the untested patch below should help as well. Can you try it out? Unfortunately the patch didn't work. configure does not execute the new case branch although the innermost condition matches. Hmm. Is $GCC = yes for this compiler? That would be surprising. Why else would the new branch not be matched? BTW, the same problem occurs for mpif77 and mpif90 using the PGI compilers. Called with -V they produce: pgf90 10.9-0 64-bit target on x86-64 Linux -tp core2-64 Copyright 1989-2000, The Portland Group, Inc. All Rights Reserved. Copyright 2000-2010, STMicroelectronics, Inc. All Rights Reserved. I suppose that could be fixed with the diff below on top (pending the fix for the issue above). Thanks, Ralf diff --git a/libltdl/m4/libtool.m4 b/libltdl/m4/libtool.m4 index e735c75..7323986 100644 --- a/libltdl/m4/libtool.m4 +++ b/libltdl/m4/libtool.m4 @@ -4343,6 +4343,11 @@ m4_if([$1], [CXX], [ _LT_TAGVAR(lt_prog_compiler_pic, $1)='-fPIC' _LT_TAGVAR(lt_prog_compiler_static, $1)='-static' ;; + *Portland\ Group*) + _LT_TAGVAR(lt_prog_compiler_wl, $1)='-Wl,' + _LT_TAGVAR(lt_prog_compiler_pic, $1)='-fpic' + _LT_TAGVAR(lt_prog_compiler_static, $1)='-Bstatic' + ;; esac ;; esac
Re: Enhanced OS/2 port
[ adding libtool-patches@; followups can remove libtool@ ]
* KO Myung-Hun wrote on Sun, Nov 28, 2010 at 07:20:32AM CET:
I've enhanced and fixed libtool 2.4 for OS/2.
Thanks again for working on this.
Generally, we prefer one patch per logical change, and GNU-style
ChangeLog entries. Also, we should strive to expose bugs in the
testsuite, so that we don't regress.
I understand that just producing a patch at all can be hard work,
so we can help with things (just that takes time ...)
One thing is quite helpful though, and that's how well our testsuite
fares on your system (both without and with the patch).
Also, for nontrivial changes, the FSF needs copyright papers
(more on this off-list).
That said, let's try to get the easier things out of the way:
--- Makefile.am.org 2010-09-21 16:07:22.0 +0900
+++ Makefile.am 2010-11-27 00:19:56.0 +0900
@@ -324,7 +324,7 @@
dist_man1_MANS = $(srcdir)/doc/libtool.1
$(srcdir)/doc/libtoolize.1
MAINTAINERCLEANFILES += $(dist_man1_MANS)
update_mans = \
- PATH=.$(PATH_SEPARATOR)$$PATH; export PATH; \
+ PATH=.$(PATH_SEPARATOR)$$PATH; export PATH; \
Good change.
$(HELP2MAN) --output=$@
$(srcdir)/doc/libtool.1: $(srcdir)/$(auxdir)/ltmain.sh
$(update_mans) --help-option=--help-all libtool
--- libltdl/config/general.m4sh.org 2010-09-01 15:02:44.0 +0900
+++ libltdl/config/general.m4sh 2010-11-27 12:15:52.0 +0900
@@ -296,10 +296,13 @@
;;
*)
save_IFS=$IFS
- IFS=:
- for progdir in $PATH; do
- IFS=$save_IFS
- test -x $progdir/$progname break
+ for pathsep in : ;; do
+ IFS=$pathsep
+ for progdir in $PATH$pathsep; do
+ IFS=$save_IFS
+ test -x $progdir/$progname break
+ done
+ test -n $progdir break
done
IFS=$save_IFS
test -n $progdir || progdir=`pwd`
I don't particularly like guessing here. Rather, let's store the
configure-computed PATH_SEPARATOR in the generated libtool script
(libtoolize already sets it anyway) and use that.
I'm applying the following patch in your name, and adding you to THANKS:
2010-12-15 KO Myung-Hun k...@chollian.net (tiny change)
Ralf Wildenhues ralf.wildenh...@gmx.de
Fix PATH_SEPARATOR handling for OS/2.
* Makefile.am (update_mans): Quote $(PATH_SEPARATOR).
* libltdl/m4/libtool.m4 (_LT_SETUP): Add _LT_DECL for
PATH_SEPARATOR.
* libltdl/config/general.m4sh: Use PATH_SEPARATOR when computing
$progpath.
* THANKS: Update.
diff --git a/Makefile.am b/Makefile.am
index 66f38b1..4be353c 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -330,7 +330,7 @@ $(srcdir)/doc/notes.txt: $(srcdir)/doc/notes.texi
dist_man1_MANS = $(srcdir)/doc/libtool.1 $(srcdir)/doc/libtoolize.1
MAINTAINERCLEANFILES += $(dist_man1_MANS)
update_mans = \
- PATH=.$(PATH_SEPARATOR)$$PATH; export PATH; \
+ PATH=.$(PATH_SEPARATOR)$$PATH; export PATH; \
$(HELP2MAN) --output=$@
$(srcdir)/doc/libtool.1: $(srcdir)/$(auxdir)/ltmain.sh
$(update_mans) --help-option=--help-all libtool
diff --git a/libltdl/config/general.m4sh b/libltdl/config/general.m4sh
index 44a7ce9..40d5413 100644
--- a/libltdl/config/general.m4sh
+++ b/libltdl/config/general.m4sh
@@ -296,7 +296,7 @@ case $progpath in
;;
*)
save_IFS=$IFS
- IFS=:
+ IFS=${PATH_SEPARATOR-:}
for progdir in $PATH; do
IFS=$save_IFS
test -x $progdir/$progname break
diff --git a/libltdl/m4/libtool.m4 b/libltdl/m4/libtool.m4
index 1f61140..ab3e16f 100644
--- a/libltdl/m4/libtool.m4
+++ b/libltdl/m4/libtool.m4
@@ -146,6 +146,8 @@ AC_REQUIRE([AC_CANONICAL_BUILD])dnl
AC_REQUIRE([_LT_PREPARE_SED_QUOTE_VARS])dnl
AC_REQUIRE([_LT_PROG_ECHO_BACKSLASH])dnl
+_LT_DECL([], [PATH_SEPARATOR], [0], [The PATH separator for the build
system])dnl
+dnl
_LT_DECL([], [host_alias], [0], [The host system])dnl
_LT_DECL([], [host], [0])dnl
_LT_DECL([], [host_os], [0])dnl
@@ -564,6 +567,10 @@
(in func_show_eval)
my_cmd=$1
my_fail_exp=${2-:}
+# pdksh 5.2.14-bin-2 for OS/2 does not remove trailing CR
+# when a line length is 1022. Maybe 1022 is a magic number ?
+my_cmd=`$ECHO $my_cmd | $SED s/\r$//`
Ouch. Where did you hit this? Can't you fix pdksh instead?
This change unconditionally costs two forks and one exec on almost every
command that libtool issues. Also, \r is not a portable sed regex.
Does something like this work instead?
# pdksh 5.2.14-bin-2 for OS/2 does not remove trailing CR
# when a line length is 1022.
case $my_cmd in *$'\r')
my_cmd=`$ECHO $my_cmd | $SED s/\r$//` ;;
esac
What about this?
cr=$'\r'
case $my_cmd in *$cr)
my_cmd=`$ECHO $my_cmd | $SED s/\r$//` ;;
esac
Then we still need to factor setting of $cr, but at least it's not quite
so expensive on other systems.
${opt_silent-false
Re: Enhanced OS/2 port
* Ralf Wildenhues wrote on Wed, Dec 15, 2010 at 10:32:04PM CET: --- a/libltdl/m4/libtool.m4 +++ b/libltdl/m4/libtool.m4 @@ -146,6 +146,8 @@ AC_REQUIRE([AC_CANONICAL_BUILD])dnl AC_REQUIRE([_LT_PREPARE_SED_QUOTE_VARS])dnl AC_REQUIRE([_LT_PROG_ECHO_BACKSLASH])dnl +_LT_DECL([], [PATH_SEPARATOR], [0], [The PATH separator for the build system])dnl +dnl _LT_DECL([], [host_alias], [0], [The host system])dnl _LT_DECL([], [host], [0])dnl _LT_DECL([], [host_os], [0])dnl Sorry about the glitch, but the above doesn't put double-quotes around the value in the libtool script. I'm pushing this followup patch to fix that. Cheers, Ralf * libltdl/m4/libtool.m4 (_LT_SETUP): Fix quoting for PATH_SEPARATOR. diff --git a/libltdl/m4/libtool.m4 b/libltdl/m4/libtool.m4 index ab3e16f..59114b4 100644 --- a/libltdl/m4/libtool.m4 +++ b/libltdl/m4/libtool.m4 @@ -146,7 +146,7 @@ AC_REQUIRE([AC_CANONICAL_BUILD])dnl AC_REQUIRE([_LT_PREPARE_SED_QUOTE_VARS])dnl AC_REQUIRE([_LT_PROG_ECHO_BACKSLASH])dnl -_LT_DECL([], [PATH_SEPARATOR], [0], [The PATH separator for the build system])dnl +_LT_DECL([], [PATH_SEPARATOR], [1], [The PATH separator for the build system])dnl dnl _LT_DECL([], [host_alias], [0], [The host system])dnl _LT_DECL([], [host], [0])dnl
Re: PIC flags not found for mpif77(ifort)
* Christian Rössel wrote on Wed, Dec 15, 2010 at 04:38:13PM CET: Am 12/10/2010 6:55 PM, schrieb Ralf Wildenhues: Alternatively, the untested patch below should help as well. Can you try it out? Unfortunately the patch didn't work. configure does not execute the new case branch although the innermost condition matches. Hmm. Is $GCC = yes for this compiler? That would be surprising. Why else would the new branch not be matched? BTW, the same problem occurs for mpif77 and mpif90 using the PGI compilers. Called with -V they produce: pgf90 10.9-0 64-bit target on x86-64 Linux -tp core2-64 Copyright 1989-2000, The Portland Group, Inc. All Rights Reserved. Copyright 2000-2010, STMicroelectronics, Inc. All Rights Reserved. I suppose that could be fixed with the diff below on top (pending the fix for the issue above). Thanks, Ralf diff --git a/libltdl/m4/libtool.m4 b/libltdl/m4/libtool.m4 index e735c75..7323986 100644 --- a/libltdl/m4/libtool.m4 +++ b/libltdl/m4/libtool.m4 @@ -4343,6 +4343,11 @@ m4_if([$1], [CXX], [ _LT_TAGVAR(lt_prog_compiler_pic, $1)='-fPIC' _LT_TAGVAR(lt_prog_compiler_static, $1)='-static' ;; + *Portland\ Group*) + _LT_TAGVAR(lt_prog_compiler_wl, $1)='-Wl,' + _LT_TAGVAR(lt_prog_compiler_pic, $1)='-fpic' + _LT_TAGVAR(lt_prog_compiler_static, $1)='-Bstatic' + ;; esac ;; esac ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Enhanced OS/2 port
[ adding libtool-patches@; followups can remove libtool@ ]
* KO Myung-Hun wrote on Sun, Nov 28, 2010 at 07:20:32AM CET:
I've enhanced and fixed libtool 2.4 for OS/2.
Thanks again for working on this.
Generally, we prefer one patch per logical change, and GNU-style
ChangeLog entries. Also, we should strive to expose bugs in the
testsuite, so that we don't regress.
I understand that just producing a patch at all can be hard work,
so we can help with things (just that takes time ...)
One thing is quite helpful though, and that's how well our testsuite
fares on your system (both without and with the patch).
Also, for nontrivial changes, the FSF needs copyright papers
(more on this off-list).
That said, let's try to get the easier things out of the way:
--- Makefile.am.org 2010-09-21 16:07:22.0 +0900
+++ Makefile.am 2010-11-27 00:19:56.0 +0900
@@ -324,7 +324,7 @@
dist_man1_MANS = $(srcdir)/doc/libtool.1
$(srcdir)/doc/libtoolize.1
MAINTAINERCLEANFILES += $(dist_man1_MANS)
update_mans = \
- PATH=.$(PATH_SEPARATOR)$$PATH; export PATH; \
+ PATH=.$(PATH_SEPARATOR)$$PATH; export PATH; \
Good change.
$(HELP2MAN) --output=$@
$(srcdir)/doc/libtool.1: $(srcdir)/$(auxdir)/ltmain.sh
$(update_mans) --help-option=--help-all libtool
--- libltdl/config/general.m4sh.org 2010-09-01 15:02:44.0 +0900
+++ libltdl/config/general.m4sh 2010-11-27 12:15:52.0 +0900
@@ -296,10 +296,13 @@
;;
*)
save_IFS=$IFS
- IFS=:
- for progdir in $PATH; do
- IFS=$save_IFS
- test -x $progdir/$progname break
+ for pathsep in : ;; do
+ IFS=$pathsep
+ for progdir in $PATH$pathsep; do
+ IFS=$save_IFS
+ test -x $progdir/$progname break
+ done
+ test -n $progdir break
done
IFS=$save_IFS
test -n $progdir || progdir=`pwd`
I don't particularly like guessing here. Rather, let's store the
configure-computed PATH_SEPARATOR in the generated libtool script
(libtoolize already sets it anyway) and use that.
I'm applying the following patch in your name, and adding you to THANKS:
2010-12-15 KO Myung-Hun k...@chollian.net (tiny change)
Ralf Wildenhues ralf.wildenh...@gmx.de
Fix PATH_SEPARATOR handling for OS/2.
* Makefile.am (update_mans): Quote $(PATH_SEPARATOR).
* libltdl/m4/libtool.m4 (_LT_SETUP): Add _LT_DECL for
PATH_SEPARATOR.
* libltdl/config/general.m4sh: Use PATH_SEPARATOR when computing
$progpath.
* THANKS: Update.
diff --git a/Makefile.am b/Makefile.am
index 66f38b1..4be353c 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -330,7 +330,7 @@ $(srcdir)/doc/notes.txt: $(srcdir)/doc/notes.texi
dist_man1_MANS = $(srcdir)/doc/libtool.1 $(srcdir)/doc/libtoolize.1
MAINTAINERCLEANFILES += $(dist_man1_MANS)
update_mans = \
- PATH=.$(PATH_SEPARATOR)$$PATH; export PATH; \
+ PATH=.$(PATH_SEPARATOR)$$PATH; export PATH; \
$(HELP2MAN) --output=$@
$(srcdir)/doc/libtool.1: $(srcdir)/$(auxdir)/ltmain.sh
$(update_mans) --help-option=--help-all libtool
diff --git a/libltdl/config/general.m4sh b/libltdl/config/general.m4sh
index 44a7ce9..40d5413 100644
--- a/libltdl/config/general.m4sh
+++ b/libltdl/config/general.m4sh
@@ -296,7 +296,7 @@ case $progpath in
;;
*)
save_IFS=$IFS
- IFS=:
+ IFS=${PATH_SEPARATOR-:}
for progdir in $PATH; do
IFS=$save_IFS
test -x $progdir/$progname break
diff --git a/libltdl/m4/libtool.m4 b/libltdl/m4/libtool.m4
index 1f61140..ab3e16f 100644
--- a/libltdl/m4/libtool.m4
+++ b/libltdl/m4/libtool.m4
@@ -146,6 +146,8 @@ AC_REQUIRE([AC_CANONICAL_BUILD])dnl
AC_REQUIRE([_LT_PREPARE_SED_QUOTE_VARS])dnl
AC_REQUIRE([_LT_PROG_ECHO_BACKSLASH])dnl
+_LT_DECL([], [PATH_SEPARATOR], [0], [The PATH separator for the build
system])dnl
+dnl
_LT_DECL([], [host_alias], [0], [The host system])dnl
_LT_DECL([], [host], [0])dnl
_LT_DECL([], [host_os], [0])dnl
@@ -564,6 +567,10 @@
(in func_show_eval)
my_cmd=$1
my_fail_exp=${2-:}
+# pdksh 5.2.14-bin-2 for OS/2 does not remove trailing CR
+# when a line length is 1022. Maybe 1022 is a magic number ?
+my_cmd=`$ECHO $my_cmd | $SED s/\r$//`
Ouch. Where did you hit this? Can't you fix pdksh instead?
This change unconditionally costs two forks and one exec on almost every
command that libtool issues. Also, \r is not a portable sed regex.
Does something like this work instead?
# pdksh 5.2.14-bin-2 for OS/2 does not remove trailing CR
# when a line length is 1022.
case $my_cmd in *$'\r')
my_cmd=`$ECHO $my_cmd | $SED s/\r$//` ;;
esac
What about this?
cr=$'\r'
case $my_cmd in *$cr)
my_cmd=`$ECHO $my_cmd | $SED s/\r$//` ;;
esac
Then we still need to factor setting of $cr, but at least it's not quite
so expensive on other systems.
${opt_silent-false
Re: PIC flags not found for mpif77(ifort)
Hello Christian, * Christian Rössel wrote on Fri, Dec 10, 2010 at 02:56:51PM CET: ./configure --enable-shared F77=mpif77 ... where mpif77 translates to ifort -I/opt/parastation/mpi2-intel/include -L/opt/parastation/mpi2-intel/lib -Wl,-rpath -Wl,/opt/parastation/mpi2-intel/lib -lmpich -lpthread -L/opt/parastation/lib64 -Wl,-rpath,/opt/parastation/lib64 -Wl,--enable-new-dtags -lpscom -lrt configure fails in finding PIC flags (mpicc (icc) and mpicxx (icpc) PIC flags are discovered though): configure:17627: checking for mpif77 option to produce PIC configure:17899: result: There is no more output concerning the PIC flags in config.log. With F77=ifort everything works as expected: configure:16805: checking for ifort option to produce PIC configure:17077: result: -fPIC Yeah, that's because libtool.m4 macros partly match by name, unless the compiler claims to be GCC. A bit dumb, sure, but it's not easy to avoid because portable testing of these flags is not trivial. We might have to think about a more general way to extract the compiler name from an MPI driver (-show and -showme come to mind). For the moment you should be able to work around it using configure lt_cv_prog_compiler_pic_F77=-fPIC \ lt_cv_prog_compiler_pic_FC=-fPIC \ but I'm not sure if you also need fixes for missing -static and -Wl, flags (lt_prog_compiler_wl_F77 and lt_prog_compiler_static_F77 ...). This requires Libtool = 2.4. Alternatively, the untested patch below should help as well. Can you try it out? Thanks for the report, Ralf Fix PIC flags with mpif77 using ifort on GNU/Linux. * libltdl/m4/libtool.m4 (_LT_COMPILER_PIC) [linux]: Match Intel compiler also using $CC -V output, to avoid false negatives with compiler drivers like mpif77. Report by Christian Rössel. diff --git a/libltdl/m4/libtool.m4 b/libltdl/m4/libtool.m4 index 1f61140..e735c75 100644 --- a/libltdl/m4/libtool.m4 +++ b/libltdl/m4/libtool.m4 @@ -4338,6 +4338,11 @@ m4_if([$1], [CXX], [ _LT_TAGVAR(lt_prog_compiler_static, $1)='-Bstatic' _LT_TAGVAR(lt_prog_compiler_wl, $1)='-Wl,' ;; +*Intel*\ [CF]*Compiler*) + _LT_TAGVAR(lt_prog_compiler_wl, $1)='-Wl,' + _LT_TAGVAR(lt_prog_compiler_pic, $1)='-fPIC' + _LT_TAGVAR(lt_prog_compiler_static, $1)='-static' + ;; esac ;; esac ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Unwanted shared runtime libraries getting added
* Ethan Mallove wrote on Fri, Dec 10, 2010 at 07:41:20PM CET: On Thu, Oct/21/2010 06:13:03AM, Ralf Wildenhues wrote: Pass -Wc,-static-intel instead. This works like a charm for shared libraries, but for standalone executables I get an error like this: ... icc: command line warning #10156: ignoring option '-W'; no argument required /bin/sh ../../../libtool --tag=CC --mode=link icc -Wc,-static-intel -g -finline-functions -fno-strict-aliasing -restrict -pthread -fvisibility=hidden -export-dynamic -o orte-iof orte-iof.o ../../../orte/libopen-rte.la -lnsl -lutil libtool: link: icc -Wl,-static-intel -g -finline-functions -fno-strict-aliasing -restrict -pthread -fvisibility=hidden -o .libs/orte-iof orte-iof.o -Wl,--export-dynamic ../../../orte/.libs/libopen-rte.so -ldl -lnsl -lutil -pthread -Wl,-rpath -Wl,$ORIGIN -Wl,-rpath -Wl,$ORIGIN/.. -Wl,-rpath -Wl,$ORIGIN/../lib ipo: warning #11015: Warning unknown option -static-intel ld: unrecognized -a option `tic-intel' Do you know of a way to get this working in both cases: shared libs and standalone executable? Yes. Use Libtool 2.2.8 or newer. Quoting from the NEWS file: - Fix ancient bug where -Wc, was turned into $wl (typically -Wl,) when using the compiler driver to link programs. Now -Wc, is stripped just as it is when linking libraries through the compiler driver. Cheers, Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool
[SCM] GNU Libtool branch, master, updated. v2.4-30-g82beb2a
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project GNU Libtool.
The branch, master has been updated
via 82beb2a169ac1943df67be90675c3135ece03735 (commit)
via 1c9aa6dac54372220d367715bf891a6f06c668fd (commit)
via cc027148f2acded5c1a2bd5c951ef70fb3223a50 (commit)
from 4fee8796c92a2ab554eb6596330ac06613c22807 (commit)
Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.
- Log -
commit 82beb2a169ac1943df67be90675c3135ece03735
Author: Ralf Wildenhues ralf.wildenh...@gmx.de
Date: Mon Dec 6 04:31:14 2010 +0100
Fix nvcc PIC setting on darwin.
* libltdl/m4/libtool.m4 (_LT_COMPILER_PIC)
lt_prog_compiler_pic: Prepend -Xcompiler to nonempty variable
setting rather than hard-coding -Xcompiler -fPIC, for darwin.
* NEWS, THANKS: Update.
Report by PaweÅ Daniluk.
Signed-off-by: Ralf Wildenhues ralf.wildenh...@gmx.de
commit 1c9aa6dac54372220d367715bf891a6f06c668fd
Author: Ralf Wildenhues ralf.wildenh...@gmx.de
Date: Sat Nov 20 10:34:16 2010 +0100
Honor $AUTOCONF, $AUTOMAKE in --help output.
* libltdl/config/getopt.m4sh (func_help): Use $AUTOCONF and
$AUTOMAKE if set, for --version outout.
Signed-off-by: Ralf Wildenhues ralf.wildenh...@gmx.de
commit cc027148f2acded5c1a2bd5c951ef70fb3223a50
Author: Ralf Wildenhues ralf.wildenh...@gmx.de
Date: Fri Nov 19 18:42:04 2010 +0100
docs: Libtool configuration diagram.
* doc/libtool.texi (Integrating libtool): Add diagrams
explaining the dependencies between Libtool files.
Suggestion by Ethan Mallove.
Signed-off-by: Ralf Wildenhues ralf.wildenh...@gmx.de
---
Summary of changes:
ChangeLog | 18 +++
NEWS |1 +
THANKS |1 +
doc/libtool.texi | 50
libltdl/config/getopt.m4sh |4 +-
libltdl/m4/libtool.m4 |4 ++-
6 files changed, 75 insertions(+), 3 deletions(-)
diff --git a/ChangeLog b/ChangeLog
index e418f3c..8bc122e 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,21 @@
+2010-12-10 Ralf Wildenhues ralf.wildenh...@gmx.de
+
+ Fix nvcc PIC setting on darwin.
+ * libltdl/m4/libtool.m4 (_LT_COMPILER_PIC)
+ lt_prog_compiler_pic: Prepend -Xcompiler to nonempty variable
+ setting rather than hard-coding -Xcompiler -fPIC, for darwin.
+ * NEWS, THANKS: Update.
+ Report by PaweÅ Daniluk.
+
+ Honor $AUTOCONF, $AUTOMAKE in --help output.
+ * libltdl/config/getopt.m4sh (func_help): Use $AUTOCONF and
+ $AUTOMAKE if set, for --version outout.
+
+ docs: Libtool configuration diagram.
+ * doc/libtool.texi (Integrating libtool): Add diagrams
+ explaining the dependencies between Libtool files.
+ Suggestion by Ethan Mallove.
+
2010-11-15 Ralf Wildenhues ralf.wildenh...@gmx.de
Eliminate hardcode_libdir_flag_spec_ld tag variable.
diff --git a/NEWS b/NEWS
index 83cee5e..0aeca57 100644
--- a/NEWS
+++ b/NEWS
@@ -14,6 +14,7 @@ New in 2.4.2 2010-12-??: git version 2.4.1a, Libtool team:
not available) works again. Regression introduced in v2.2.6-39-g9c3d4d8.
- The bug that leaked developer tool paths into the release tarballs
from ./bootstrap is fixed.
+ - Improved support for the Cuda Compiler Driver (nvcc) on Darwin.
* Important incompatible changes:
diff --git a/THANKS b/THANKS
index e85e21a..6dd8dd8 100644
--- a/THANKS
+++ b/THANKS
@@ -147,6 +147,7 @@
Paul Biggar paul.big...@gmail.com
Paul Eggert egg...@twinsun.com
Paul Laight plai...@quantxautomation.co.uk
+ PaweÅ Daniluk pa...@bioexploratorium.pl
Peter Eisentraut pete...@gmx.net
Peter Fritzsche peter.fritzs...@gmx.de
Peter Jeremy peterjer...@optushome.com.au
diff --git a/doc/libtool.texi b/doc/libtool.texi
index 12d006b..04c5507 100644
--- a/doc/libtool.texi
+++ b/doc/libtool.texi
@@ -1791,6 +1791,56 @@ The remaining @var{mode-args} are either flags for the
deletion program
This chapter describes how to integrate libtool with your packages so
that your users can install hassle-free shared libraries.
+There are several ways in which Libtool may be integrated in your
+package, described in the following sections. Typically, the Libtool
+macro files as well as @file{ltmain.sh} are copied into your package
+using @command{libtoolize} and @command{aclocal} after setting up the
+...@file{configure.ac} and toplevel @file{Makefile.am}, then
+...@command{autoconf} adds the needed tests
Re: Libtool and CUDA
* Peter O'Gorman wrote on Mon, Dec 06, 2010 at 10:56:13PM CET: On 12/06/2010 03:25 PM, Ralf Wildenhues wrote: Where do you see that? As far as I understand, Paweł hasn't actually tried configuring Libtool with something like Yeah, I failed to read your entire email this morning, definitely didn't have enough coffee. It makes sense now :) We have some compilers with whitespace in lt_prog_compiler_pic, I assume nvcc doesn't run on those platforms? So far I know only of GNU/Linux, Windows, and OS X as supported platforms. I would be mildly surprised if Nvidia were interested in porting their code to any other platforms. Thanks for the feedback, I've pushed the patch now. Cheers, Ralf
Re: docs: Libtool configuration diagram.
* Ralf Wildenhues wrote on Sat, Nov 20, 2010 at 09:30:41AM CET: Ethan suggested we have a Libtool flow chart, similar to how Automake has one in its manual. Here we go. OK to commit? Pushed now. docs: Libtool configuration diagram. * doc/libtool.texi (Integrating libtool): Add diagrams explaining the dependencies between Libtool files. Suggestion by Ethan Mallove.
Re: libtool --help: honor $AUTOCONF, $AUTOMAKE
* Ralf Wildenhues wrote on Sat, Nov 20, 2010 at 10:30:37AM CET:
Avoid running installed automake from 'libtool --help'.
* tests/subobj9.test: Export AUTOCONF and AUTOMAKE.
Together with fixed Libtool, this fixes check-coverage to not
invoke installed automake.
Pushed to Automake maint now.
diff --git a/tests/subobj9.test b/tests/subobj9.test
index 2045d58..83f3a31 100755
--- a/tests/subobj9.test
+++ b/tests/subobj9.test
@@ -64,6 +64,9 @@ $AUTOMAKE -a
# Skip this test on configure errors (e.g., broken C++ compilers).
./configure || Exit 77
+# Ensure './libtool --help' will use the right tool versions.
+export AUTOCONF AUTOMAKE
+
# Opportunistically check that --tag=CXX is used when supported.
if ./libtool --help | grep tag=TAG; then
$MAKE print stdout || { cat stdout; Exit 1; }
Honor $AUTOCONF, $AUTOMAKE in --help output.
* libltdl/config/getopt.m4sh (func_help): Use $AUTOCONF and
$AUTOMAKE if set, for --version outout.
Pushed to Libtool now.
diff --git a/libltdl/config/getopt.m4sh b/libltdl/config/getopt.m4sh
index 2196743..e9363bc 100644
--- a/libltdl/config/getopt.m4sh
+++ b/libltdl/config/getopt.m4sh
@@ -592,8 +592,8 @@ func_help ()
s*\$LTCFLAGS*'$LTCFLAGS'*
s*\$LD*'$LD'*
s/\$with_gnu_ld/'$with_gnu_ld'/
- s/\$automake_version/'`(automake --version) 2/dev/null |$SED 1q`'/
- s/\$autoconf_version/'`(autoconf --version) 2/dev/null |$SED 1q`'/
+ s/\$automake_version/'`(${AUTOMAKE-automake} --version) 2/dev/null
|$SED 1q`'/
+ s/\$autoconf_version/'`(${AUTOCONF-autoconf} --version) 2/dev/null
|$SED 1q`'/
p
d
}
Re: Libtool and CUDA
* Peter O'Gorman wrote on Mon, Dec 06, 2010 at 10:56:13PM CET: On 12/06/2010 03:25 PM, Ralf Wildenhues wrote: Where do you see that? As far as I understand, Paweł hasn't actually tried configuring Libtool with something like Yeah, I failed to read your entire email this morning, definitely didn't have enough coffee. It makes sense now :) We have some compilers with whitespace in lt_prog_compiler_pic, I assume nvcc doesn't run on those platforms? So far I know only of GNU/Linux, Windows, and OS X as supported platforms. I would be mildly surprised if Nvidia were interested in porting their code to any other platforms. Thanks for the feedback, I've pushed the patch now. Cheers, Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Libtool and CUDA
Hi Peter, * Peter O'Gorman wrote on Mon, Dec 06, 2010 at 02:49:23PM CET: On 12/06/2010 01:07 AM, Ralf Wildenhues wrote: OK to apply? Unless Pawel reports that it works for him, no. This doesn't make sense to me. Why? Well, perhaps I haven't been drinking enough coffee, but... Hehe. _LT_TAGVAR(lt_prog_compiler_wl, $1)='-Xlinker ' This assignment didn't work, or was overwritten later. Where do you see that? As far as I understand, Paweł hasn't actually tried configuring Libtool with something like ./configure CC=nvcc because then the assignment will work. - _LT_TAGVAR(lt_prog_compiler_pic, $1)='-Xcompiler -fPIC' So, why will this make any difference? See above. + if test -n $_LT_TAGVAR(lt_prog_compiler_pic, $1); then +_LT_TAGVAR(lt_prog_compiler_pic, $1)=-Xcompiler $_LT_TAGVAR(lt_prog_compiler_pic, $1) + fi Of course the whole support currently won't work if you need to have both compilers CC=gcc and, say, NVCC=nvcc or so; to workaround you currently need a subpackage with a sub configure script where you override CC=$NVCC. We could fix that in the same way as the proposed Go patch: by explicitly introducing a new language called Cuda or so. I'm not disinclined, but since there exists no free version of this compiler this might politically be a bit interesting, to say the least. I was wrong a bit in my last message though: the manual for version 2.0 does document --shared and -shared, and mentions that other flags necessary for shared libraries need to be passed through with -Xcompiler. Which matches my proposed patch. Cheers, Ralf
Re: Libtools for Win7-64
* Arbol One wrote on Mon, Dec 06, 2010 at 02:57:16PM CET: Having stated the above and on another front, I would like to know if you can direct me to a place where I can download libtools-64bit. Well, you can just download Libtool 2.4 from http://ftp.gnu.org/gnu/libtool, extract and build it on your systems. Whichever systems that are. If you hit one that we don't support (yet), come back and complain. We will then work with you to add support for that system as well. We support everything! ;-) Cheers, Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Libtool and CUDA
Hi Peter, * Peter O'Gorman wrote on Mon, Dec 06, 2010 at 02:49:23PM CET: On 12/06/2010 01:07 AM, Ralf Wildenhues wrote: OK to apply? Unless Pawel reports that it works for him, no. This doesn't make sense to me. Why? Well, perhaps I haven't been drinking enough coffee, but... Hehe. _LT_TAGVAR(lt_prog_compiler_wl, $1)='-Xlinker ' This assignment didn't work, or was overwritten later. Where do you see that? As far as I understand, Paweł hasn't actually tried configuring Libtool with something like ./configure CC=nvcc because then the assignment will work. - _LT_TAGVAR(lt_prog_compiler_pic, $1)='-Xcompiler -fPIC' So, why will this make any difference? See above. + if test -n $_LT_TAGVAR(lt_prog_compiler_pic, $1); then +_LT_TAGVAR(lt_prog_compiler_pic, $1)=-Xcompiler $_LT_TAGVAR(lt_prog_compiler_pic, $1) + fi Of course the whole support currently won't work if you need to have both compilers CC=gcc and, say, NVCC=nvcc or so; to workaround you currently need a subpackage with a sub configure script where you override CC=$NVCC. We could fix that in the same way as the proposed Go patch: by explicitly introducing a new language called Cuda or so. I'm not disinclined, but since there exists no free version of this compiler this might politically be a bit interesting, to say the least. I was wrong a bit in my last message though: the manual for version 2.0 does document --shared and -shared, and mentions that other flags necessary for shared libraries need to be passed through with -Xcompiler. Which matches my proposed patch. Cheers, Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Libtool and CUDA
* Paweł Daniluk wrote on Mon, Dec 06, 2010 at 11:52:00AM CET: Thanks for your prompt reply. Unfortunately the patch doesn't seem to change anything. Perhaps I'm doing something completely wrong. I expect that libtool after invoking in compile mode with nvcc instead of gcc should add -Xcompiler where needed, but I get: I have always treated libtool as a black box which just works, and know very little about its internals. Nevertheless libtool doesn't seem to depend on any external files, and contains no nvcc string. Maybe I miss something during the compilation phase. Right. You need to configure Libtool with CC=nvcc for it to work right for nvcc. One alternative is to integrate Libtool in your own (autoconf-using) package; see 'info libtool Integrating libtool' for more information. Cheers, Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Oracle Solaris Studio 12.2 compiler incompatibility with libtool
* Ralf Wildenhues wrote on Thu, Nov 18, 2010 at 09:23:17PM CET: * Terry Dontje wrote on Wed, Nov 17, 2010 at 01:00:26PM CET: I've discussed this internally and yes we would like Ceres to be supported. Oh, no problem. Presumably that means you have some way to test the proposed patch then with all the interesting compilers. That would be very nice. :-) Erm, I haven't pushed this patch yet, assuming that some test feedback would be better than none at all. Any chance you could try it out sometime? Thanks, Ralf Here it goes; it works with this (yes, very old) Sun Studio X.X on GNU/Linux installation; and yes, this is about GNU/Linux only. 2010-11-18 Ralf Wildenhues ... Fix $wl setting for Solaris Studio 12.2 f90 on GNU/Linux. * libltdl/m4/libtool.m4 (_LT_COMPILER_PIC) [linux] lt_prog_compiler_wl: Set to '-Qoption ld ' if we detect Sun Fortran version 8.4 or newer. Report by Terry Dontje. diff --git a/libltdl/m4/libtool.m4 b/libltdl/m4/libtool.m4 index 419ffe1..4a371c9 100644 --- a/libltdl/m4/libtool.m4 +++ b/libltdl/m4/libtool.m4 @@ -4324,12 +4324,17 @@ m4_if([$1], [CXX], [ ;; *) case `$CC -V 21 | sed 5q` in - *Sun\ F* | *Sun*Fortran*) + *Sun\ Ceres\ Fortran* | *Sun*Fortran*\ [[1-7]].* | *Sun*Fortran*\ 8.[[0-3]]*) # Sun Fortran 8.3 passes all unrecognized flags to the linker _LT_TAGVAR(lt_prog_compiler_pic, $1)='-KPIC' _LT_TAGVAR(lt_prog_compiler_static, $1)='-Bstatic' _LT_TAGVAR(lt_prog_compiler_wl, $1)='' ;; + *Sun\ F* | *Sun*Fortran*) + _LT_TAGVAR(lt_prog_compiler_pic, $1)='-KPIC' + _LT_TAGVAR(lt_prog_compiler_static, $1)='-Bstatic' + _LT_TAGVAR(lt_prog_compiler_wl, $1)='-Qoption ld ' + ;; *Sun\ C*) # Sun C 5.9 _LT_TAGVAR(lt_prog_compiler_pic, $1)='-KPIC'
Re: Libtool and CUDA
Hello Paweł, * Paweł Daniluk wrote on Sun, Dec 05, 2010 at 11:16:37PM CET: I am trying to run nvcc compiler driver through libtool, and I keep getting errors about compiler flags which are not supported by nvcc: pa...@solea:~/sandbox/libdesc/libdesc/trunk$ /opt/local/bin/glibtool --mode=compile --tag=CC nvcc -c -m64 -arch=sm_11 -g -DTIMER -Xcompiler -fno-common -I/usr/local/cuda/include/ -o cliques_cuda_int.lo cliques_cuda_int.cu glibtool: compile: nvcc -c -m64 -arch=sm_11 -g -fno-common -DTIMER -I/usr/local/cuda/include/ cliques_cuda_int.cu -fno-common -DPIC -o .libs/cliques_cuda_int.o nvcc fatal : Unknown option 'fno-common' This is understandable because -fno-common should be prepended with -Xcompiler in nvcc call. One would expect that libtool should do it automagically, since it has some kind of CUDA support built in. What am I doing wrong? Is there any method to override regular libtool behavior to put -Xcompiler before flags it adds? I'm using libtool 2.4 from MacPorts on Mac OS 10.6.5. Does this patch fix things for you? As far as I see, you should be getting -fPIC passed instead of -fno-common, so it's not completely clear that this is right, or what other changes MacPorts has done to their glibtool code over upstream Libtool. Please also send 'glibtool --config' output. OK to apply? OK to add you to THANKS, Paweł? Thanks, Ralf Fix nvcc PIC setting on darwin. * libltdl/m4/libtool.m4 (_LT_COMPILER_PIC) lt_prog_compiler_pic: Prepend -Xcompiler to nonempty variable setting rather than hard-coding -Xcompiler -fPIC, for darwin. * NEWS, THANKS: Update. Report by Paweł Daniluk. diff --git a/NEWS b/NEWS index 1679c58..d8fc3ea 100644 --- a/NEWS +++ b/NEWS @@ -18,6 +18,7 @@ New in 2.4.2 2010-12-??: git version 2.4.1a, Libtool team: not available) works again. Regression introduced in v2.2.6-39-g9c3d4d8. - The bug that leaked developer tool paths into the release tarballs from ./bootstrap is fixed. + - Improved support for the Cuda Compiler Driver (nvcc) on Darwin. * Important incompatible changes: diff --git a/libltdl/m4/libtool.m4 b/libltdl/m4/libtool.m4 index 99d66bb..5f18dcb 100644 --- a/libltdl/m4/libtool.m4 +++ b/libltdl/m4/libtool.m4 @@ -4240,7 +4240,9 @@ m4_if([$1], [CXX], [ case $cc_basename in nvcc*) # Cuda Compiler Driver 2.2 _LT_TAGVAR(lt_prog_compiler_wl, $1)='-Xlinker ' - _LT_TAGVAR(lt_prog_compiler_pic, $1)='-Xcompiler -fPIC' + if test -n $_LT_TAGVAR(lt_prog_compiler_pic, $1); then +_LT_TAGVAR(lt_prog_compiler_pic, $1)=-Xcompiler $_LT_TAGVAR(lt_prog_compiler_pic, $1) + fi ;; esac else
Re: Libtool and CUDA
Hi Peter, * Peter O'Gorman wrote on Mon, Dec 06, 2010 at 05:23:12AM CET: On 12/05/2010 09:34 PM, Ralf Wildenhues wrote: Does this patch fix things for you? As far as I see, you should be getting -fPIC passed instead of -fno-common, so it's not completely clear that this is right, or what other changes MacPorts has done to their glibtool code over upstream Libtool. Please also send 'glibtool --config' output. OK to apply? Unless Pawel reports that it works for him, no. This doesn't make sense to me. Why? MacPorts doesn't appear to have patched their libtool at all: http://trac.macports.org/browser/trunk/dports/devel/libtool/Portfile OK. The installed glibtool is quite certainly configured to use gcc not nvcc. If you configure libtool to use nvcc though, the current code would get '-Xcompiler -fPIC' on darwin. I only have nvcc.pdf from an older version that didn't provide documentation for MacOS installation, but it didn't mention PIC code at all, which is not too surprising given that the Cuda-specific parts don't care all that much about what happens on the CPU. So IMVHO it would make sense to just pass through the PIC flag to the underlying gcc compiler driver, whatever the flag is. What am I missing? Thanks, Ralf _LT_TAGVAR(lt_prog_compiler_wl, $1)='-Xlinker ' - _LT_TAGVAR(lt_prog_compiler_pic, $1)='-Xcompiler -fPIC' + if test -n $_LT_TAGVAR(lt_prog_compiler_pic, $1); then +_LT_TAGVAR(lt_prog_compiler_pic, $1)=-Xcompiler $_LT_TAGVAR(lt_prog_compiler_pic, $1) + fi
Re: ld: fatal: file .libs/libglib-2.0.exp: unknown file type
* Laviticus Stone wrote on Thu, Dec 02, 2010 at 08:53:40AM CET: On 12/ 2/10 02:37 AM, Ralf Wildenhues wrote: * Laviticus Stone wrote on Thu, Dec 02, 2010 at 01:45:04AM CET: Hi, i'm trying to compile glib-2.0 on Solaris 11 from netbsd pkgsrc. Libtool creates the following command and results: ld: fatal: file .libs/libglib-2.0.exp: unknown file type ld: fatal: file processing errors. No output written to .libs/libglib-2.0.so.0.2600.1 collect2: ld returned 1 exit status Somehow libtool seems to think you're using GNU ld but apparently you're not. Please send output of ./libtool --version ./libtool --config Ah yes, netbsd's pkgsrc is configured for LD=ld I imagine it was finding gnu lsd, which was in the search path, and assumign gnu ld, yet the gcc command it was issuing was using the solaris ld in /usr/ccs/bin. ps up to date pkgsrc is ltmain.sh (GNU libtool) 2.2.6b So I gather you can fix/work around your issues by installing a local Libtool, rebuilding the pkgsrc one with an absolute LD=/path/to/ld as configure argument, or by adjusting your PATH to find the ld that was found at the time the pkgsrc Libtool was built. Right? Thanks, Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Libtools for Win7-64
Hello Arbol, * Arbol One wrote on Sun, Dec 05, 2010 at 11:47:51PM CET: Does anyone know if there is a libtool's port to Win7-64. First off, welcome to this list. Please do not top-post nor full-quote here, also please do not reply to existing threads with new topics; rather, start a new thread for a new topic, and keep on a thread for an existing one. Thank you. Libtool has been ported to work on MinGW-w64, if that's what you mean. As far as I know, MinGW-w64 works on Win7. So yes, Libtool should work on Win7-64 already. But maybe you mean to run it in Cygwin; that also should work on 64bit Windows. Cheers, Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Libtool and CUDA
Hello Paweł, * Paweł Daniluk wrote on Sun, Dec 05, 2010 at 11:16:37PM CET: I am trying to run nvcc compiler driver through libtool, and I keep getting errors about compiler flags which are not supported by nvcc: pa...@solea:~/sandbox/libdesc/libdesc/trunk$ /opt/local/bin/glibtool --mode=compile --tag=CC nvcc -c -m64 -arch=sm_11 -g -DTIMER -Xcompiler -fno-common -I/usr/local/cuda/include/ -o cliques_cuda_int.lo cliques_cuda_int.cu glibtool: compile: nvcc -c -m64 -arch=sm_11 -g -fno-common -DTIMER -I/usr/local/cuda/include/ cliques_cuda_int.cu -fno-common -DPIC -o .libs/cliques_cuda_int.o nvcc fatal : Unknown option 'fno-common' This is understandable because -fno-common should be prepended with -Xcompiler in nvcc call. One would expect that libtool should do it automagically, since it has some kind of CUDA support built in. What am I doing wrong? Is there any method to override regular libtool behavior to put -Xcompiler before flags it adds? I'm using libtool 2.4 from MacPorts on Mac OS 10.6.5. Does this patch fix things for you? As far as I see, you should be getting -fPIC passed instead of -fno-common, so it's not completely clear that this is right, or what other changes MacPorts has done to their glibtool code over upstream Libtool. Please also send 'glibtool --config' output. OK to apply? OK to add you to THANKS, Paweł? Thanks, Ralf Fix nvcc PIC setting on darwin. * libltdl/m4/libtool.m4 (_LT_COMPILER_PIC) lt_prog_compiler_pic: Prepend -Xcompiler to nonempty variable setting rather than hard-coding -Xcompiler -fPIC, for darwin. * NEWS, THANKS: Update. Report by Paweł Daniluk. diff --git a/NEWS b/NEWS index 1679c58..d8fc3ea 100644 --- a/NEWS +++ b/NEWS @@ -18,6 +18,7 @@ New in 2.4.2 2010-12-??: git version 2.4.1a, Libtool team: not available) works again. Regression introduced in v2.2.6-39-g9c3d4d8. - The bug that leaked developer tool paths into the release tarballs from ./bootstrap is fixed. + - Improved support for the Cuda Compiler Driver (nvcc) on Darwin. * Important incompatible changes: diff --git a/libltdl/m4/libtool.m4 b/libltdl/m4/libtool.m4 index 99d66bb..5f18dcb 100644 --- a/libltdl/m4/libtool.m4 +++ b/libltdl/m4/libtool.m4 @@ -4240,7 +4240,9 @@ m4_if([$1], [CXX], [ case $cc_basename in nvcc*) # Cuda Compiler Driver 2.2 _LT_TAGVAR(lt_prog_compiler_wl, $1)='-Xlinker ' - _LT_TAGVAR(lt_prog_compiler_pic, $1)='-Xcompiler -fPIC' + if test -n $_LT_TAGVAR(lt_prog_compiler_pic, $1); then +_LT_TAGVAR(lt_prog_compiler_pic, $1)=-Xcompiler $_LT_TAGVAR(lt_prog_compiler_pic, $1) + fi ;; esac else ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Libtool and CUDA
Hi Peter, * Peter O'Gorman wrote on Mon, Dec 06, 2010 at 05:23:12AM CET: On 12/05/2010 09:34 PM, Ralf Wildenhues wrote: Does this patch fix things for you? As far as I see, you should be getting -fPIC passed instead of -fno-common, so it's not completely clear that this is right, or what other changes MacPorts has done to their glibtool code over upstream Libtool. Please also send 'glibtool --config' output. OK to apply? Unless Pawel reports that it works for him, no. This doesn't make sense to me. Why? MacPorts doesn't appear to have patched their libtool at all: http://trac.macports.org/browser/trunk/dports/devel/libtool/Portfile OK. The installed glibtool is quite certainly configured to use gcc not nvcc. If you configure libtool to use nvcc though, the current code would get '-Xcompiler -fPIC' on darwin. I only have nvcc.pdf from an older version that didn't provide documentation for MacOS installation, but it didn't mention PIC code at all, which is not too surprising given that the Cuda-specific parts don't care all that much about what happens on the CPU. So IMVHO it would make sense to just pass through the PIC flag to the underlying gcc compiler driver, whatever the flag is. What am I missing? Thanks, Ralf _LT_TAGVAR(lt_prog_compiler_wl, $1)='-Xlinker ' - _LT_TAGVAR(lt_prog_compiler_pic, $1)='-Xcompiler -fPIC' + if test -n $_LT_TAGVAR(lt_prog_compiler_pic, $1); then +_LT_TAGVAR(lt_prog_compiler_pic, $1)=-Xcompiler $_LT_TAGVAR(lt_prog_compiler_pic, $1) + fi ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Version mismatch error
Hello Dan, * Dan Nicholson wrote on Fri, Dec 03, 2010 at 02:43:04PM CET: On Wed, Oct 20, 2010 at 10:49 AM, Ralf Wildenhues wrote: Depending on your package setup, that means either passing --install to libtoolize (when AC_CONFIG_MACRO_DIR has been set in configure.ac), or running aclocal with flags set so that it finds the right Libtool macros (either by some -I include-path, or setting the path in the dirlist file of the aclocal installation), or possibly hand-copying macro files or file contents to your aclocal.m4 file. Details are documented in the manual. It would nice if libtoolize when run without --install (e.g. when run by autoreconf without --install) would detect that ltmain.sh and libtool.m4 are out of sync and error. One of the most common autotools errors I see is that people run bare autoreconf and things break strangely (to them) some time later. What do you think? If we can do a warning or error reliably, then I'm all for it. I don't think it can be done in libtoolize though, because aclocal may be called afterwards and fix things up. autoreconf might call libtoolize with some special --check argument or so, to tell it that aclocal --install won't be called afterwards. Putting the warning into automake seems possible but an ugly hack. We could put a check into autoreconf, but then non-autoreconf users wouldn't get the extra safety. It's not easy. :-/ Cheers, Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Enhanced OS/2 port
Hello, * KO Myung-Hun wrote on Wed, Dec 01, 2010 at 09:24:56AM CET: I've enhanced and fixed libtool 2.4 for OS/2. Review, please. Ping ? Thanks for your patch, and sorry for the delay. I'm very busy ATM but I will try to review it by next week. It needs some more work. Also, patches should generally be sent to the libtool-patches list. Thanks, Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: ld: fatal: file .libs/libglib-2.0.exp: unknown file type
Hello Laviticus, * Laviticus Stone wrote on Thu, Dec 02, 2010 at 01:45:04AM CET: Hi, i'm trying to compile glib-2.0 on Solaris 11 from netbsd pkgsrc. Libtool creates the following command and results: gcc -shared .libs/garray.o .libs/gasyncqueue.o .libs/gatomic.o [...] .libs/giounix.o .libs/gspawn.o -Wl,--whole-archive libcharset/.libs/libcharset.a -Wl,--no-whole-archive -Wl,-rpath -Wl,/usr/pkgsrc/devel/glib2/work/.buildlink/lib -Wl,-rpath -Wl,/usr/pkgsrc/devel/glib2/work/.buildlink/lib -L/usr/pkgsrc/devel/glib2/work/.buildlink/lib /usr/pkgsrc/devel/glib2/work/.buildlink/lib/libpcre.so /usr/pkgsrc/devel/glib2/work/.buildlink/lib/libintl.so /usr/pkgsrc/devel/glib2/work/.buildlink/lib/libiconv.so -lc -lnsl -lsocket -lc -Wl,-R/usr/pkg/lib -Wl,-soname -Wl,libglib-2.0.so.0 -Wl,-retain-symbols-file -Wl,.libs/libglib-2.0.exp -o .libs/libglib-2.0.so.0.2600.1 ld: fatal: file .libs/libglib-2.0.exp: unknown file type ld: fatal: file processing errors. No output written to .libs/libglib-2.0.so.0.2600.1 collect2: ld returned 1 exit status Somehow libtool seems to think you're using GNU ld but apparently you're not. Please send output of ./libtool --version ./libtool --config Thanks, Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool
docs: Libtool configuration diagram.
Ethan suggested we have a Libtool flow chart, similar to how Automake
has one in its manual.
Here we go. OK to commit?
Thanks,
Ralf
docs: Libtool configuration diagram.
* doc/libtool.texi (Integrating libtool): Add diagrams
explaining the dependencies between Libtool files.
Suggestion by Ethan Mallove.
diff --git a/doc/libtool.texi b/doc/libtool.texi
index 12d006b..04c5507 100644
--- a/doc/libtool.texi
+++ b/doc/libtool.texi
@@ -1791,6 +1791,56 @@ The remaining @var{mode-args} are either flags for the
deletion program
This chapter describes how to integrate libtool with your packages so
that your users can install hassle-free shared libraries.
+There are several ways in which Libtool may be integrated in your
+package, described in the following sections. Typically, the Libtool
+macro files as well as @file{ltmain.sh} are copied into your package
+using @command{libtoolize} and @command{aclocal} after setting up the
+...@file{configure.ac} and toplevel @file{Makefile.am}, then
+...@command{autoconf} adds the needed tests to the @file{configure} script.
+These individual steps are often automated with @command{autoreconf}.
+
+Here is a diagram showing how such a typical Libtool configuration works
+when preparing a package for distribution, assuming that @file{m4} has
+been chosen as location for additional Autoconf macros, and
+...@file{build-aux} as location for auxiliary build tools (@pxref{Input,,
+The Autoconf Manual, autoconf, The Autoconf Manual}):
+
+...@example
+...@group
+libtool.m4 -..-- aclocal.m4 -.
+ltoptions.m4 ---+ .- aclocal* -++-- autoconf*
+ltversion.m4 ---+--+ `-- [copy in m4/] --+ |
+ltsugar.m4 -+ |^ | \/
+lt~obsolete.m4 -+ +- libtoolize* -' |configure
+[ltdl.m4] --+ | |
+ `--'
+
+ltmain.sh --- libtoolize* - [copy in build-aux/]
+...@end group
+...@end example
+
+During configuration, the @file{libtool} script is generated either
+through @command{config.status} or @command{config.lt}:
+
+...@example
+...@group
+ .-- config.status* --.
+configure* --+ +-- libtool
+ `-- [config.lt*] ' ^
+ |
+ltmain.sh '
+...@end group
+...@end example
+
+At @command{make} run time, @command{libtool} is then invoked as needed
+as a wrapper around compilers, linkers, install and cleanup programs.
+
+There are alternatives choices to several parts of the setup; for
+example, the Libtool macro files can either be copied or symlinked into
+the package, or copied into @file{aclocal.m4}. As another example, an
+external, pre-configured @command{libtool} script may be used,
+by-passing most of the tests and package-specific setup for Libtool.
+
@menu
* Autoconf macros:: Autoconf macros exported by libtool.
* Makefile rules:: Writing @file{Makefile} rules for libtool.
Re: Oracle Solaris Studio 12.2 compiler incompatibility with libtool
* Terry Dontje wrote on Wed, Nov 17, 2010 at 01:00:26PM CET: On 11/16/2010 02:01 PM, Terry Dontje wrote: On 11/16/2010 01:56 PM, Ralf Wildenhues wrote: Thanks. Now the only remaining question is whether we still need to support that thing called 'Sun Ceres Fortran' here: http://www.open-mpi.org/community/lists/devel/2008/11/4932.php and if yes, whether that also supported '-Qoption ld' already, despite a hint to the contrary in that reference. Any chance one of you might know/remember this? Like a bad recurring nightmare :-). Note the f90 2009 compiler is the 8.4 where Ceres was 8.3. So from 8.4 on -Qoption is supported. I think we probably would want to still support Ceres but let me ask around. I've discussed this internally and yes we would like Ceres to be supported. Sorry, Oh, no problem. Presumably that means you have some way to test the proposed patch then with all the interesting compilers. That would be very nice. :-) Here it goes; it works with this (yes, very old) Sun Studio X.X on GNU/Linux installation; and yes, this is about GNU/Linux only. Thanks, Ralf 2010-11-18 Ralf Wildenhues ralf.wildenh...@gmx.de Fix $wl setting for Solaris Studio 12.2 f90 on GNU/Linux. * libltdl/m4/libtool.m4 (_LT_COMPILER_PIC) [linux] lt_prog_compiler_wl: Set to '-Qoption ld ' if we detect Sun Fortran version 8.4 or newer. Report by Terry Dontje. diff --git a/libltdl/m4/libtool.m4 b/libltdl/m4/libtool.m4 index 419ffe1..4a371c9 100644 --- a/libltdl/m4/libtool.m4 +++ b/libltdl/m4/libtool.m4 @@ -4324,12 +4324,17 @@ m4_if([$1], [CXX], [ ;; *) case `$CC -V 21 | sed 5q` in - *Sun\ F* | *Sun*Fortran*) + *Sun\ Ceres\ Fortran* | *Sun*Fortran*\ [[1-7]].* | *Sun*Fortran*\ 8.[[0-3]]*) # Sun Fortran 8.3 passes all unrecognized flags to the linker _LT_TAGVAR(lt_prog_compiler_pic, $1)='-KPIC' _LT_TAGVAR(lt_prog_compiler_static, $1)='-Bstatic' _LT_TAGVAR(lt_prog_compiler_wl, $1)='' ;; + *Sun\ F* | *Sun*Fortran*) + _LT_TAGVAR(lt_prog_compiler_pic, $1)='-KPIC' + _LT_TAGVAR(lt_prog_compiler_static, $1)='-Bstatic' + _LT_TAGVAR(lt_prog_compiler_wl, $1)='-Qoption ld ' + ;; *Sun\ C*) # Sun C 5.9 _LT_TAGVAR(lt_prog_compiler_pic, $1)='-KPIC'
[SCM] GNU Libtool branch, master, updated. v2.4-27-g4fee879
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project GNU Libtool.
The branch, master has been updated
via 4fee8796c92a2ab554eb6596330ac06613c22807 (commit)
from 8eb036bb129a5673dd6ada62075588424edf319a (commit)
Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.
- Log -
commit 4fee8796c92a2ab554eb6596330ac06613c22807
Author: Ralf Wildenhues ralf.wildenh...@gmx.de
Date: Mon Nov 15 23:13:33 2010 +0100
Eliminate hardcode_libdir_flag_spec_ld tag variable.
* libltdl/config/ltmain.m4sh (func_mode_link): Set $wl to empty
if $LD is used for creating shared libraries. Do not use
hardcode_libdir_flag_spec_ld any more.
* libltdl/m4/libtool.m4 (_LT_LINKER_SHLIBS, _LT_LANG_CXX_CONFIG)
(_LT_LANG_F77_CONFIG, _LT_LANG_FC_CONFIG, _LT_SYS_DYNAMIC_LINKER)
hardcode_libdir_flag_spec_ld: Remove all instances of the tag
variable.
(_LT_LINKER_SHLIBS) [linux, xlf] hardcode_libdir_flag_spec:
Set variable, including ${wl}. Fixes hardcoding in programs
created by XL Fortran on GNU/Linux.
* NEWS, THANKS: Update.
Report by Paul H. Hargrove.
Signed-off-by: Ralf Wildenhues ralf.wildenh...@gmx.de
---
Summary of changes:
ChangeLog | 14 ++
NEWS |9 +
libltdl/config/ltmain.m4sh | 11 ++-
libltdl/m4/libtool.m4 | 11 +--
4 files changed, 30 insertions(+), 15 deletions(-)
diff --git a/ChangeLog b/ChangeLog
index 89b2d52..e418f3c 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,5 +1,19 @@
2010-11-15 Ralf Wildenhues ralf.wildenh...@gmx.de
+ Eliminate hardcode_libdir_flag_spec_ld tag variable.
+ * libltdl/config/ltmain.m4sh (func_mode_link): Set $wl to empty
+ if $LD is used for creating shared libraries. Do not use
+ hardcode_libdir_flag_spec_ld any more.
+ * libltdl/m4/libtool.m4 (_LT_LINKER_SHLIBS, _LT_LANG_CXX_CONFIG)
+ (_LT_LANG_F77_CONFIG, _LT_LANG_FC_CONFIG, _LT_SYS_DYNAMIC_LINKER)
+ hardcode_libdir_flag_spec_ld: Remove all instances of the tag
+ variable.
+ (_LT_LINKER_SHLIBS) [linux, xlf] hardcode_libdir_flag_spec:
+ Set variable, including ${wl}. Fixes hardcoding in programs
+ created by XL Fortran on GNU/Linux.
+ * NEWS, THANKS: Update.
+ Report by Paul H. Hargrove.
+
Rebuild menus in the manual.
* doc/automake.texi: Rebuild menus (using ^C ^U ^A in emacs).
Thanks to Ian Lance Taylor for the suggestion.
diff --git a/NEWS b/NEWS
index 6930274..83cee5e 100644
--- a/NEWS
+++ b/NEWS
@@ -15,6 +15,15 @@ New in 2.4.2 2010-12-??: git version 2.4.1a, Libtool team:
- The bug that leaked developer tool paths into the release tarballs
from ./bootstrap is fixed.
+* Important incompatible changes:
+
+ - The undocumented hardcode_libdir_flag_spec_ld tag variable has been
+removed in favor of using hardcode_libdir_flag_spec with $wl set to empty.
+
+* Changes in supported systems or compilers:
+
+ - Fixes for gfortran on Darwin, XL Fortran on GNU/Linux.
+
New in 2.4 2010-09-22: git version 2.2.11a, Libtool team:
* New features:
diff --git a/libltdl/config/ltmain.m4sh b/libltdl/config/ltmain.m4sh
index af46cb8..aff8a1c 100644
--- a/libltdl/config/ltmain.m4sh
+++ b/libltdl/config/ltmain.m4sh
@@ -7237,6 +7237,11 @@ EOF
# Test again, we may have decided not to build it any more
if test $build_libtool_libs = yes; then
+ # Remove ${wl} instances when linking with ld.
+ # FIXME: should test the right _cmds variable.
+ case $archive_cmds in
+ *\$LD\ *) wl= ;;
+esac
if test $hardcode_into_libs = yes; then
# Hardcode the library paths
hardcode_libdirs=
@@ -7275,11 +7280,7 @@ EOF
if test -n $hardcode_libdir_separator
test -n $hardcode_libdirs; then
libdir=$hardcode_libdirs
- if test -n $hardcode_libdir_flag_spec_ld; then
- eval dep_rpath=\$hardcode_libdir_flag_spec_ld\
- else
- eval dep_rpath=\$hardcode_libdir_flag_spec\
- fi
+ eval dep_rpath=\$hardcode_libdir_flag_spec\
fi
if test -n $runpath_var test -n $perm_rpath; then
# We should set the runpath_var.
diff --git a/libltdl/m4/libtool.m4 b/libltdl/m4/libtool.m4
index d8b3a4d..419ffe1 100644
--- a/libltdl/m4/libtool.m4
+++ b/libltdl/m4/libtool.m4
@@ -4522,7 +4522,6 @@ m4_if([$1], [CXX], [
_LT_TAGVAR(hardcode_direct, $1)=no
_LT_TAGVAR(hardcode_direct_absolute, $1)=no
_LT_TAGVAR(hardcode_libdir_flag_spec, $1)=
- _LT_TAGVAR(hardcode_libdir_flag_spec_ld, $1
Re: LD_LIBRARY_PATH_64 on Solaris
http://thread.gmane.org/gmane.comp.gnu.libtool.patches/10909
* Ralf Wildenhues wrote on Sat, Oct 16, 2010 at 04:52:20PM CEST:
Handle auxiliary shared library path environment variables.
This patch lets libtool handle systems with more than one shared
library path variable, such as Solaris, HP-UX, IRIX. If the
libtool variable aux_shlibpath_var is set, then it names an
environment variable that, if set, overrides the environment
variable named by shlibpath_var. libtool takes care to set
$aux_shlibpath_var only if it is set already in the environment,
to avoid losing settings from $shlibpath_var.
* libltdl/config/ltmain.m4sh (func_mode_execute)
(func_mode_finish, func_exec_program, func_emit_cwrapperexe_src)
(func_mode_link): Handle $aux_shlibpath_var in addition to
$shlibpath_var, by setting the former if aux_shlibpath_var is
nonempty and the variable it names is set in the environment.
* libltdl/ltdl.c (try_dlopen): Honor LT_MODULE_AUX_PATH_VAR if
it is set and nonempty, and LT_MODULE_PATH_VAR only otherwise.
* libltdl/m4/libtool.m4 (_LT_SYS_DYNAMIC_LINKER)
aux_shlibpath_var: New _LT_DECL.
[hpux/hppa64]: Set shlibpath_var to SHLIB_PATH, aux_shlibpath_var
to LD_LIBRARY_PATH.
[irix]: Set shlibpath to LD_LIBRARY_PATH, aux_shlibpath_var to
LD_LIBRARY${shlibsuff}_PATH.
[solaris i386/x86_64]: Set aux_shlibpath_var to
LD_LIBRARY_PATH_{32,64} as appropriate.
* libltdl/m4/ltdl.m4 (LT_SYS_MODULE_PATH): New define
LT_MODULE_AUX_PATH_VAR, new cache variable
lt_cv_module_aux_path_var, set from aux_shlibpath_var.
* tests/shlibpath.at (aux_shlibpath_var): New test.
* NEWS: Update.
* doc/libtool.texi (libtool script contents): Document
aux_shlibpath_var. Adjust documentation for
hardcode_direct_absolute and hardcode_shlibpath_var.
Report by Paul H. Hargrove.
Any comments on this? There were several design decisions to be made in
this patch, a quick sanity check by somebody would be nice.
Thanks,
Ralf
Re: Eliminate hardcode_libdir_flag_spec_ld tag variable.
http://thread.gmane.org/gmane.comp.gnu.libtool.patches/10908
* Ralf Wildenhues wrote on Sat, Oct 16, 2010 at 03:22:22PM CEST:
Eliminate hardcode_libdir_flag_spec_ld tag variable.
* libltdl/config/ltmain.m4sh (func_mode_link): Set $wl to empty
if $LD is used for creating shared libraries. Do not use
hardcode_libdir_flag_spec_ld any more.
* libltdl/m4/libtool.m4 (_LT_LINKER_SHLIBS, _LT_LANG_CXX_CONFIG)
(_LT_LANG_F77_CONFIG, _LT_LANG_FC_CONFIG, _LT_SYS_DYNAMIC_LINKER)
hardcode_libdir_flag_spec_ld: Remove all instances of the tag
variable.
(_LT_LINKER_SHLIBS) [linux, xlf] hardcode_libdir_flag_spec:
Set variable, including ${wl}. Fixes hardcoding in programs
created by XL Fortran on GNU/Linux.
* NEWS, THANKS: Update.
Report by Paul H. Hargrove.
Any comments on this? I'll otherwise push soonish.
Thanks,
Ralf
Rebuild menus in the manual.
I would like to push this patch that has emacs-rebuilt menus.
They actually typeset a bit worse than the hand-written ones
(see e.g. the last hunk) but I think that doing something
automatically is better than doing it manually, and if there
is pain involved then we should consider trying to shorten the
names of the nodes in question. (If we do, we need to remember
to add entries to html_node/.symlinks in the web cvs, so the old
URLs remain valid.)
Opinions?
Thanks,
Ralf
Rebuild menus in the manual.
* doc/automake.texi: Rebuild menus (using ^C ^U ^A in emacs).
Thanks to Ian Lance Taylor for the suggestion.
diff --git a/doc/libtool.texi b/doc/libtool.texi
index 5c2570d..12d006b 100644
--- a/doc/libtool.texi
+++ b/doc/libtool.texi
@@ -100,7 +100,7 @@ GNU Libtool.
* FAQ:: Frequently Asked Questions
* Troubleshooting:: When libtool doesn't work as advertised.
* Maintaining:: Information used by the libtool maintainer.
-* GNU Free Documentation License:: License for this manual.
+* GNU Free Documentation License:: License for this manual.
* Combined Index:: Full index.
@detailmenu
@@ -127,7 +127,7 @@ Linking executables
* Wrapper executables:: Wrapper executables for some platforms.
-Invoking @code{libtool}
+Invoking @command{libtool}
* Compile mode::Creating library object files.
* Link mode:: Generating executables and libraries.
@@ -176,7 +176,7 @@ Dlopened modules
* Building modules::Creating dlopenable objects and libraries.
* Dlpreopening::Dlopening that works on static platforms.
-* Linking with dlopened modules:: Using dlopenable modules in libraries.
+* Linking with dlopened modules:: Using dlopenable modules in libraries.
* Finding the dlname:: Choosing the right file to @code{dlopen}.
* Dlopen issues:: Unresolved problems that need your attention.
@@ -189,7 +189,7 @@ Using libltdl
* Module loaders for libltdl:: Creating user defined module loaders.
* Distributing libltdl::How to distribute libltdl with your package.
-Frequently Asked Questions
+Frequently Asked Questions about libtool
* Stripped link flags:: Dropped flags when creating a library
@@ -200,7 +200,7 @@ Troubleshooting
The libtool test suite
-* Test descriptions:: The contents of the test suite.
+* Test descriptions:: The contents of the old test suite.
* When tests fail:: What to do when a test fails.
Maintenance notes for libtool
@@ -227,6 +227,15 @@ Platform quirks
* File name conversion::Converting file names between platforms.
* Windows DLLs::Windows header defines.
+File name conversion
+
+* File Name Conversion Failure:: What happens when file name conversion fails
+* Native MinGW File Name Conversion:: MSYS file name conversion idiosyncrasies
+* Cygwin/Windows File Name Conversion:: Using @command{cygpath} to convert
Cygwin file names
+* Unix/Windows File Name Conversion:: Using Wine to convert Unix paths
+* LT_CYGPATH:: Invoking @command{cygpath} from other
environments
+* Cygwin to MinGW Cross:: Other notes concerning MinGW cross
+
@end detailmenu
@end menu
@@ -3347,7 +3356,7 @@ use libtool to generate dlopen-accessible modules.
@menu
* Building modules::Creating dlopenable objects and libraries.
* Dlpreopening::Dlopening that works on static platforms.
-* Linking with dlopened modules:: Using dlopenable modules in libraries.
+* Linking with dlopened modules:: Using dlopenable modules in libraries.
* Finding the dlname:: Choosing the right file to @code{dlopen}.
* Dlopen issues:: Unresolved problems that need your attention.
@end menu
@@ -6069,12 +6078,12 @@ See @pxref{Unix/Windows File Name Conversion} and
@pxref{LT_CYGPATH}.
@end multitable
@menu
-* File Name Conversion Failure::What happens when file name conversion
fails
-* Native MinGW File Name Conversion:: MSYS file name conversion
idiosyncrasies
-* Cygwin/Windows File Name Conversion:: Using @command{cygpath} to convert
Cygwin file names
-* Unix/Windows File Name Conversion:: Using Wine to convert Unix paths
-* LT_CYGPATH:: Invoking @command{cygpath} from other
environments
-* Cygwin to MinGW Cross:: Other notes concerning MinGW cross
+* File Name Conversion Failure:: What happens when file name conversion fails
+* Native MinGW File Name Conversion:: MSYS file name conversion idiosyncrasies
+* Cygwin/Windows File Name Conversion:: Using @command{cygpath} to convert
Cygwin file names
+* Unix/Windows File Name Conversion:: Using Wine to convert Unix paths
+* LT_CYGPATH:: Invoking @command{cygpath} from other
environments
+* Cygwin to MinGW Cross:: Other notes concerning MinGW cross
@end menu
[SCM] GNU Libtool branch, master, updated. v2.4-24-g5ca9b3e
This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project GNU Libtool. The branch, master has been updated via 5ca9b3ec6b8be1cdd9713845b3e7cf389cc17ae4 (commit) from 7a6ca6e6942ddad9f0dc95e8c6d32e062c9cedbc (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log - commit 5ca9b3ec6b8be1cdd9713845b3e7cf389cc17ae4 Author: Ralf Wildenhues ralf.wildenh...@gmx.de Date: Wed Nov 10 19:28:11 2010 +0100 Fix cwrapper test failure with --disable-static. * tests/cwrapper.at (cwrapper and installed shared libraries): Compile program source without libtool, so we can be sure a non-PIC object will be created. Signed-off-by: Ralf Wildenhues ralf.wildenh...@gmx.de --- Summary of changes: ChangeLog |7 +++ tests/cwrapper.at |3 +-- 2 files changed, 8 insertions(+), 2 deletions(-) diff --git a/ChangeLog b/ChangeLog index 5d1ec7c..9c169e0 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,3 +1,10 @@ +2010-11-10 Ralf Wildenhues ralf.wildenh...@gmx.de + + Fix cwrapper test failure with --disable-static. + * tests/cwrapper.at (cwrapper and installed shared libraries): + Compile program source without libtool, so we can be sure a + non-PIC object will be created. + 2010-11-01 Peter Rosin p...@lysator.liu.se docs: Windows DLLs and headers. diff --git a/tests/cwrapper.at b/tests/cwrapper.at index 6e8cf3c..0e5ecb7 100644 --- a/tests/cwrapper.at +++ b/tests/cwrapper.at @@ -249,8 +249,7 @@ int main (void) } ]]) -AT_CHECK([$LIBTOOL --mode=compile --tag=CC $CC $CPPFLAGS $CFLAGS -c m.c], - [], [ignore], [ignore]) +AT_CHECK([$CC $CPPFLAGS $CFLAGS -c m.c], [], [ignore], [ignore]) AT_CHECK([$LIBTOOL --mode=link $CC $CFLAGS $LDFLAGS -o m1$EXEEXT m.$OBJEXT foo/liba.la], [], [ignore], [ignore]) hooks/post-receive -- GNU Libtool
[SCM] GNU Libtool branch, master, updated. v2.4-25-g2a736ed
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project GNU Libtool.
The branch, master has been updated
via 2a736edf3ee2432e204157f7d535afc09bb53e36 (commit)
from 5ca9b3ec6b8be1cdd9713845b3e7cf389cc17ae4 (commit)
Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.
- Log -
commit 2a736edf3ee2432e204157f7d535afc09bb53e36
Author: Ollie Wild a...@google.com
Date: Wed Nov 10 21:06:50 2010 +0100
Modify --with-pic to support per-package configurations.
* libltdl/m4/libtool.m4: Modify --with-pic to accept a list of
package names. Modelled off --enable-shared.
* tests/with-pic.at: New test.
* Makefile.am (TESTSUITE_AT): Add tests/with-pic.at.
* doc/libtool.texi (LT_INIT): Enhance documentation of
--with-pic configure flag.
* NEWS (New features): Mention that --with-pic now accepts a
comma-separated list of package names.
Signed-off-by: Ralf Wildenhues ralf.wildenh...@gmx.de
---
Summary of changes:
ChangeLog | 12 +
Makefile.am|1 +
NEWS |6
doc/libtool.texi | 17 ++--
libltdl/m4/ltoptions.m4| 19 -
tests/{pic_flag.at = with-pic.at} | 49 +---
6 files changed, 73 insertions(+), 31 deletions(-)
copy tests/{pic_flag.at = with-pic.at} (50%)
diff --git a/ChangeLog b/ChangeLog
index 9c169e0..97b9448 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,15 @@
+2010-11-07 Ollie Wild a...@google.com
+
+ Modify --with-pic to support per-package configurations.
+ * libltdl/m4/libtool.m4: Modify --with-pic to accept a list of
+ package names. Modelled off --enable-shared.
+ * tests/with-pic.at: New test.
+ * Makefile.am (TESTSUITE_AT): Add tests/with-pic.at.
+ * doc/libtool.texi (LT_INIT): Enhance documentation of
+ --with-pic configure flag.
+ * NEWS (New features): Mention that --with-pic now accepts a
+ comma-separated list of package names.
+
2010-11-10 Ralf Wildenhues ralf.wildenh...@gmx.de
Fix cwrapper test failure with --disable-static.
diff --git a/Makefile.am b/Makefile.am
index db2c0a9..66f38b1 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -502,6 +502,7 @@ TESTSUITE_AT= tests/testsuite.at \
tests/ctor.at \
tests/exceptions.at \
tests/early-libtool.at \
+ tests/with-pic.at \
tests/no-executables.at \
tests/deplibs-ident.at \
tests/configure-iface.at \
diff --git a/NEWS b/NEWS
index d8d692e..6930274 100644
--- a/NEWS
+++ b/NEWS
@@ -2,6 +2,12 @@ NEWS - list of user-visible changes between releases of GNU
Libtool
New in 2.4.2 2010-12-??: git version 2.4.1a, Libtool team:
+* New features:
+
+ - The --with-pic configure option now supports a list of comma-separated
+package names. This can be used to build some static libraries with PIC
+objects while building others with non-PIC objects.
+
* Bug fixes:
- The generic approximation of the command line length limit (when getconf is
diff --git a/doc/libtool.texi b/doc/libtool.texi
index 2f48a09..5c2570d 100644
--- a/doc/libtool.texi
+++ b/doc/libtool.texi
@@ -2042,9 +2042,10 @@ LT_PREREQ([...@value{version}])
@defmac LT_INIT (@var{options})
@defmacx AC_PROG_LIBTOOL
@defmacx AM_PROG_LIBTOOL
-Add support for the @option{--enable-shared} and @option{--disable-shared}
-...@code{configure} fla...@footnote{@code{LT_INIT} requires that
-you define the @file{Makefile} variable @code{top_builddir} in your
+Add support for the @option{--enable-shared}, @option{--disable-shared},
+...@option{--enable-static}, @option{--disable-static}, @option{--with-pic},
and
+...@option{--without-pic} @code{configure} fla...@footnote{@code{LT_INIT}
requires
+that you define the @file{Makefile} variable @code{top_builddir} in your
@file{Makefile.in}. Automake does this automatically, but Autoconf
users should set it to the relative path to the top of your build
directory (@file{../..}, for example).} @code{AC_PROG_LIBTOOL} and
@@ -2086,6 +2087,16 @@ behaves similarly, but it uses @option{--enable-static}
and
The package name @samp{default} matches any packages that have not set
their name in the @code{PACKAGE} environment variable.
+The @option{--with-pic} and @option{--without-pic} configure flags can be used
+to specify whether or not @command{libtool} uses PIC objects. By default,
+...@command{libtool} uses PIC objects for shared libraries and non-PIC objects
for
+static
Fix cwrapper test failure with --disable-static.
http://hydra.nixos.org/build/737077/log/raw shows among others (some of which are NixOS and not Libtool issues) the following failure: libtool: compile: gcc -g -O2 -c m.c -fPIC -DPIC -o .libs/m.o ./cwrapper.at:255: $LIBTOOL --mode=link $CC $CFLAGS $LDFLAGS -o m1$EXEEXT m.$OBJEXT foo/liba.la stderr: gcc: m.o: No such file or directory stdout: libtool: link: gcc -g -O2 -o .libs/m1 m.o foo/.libs/liba.so -Wl,-rpath -Wl,/tmp/nix-build-j7dzmn77cw5yzw9l6d48fdqv4q18mjy0-libtool-2.4.1a.drv-0/libtool-2.4.1a/tests/testsuite.dir/057/inst/lib ./cwrapper.at:255: exit code was 1, expected 0 57. cwrapper.at:201: 57. cwrapper and installed shared libraries (cwrapper.at:201): FAILED (cwrapper.at:255) which should be fixed by the patch below, which I'm pushing as obvious. Thanks, Ralf Fix cwrapper test failure with --disable-static. * tests/cwrapper.at (cwrapper and installed shared libraries): Compile program source without libtool, so we can be sure a non-PIC object will be created. diff --git a/tests/cwrapper.at b/tests/cwrapper.at index 6e8cf3c..0e5ecb7 100644 --- a/tests/cwrapper.at +++ b/tests/cwrapper.at @@ -249,8 +249,7 @@ int main (void) } ]]) -AT_CHECK([$LIBTOOL --mode=compile --tag=CC $CC $CPPFLAGS $CFLAGS -c m.c], - [], [ignore], [ignore]) +AT_CHECK([$CC $CPPFLAGS $CFLAGS -c m.c], [], [ignore], [ignore]) AT_CHECK([$LIBTOOL --mode=link $CC $CFLAGS $LDFLAGS -o m1$EXEEXT m.$OBJEXT foo/liba.la], [], [ignore], [ignore])
Re: Fix cwrapper test failure with --disable-static.
Hi Charles, * Charles Wilson wrote on Wed, Nov 10, 2010 at 09:46:54PM CET: On 11/10/2010 1:29 PM, Ralf Wildenhues wrote: -AT_CHECK([$LIBTOOL --mode=compile --tag=CC $CC $CPPFLAGS $CFLAGS -c m.c], - [], [ignore], [ignore]) +AT_CHECK([$CC $CPPFLAGS $CFLAGS -c m.c], [], [ignore], [ignore]) AT_CHECK([$LIBTOOL --mode=link $CC $CFLAGS $LDFLAGS -o m1$EXEEXT m.$OBJEXT foo/liba.la], [], [ignore], [ignore]) Wouldn't a better fix be to change the link command to reference m.lo instead of m.$OBJEXT ? That would be an alternative, but it would mean that we (needlessly) use PIC code on systems where non-PIC is turned off by default (or --disable-static was used). automake-generated code also compiles program sources without libtool, so the change was, to me, the canonical one. Is there a portability issue associated with it? Thanks, Ralf
Re: Problem with deplibs
Hello Bruno, * Bruno Barberi Gnecco wrote on Tue, Nov 09, 2010 at 08:47:08PM CET: I'm facing a problem compiling a library with libtool (via automake/autoconf). It depends on OpenCV, and deplibs links against all indirect libraries as well (that is, it adds the libs such as /usr/lib64/libhighgui.so /usr/lib64/libgthread-2.0.so /usr/lib64/libgtk-x11-2.0.so /usr/lib64/libgdk-x11-2.0.so). For some reason this breaks the application (don't ask me why, the cameras just stop working). All I need is to link only against the libraries I specify. I though link_all_deplibs=no in configure.in would achieve this, but it has no effect at all. You need to provide more information for us to be able to help. If I were you, I'd start trying to find out why additional DT_NEEDED entries would break an application. That usually only happens because incompatible library versions, or even multiple versions of a library, are linked in. Looking at make output, esp. the libtool --mode=link commands and all output they generate, can help here. In order to judge whether link_all_deplibs=no works or not, we'd need to see, in addition to said build output, probably also the contents of the created .la file, plus that of the .la files that belong to libraries that are linked in. This data is usually contained in the output of the --mode=link command with --debug added as first libtool argument (gzip large outputs). Also, './libtool --config' output is usually helpful. Hope that helps. Cheers, Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool
