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: [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: 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: 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: 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
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
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: [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: 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
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: 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
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
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: 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
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: 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
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'
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
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: ltmain.sh patch: -all-dynamic option
* Karl-Andre' Skevik wrote on Tue, Nov 02, 2010 at 09:26:33AM CET: Ralf Wildenhues writes: * Karl-Andre' Skevik wrote on Sat, Oct 30, 2010 at 11:46:38AM CEST: I have an application that builds a library for use with LD_PRELOAD, which should only be built dynamically. I have used a modification like the one below to achieve this: Thanks for the report and patch. What does -all-dynamic bring you that either of the following won't? - configure with --disable-static, The package also builds normal libraries that should be build both as static and dynamic, so this option can unfortunately not be used. OK. - add --tag=disable-static to AM_LIBTOOLFLAGS or libfoo_la_LIBTOOLFLAGS. At least with libtool 1.5.26 this does not appear to have any effect, a static library still gets built and installed. Libtool 1.5.26 is old, and the 1.5 branch not maintained any more. We have arrived at 2.4, please consider updating. That said, I *think* that this should have worked with 1.5.x already; but you need Automake = 1.10 for support of the *_LIBTOOLFLAGS special variables. I'm guessing that you have an older Automake, because the following minimal example gets me a libfoo that is not built statically. Please report whether it does for you, and if you get a static libfoo.a, please try to modify the example so it exposes the failure in your setup. Thanks, Ralf cat configure.ac \EOF AC_INIT([a], [1]) AM_INIT_AUTOMAKE([foreign]) AC_PROG_CC AC_PROG_LIBTOOL AC_CONFIG_FILES([Makefile]) AC_OUTPUT EOF cat Makefile.am \EOF lib_LTLIBRARIES = libfoo.la libfoo_la_LIBTOOLFLAGS = --tag=disable-static EOF : libfoo.c autoreconf -vi ./configure make make install
Re: [patch] allow --with-pic to accept package names
Hi Ollie,
* Ollie Wild wrote on Fri, Oct 22, 2010 at 06:32:08PM CEST:
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.
Peter, thanks for noticing the quoting bug. Updated patch attached.
Thanks. The patch still has the issues I described in
http://article.gmane.org/gmane.comp.gnu.libtool.patches/10924
Please indicate whether you are still working on any of those issues,
and which.
Thanks,
Ralf
2010-10-21 Ollie Wild a...@...
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.
diff --git a/libltdl/m4/ltoptions.m4 b/libltdl/m4/ltoptions.m4
index 17cfd51..160f7f2 100644
--- a/libltdl/m4/ltoptions.m4
+++ b/libltdl/m4/ltoptions.m4
@@ -326,9 +326,24 @@ dnl AC_DEFUN([AM_DISABLE_FAST_INSTALL], [])
# MODE is either `yes' or `no'. If omitted, it defaults to `both'.
m4_define([_LT_WITH_PIC],
[AC_ARG_WITH([pic],
-[AS_HELP_STRING([--with-pic],
+[AS_HELP_STRING([--with-pic@:@=PKGS@:@],
[try to use only PIC/non-PIC objects @:@default=use both@:@])],
-[pic_mode=$withval],
+[p=${PACKAGE-default}
+case $withval in
+yes|no) pic_mode=$withval ;;
+*)
+ pic_mode=default
+ # Look at the argument we got. We use all the common list separators.
+ lt_save_ifs=$IFS; IFS=${IFS}$PATH_SEPARATOR,
+ for pkg in $withval; do
+ IFS=$lt_save_ifs
+ if test X$pkg = X$p; then
+ pic_mode=yes
+ fi
+ done
+ IFS=$lt_save_ifs
+ ;;
+esac],
[pic_mode=default])
test -z $pic_mode pic_mode=m4_default([$1], [default])
Re: [patch] allow --with-pic to accept package names
* Ollie Wild wrote on Mon, Nov 01, 2010 at 09:55:36PM CET: On Mon, Nov 1, 2010 at 3:44 PM, Ralf Wildenhues wrote: * Ollie Wild wrote on Fri, Oct 22, 2010 at 06:32:08PM CEST: 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. Peter, thanks for noticing the quoting bug. Updated patch attached. Thanks. The patch still has the issues I described in http://article.gmane.org/gmane.comp.gnu.libtool.patches/10924 Please indicate whether you are still working on any of those issues, and which. Sorry, Ralf. I *am* working on this, but it's relatively low priority. At this point, I just need to update the documentation. I'll send a new patch later in the week. Oh, I certainly didn't want to sound pushing. Rather, as: just in case you are not working on this any more, please give us a heads-up so some volunteer can pick it up if she so likes. Sorry, Ralf
Re: [RFC] w32 and Libtool.
Hi Peter,
* Peter Rosin wrote on Sat, Oct 30, 2010 at 11:06:12PM CEST:
Den 2010-10-30 09:15 skrev Ralf Wildenhues:
* Peter Rosin wrote on Fri, Oct 29, 2010 at 10:00:34PM CEST:
+With contemporary GNU tools, auto-import often saves the day, but see
+the GNU ld documentation and its @code{--enable-auto-import} option for
+some corner cases when it does not.
This should have a cross reference to just that documentation.
...if I write:
With contemporary GNU tools, auto-import often saves the day, but see
the GNU ld documentation and its @code{--enable-auto-import} option
for some corner cases when it does not
(@pxref{Options, , --enable-auto-import, ld, The GNU linker})
that renders as:
With contemporary GNU tools, auto-import often saves the day, but see
the GNU ld documentation and its `--enable-auto-import' option for some
corner cases when it does not (*note -enable-auto-import: (ld)Options.)
with my info reader. Why is one dash eaten? Can I stop that from
happening? Should I care? (i.e. the link works, at least for me) And...
Have you tried using @option{--enable-auto-import} here? Please check
for all render forms (info, PDF, DVI, HTML) for whether they cope with
this correctly. The point is that '--' means a longer dash; see info
texinfo Conventions.
Please write as:
Examples are
@uref{http://alain.frisch.fr/@/flexdll.html, FlexDLL} and
@uref{http://edll.sourceforge.net/, edll}.
makeinfo should get the line breaking right by itself IMVHO.
...what's up with the extra @/ in your version? (just curious)
It allows an optional line break at this point:
info texinfo --index /
Regarding line breaking, both versions render similar to:
It should be noted that there are various projects that attempt to
relax these requirements by various low level tricks, but they are not
discussed here. Examples are FlexDLL
(http://alain.frisch.fr/flexdll.html) and edll
(http://edll.sourceforge.net/).
in my 80 column info reader. Which is not optimal IMVHO. :-/ Oh well.
One way around that is to simply reword the sentence. Surprisingly
often that works quite well without making things sound too stupid.
E.g.:
The interested reader may refer to the @uref{...} and ... projects
for more details.
Feel free to go ahead as you prefer.
Thanks,
Ralf
Re: [RFC] w32 and Libtool.
[ dropping libtool@ ]
Hi Peter,
* Peter Rosin wrote on Fri, Oct 29, 2010 at 10:00:34PM CEST:
This time as a patch. Ok to push, or did I screw up the texification?
Good with minor nits, but allow a day or so for comments from others.
Thanks!
Cheers,
Ralf
Subject: [PATCH] docs: Windows DLLs and headers.
* doc/libtool.texi (Platform quirks): Add new subsection
'Windows DLLs'.
--- a/doc/libtool.texi
+++ b/doc/libtool.texi
@@ -6321,6 +6323,194 @@ the source or build directory trees, and all
@option{-M*} options to
This is quite a fragile setup, but it has been in historical use, and so is
documented here.
+...@node Windows DLLs
+...@subsection Windows DLLs
+...@cindex Windows DLLs
+
+This topic describes a couple of ways to portably create Windows Dynamic
+Link Libraries (DLLs). Libtool knows how to create DLLs using GNU tools
+and using Microsoft tools.
+
+A typical library has a hidden implementation with an interface
Double quotes render ugly in PDF except in code bits, prefer ``hidden''
if you need to use quoting.
+described in a header file. On just about every system, the interface
+could be something like this:
+
+Example @file{foo.h}:
+
+...@example
+#ifndef FOO_H
+#define FOO_H
+
+int one (void);
+int two (void);
+extern int three;
+
+#endif /* FOO_H */
+...@end example
+
+And the implementation could be something like this:
@noindent here (before And on a line by itself)? I'm not sure.
+Example @file{foo.c}:
+
+...@example
+#include foo.h
+
+int one (void)
+...@{
+ return 1;
+...@}
+
+int two (void)
+...@{
+ return three - one ();
+...@}
+
+int three = 3;
+...@end example
+
+When using contemporary GNU tools to create the Windows DLL, the above
+code will work there too, thanks to its auto-import/auto-export
+features. But that is not the case when using older GNU tools or perhaps
+more interesting when using proprietary tools. In those cases the code
interestingly?
+will need additional decorations on the interface symbols with
+...@code{__declspec(dllimport)} and @code{__declspec(dllexport)} depending
+on if the library is built or if it's consumed and how it's built and
s/on if/on whether/; s/or if/or/ ?
+consumed. However, it should be noted that it would have worked also
s/\. / /
+with Microsoft tools, if only the variable three hadn't been there, due
@code{three}
+to the fact the Microsoft tools will automatically import functions (but
+sadly not variables) and Libtool will automatically export non-static
+symbols as described next.
+
+With Microsoft tools, Libtool will dig through the object files that
+make up the library, looking for non-static symbols to automatically
+export. I.e., Libtool with Microsoft tools is trying to mimic the auto-
+export feature of the contemporary GNU tools. It should be noted that
+the GNU auto-export feature is turned off when an explicit
+...@code{__declspec(dllexport)} is seen. The GNU tools do this to not make
+more symbols visible for projects that have already taken the trouble to
present tense here?
+decorate symbols. There is no similar way to limit which symbols are
+visible in the code when Libtool is using Microsoft tools. In order to
+limit symbol visibility in that case you need to use one of the options
+...@option{-export-symbols} or @option{-export-symbols-regex}.
+
+No matching help with auto-import is provided by Libtool, which is why
+variables must be decorated to import them from a DLL for everything but
+contemporary GNU tools. As stated above, functions are automatically
+imported by both contemporary GNU tools and Microsoft tools, but for
+other proprietary tools the auto-import status of functions is unknown.
+
+When the objects that form the library are built, there are generally
+two copies built for each object. One copy is used when linking the DLL
+and one copy is used for the static library. On Windows systems, a pair
+of defines are commonly used to discriminate how the interface symbols
+should be decorated. The first define is @samp{-DDLL_EXPORT} which is
+automatically provided by Libtool when Libtool builds the copy of the
The second Libtool should most likely be @command{libtool} instead, as
you're pretty clearly speaking about the command and not behavior of the
whole package. I think.
+object that is destined for the DLL. The second define is
+...@samp{-dlibfoo_build} (or similar) which is often added by the package
+providing the library and is used when building the library, but not
+when consuming the library.
+
+However, the matching double compile is not performed when consuming
+libraries. It is therefore not possible to reliably distinguish if the
+consumer is importing from a DLL or if it is going to use a static
+library.
+
+With contemporary GNU tools, auto-import often saves the day, but see
+the GNU ld documentation and its @code{--enable-auto-import} option
Re: libtool-2.2.10: print vs. printf
[ dropping libtool@ ]
Hi Markus,
* Markus Duft wrote on Thu, Oct 28, 2010 at 10:42:46AM CEST:
On 10/27/2010 08:13 PM, Ralf Wildenhues wrote:
oh, well - good to know that ;) is there some documentation i can
refer to wrt to this requirement? it seems we need to adapt some
things, as this was not the case with previous versions - and i
need to argue the need to do the work ;)
Good point actually. We don't currently have such documentation.
The Autoconf manual has some bits on $CONFIG_SHELL, but nothing
about the libtool script of course.
OK to fix that with the patch below, and add Markus to THANKS?
i'd additionally mention, that a shell mismatch can make libtool fail,
because of the print/printf mismatch. this is (AFAICT) the only thing
that really _breaks_ when the configure shell was a ksh, and the make
shell is a bash (at least for me).
No, that is not the only thing that breaks. Actually, for example on
Solaris, *lots* of other things will break as well. And we don't really
guarantee what breaks on what system and with which combination of
shells. So let me make the statement a wee bit stronger by squashing in
this diff. Hope that is enough.
I've pushed the combined patch now, since there were no more comments.
Thanks,
Ralf
--- a/doc/libtool.texi
+++ b/doc/libtool.texi
@@ -1330,7 +1330,8 @@ The current @command{libtool} implementation is done with
a shell script
that needs to be invoked by the shell which @command{configure} chose for
configuring @command{libtool} (@pxref{config.status Invocation, , The
Autoconf Manual, autoconf, The Autoconf Manual}). This shell is set in
-the she-bang (@samp{#!}) line of the @command{libtool} script.
+the she-bang (@samp{#!}) line of the @command{libtool} script. Using a
+different shell may cause undefined behavior.
The @var{mode-args} are a variable number of arguments, depending on the
selected operation mode. In general, each @var{mode-arg} is interpreted
Re: libtool-2.2.10: print vs. printf
Hi Markus.
* Markus Duft wrote on Wed, Oct 27, 2010 at 09:13:17AM CEST:
On 10/23/2010 09:16 AM, Ralf Wildenhues wrote:
* Markus Duft wrote on Fri, Oct 22, 2010 at 09:59:27AM CEST:
or am i wrong, and it is specified, that the shells that configure and
make use have to be the same?
Exactly. The bug is that the shell used during configure, and the shell
invoking libtool, are not the same. This bug can be caused by different
things, either you setting SHELL in Makefile.in, or SHELL or
CONFIG_SHELL in configure.ac, or something similar. We cannot tell
without more details.
oh, well - good to know that ;) is there some documentation i can refer to
wrt to this requirement? it seems we need to adapt some things, as this was
not the case with previous versions - and i need to argue the need to do the
work ;)
Good point actually. We don't currently have such documentation. The
Autoconf manual has some bits on $CONFIG_SHELL, but nothing about the
libtool script of course.
OK to fix that with the patch below, and add Markus to THANKS?
Thanks,
Ralf
docs: mention shell requirement for libtool script.
* doc/libtool.texi (Invoking libtool): Document that the shell
used to invoke libtool needs to be the same used to configure
it.
* THANKS: Update.
Report by Markus Duft.
diff --git a/doc/libtool.texi b/doc/libtool.texi
index 076b67b..c84b92a 100644
--- a/doc/libtool.texi
+++ b/doc/libtool.texi
@@ -1326,6 +1326,12 @@ can be achieved using either option @option{-v} or option
Print libtool version information and exit.
@end table
+The current @command{libtool} implementation is done with a shell script
+that needs to be invoked by the shell which @command{configure} chose for
+configuring @command{libtool} (@pxref{config.status Invocation, , The
+Autoconf Manual, autoconf, The Autoconf Manual}). This shell is set in
+the she-bang (@samp{#!}) line of the @command{libtool} script.
+
The @var{mode-args} are a variable number of arguments, depending on the
selected operation mode. In general, each @var{mode-arg} is interpreted
by programs libtool invokes, rather than libtool itself.
Re: [patch] allow --with-pic to accept package names
Hello Ollie,
* Ollie Wild wrote on Fri, Oct 22, 2010 at 06:32:08PM CEST:
2010-10-21 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.
This patch looks ok but it uses $pkg and $p which are not in Libtool's
name space, and it lacks updates to NEWS, libtool.texi, and the test
suite. Oh yes, the --enable-shared code has similar problems, but a
patch shouldn't be held hostage for drive-by bugs. ;-)
Seriously though, if you need help with any of the remaining issues
please ping us.
Thanks,
Ralf
--- a/libltdl/m4/ltoptions.m4
+++ b/libltdl/m4/ltoptions.m4
@@ -326,9 +326,24 @@ dnl AC_DEFUN([AM_DISABLE_FAST_INSTALL], [])
# MODE is either `yes' or `no'. If omitted, it defaults to `both'.
m4_define([_LT_WITH_PIC],
[AC_ARG_WITH([pic],
-[AS_HELP_STRING([--with-pic],
+[AS_HELP_STRING([--with-pic@:@=PKGS@:@],
[try to use only PIC/non-PIC objects @:@default=use both@:@])],
-[pic_mode=$withval],
+[p=${PACKAGE-default}
+case $withval in
+yes|no) pic_mode=$withval ;;
+*)
+ pic_mode=default
+ # Look at the argument we got. We use all the common list separators.
+ lt_save_ifs=$IFS; IFS=${IFS}$PATH_SEPARATOR,
+ for pkg in $withval; do
+ IFS=$lt_save_ifs
+ if test X$pkg = X$p; then
+ pic_mode=yes
+ fi
+ done
+ IFS=$lt_save_ifs
+ ;;
+esac],
[pic_mode=default])
test -z $pic_mode pic_mode=m4_default([$1], [default])
Eliminate hardcode_libdir_flag_spec_ld tag variable. (was: [OMPI devel] make check (libtool) failure on Linux/ppc w/ XLC (1.5rc5 and 1.4.3rc1))
[ moving to the libtool-patches list from here:
http://www.open-mpi.org/community/lists/devel/2010/08/8399.php ]
* Ralf Wildenhues wrote on Thu, Oct 14, 2010 at 08:56:19PM CEST:
this bug has been addressed in upstream Libtool commit
v2.2.6-59-gb7dbec6:
http://git.savannah.gnu.org/cgit/libtool.git/commit/?id=v2.2.6-59-gb7dbec6
It is not wholly fixed yet, but for all cases interesting to OpenMPI.
(A libtoolized package using only Fortran but no C compiler may still
have issues.)
Not totally true; since C will be enabled by libtool anyway, we are
fairly safe here (as the test will be run with the C compiler then, and
not rerun with Fortran due to caching).
However, we should fix setting hardcode_libdir_flag_spec for XL Fortran
on GNU/Linux anyway, and for that we need to ensure $wl is unset in the
shared library creation code in ltmain. The patch below does that and
eliminates the need for hardcode_libdir_flag_spec_ld in the process.
This should also help when hardcoding flags in programs created by this
compiler.
The idea is that, if $archive_cmds contains the string `$LD ' literally,
then we are going to link with ld, and $wl can be nullified.
Warning 1: this also nullifies $wl for all following tag variable
expansions in the ltmain code. I *think* this is safe, as by this time
all we're going to do is create a shared library; but I'm not 100% sure.
(OTOH, the number of systems where $LD is used for linking is pretty low
in practice by now.)
Warning 2: we might be creating the library with either one of
archive_cmds
archive_expsym_cmds
module_cmds
module_expsym_cmds
but the code only checks the former, rather the one that really will be
selected later. Should I fix that, for future-proofness in case we ever
have the case where module creation differs from archive creation in
whether $LD is used directly for linking? (Sounds fairly remote,
right?)
Tested on GNU/Linux/ppc with the XL compiler suite, as well as on
HP-UX 10.20 (no regressions in the latter).
OK to commit and add Paul to THANKS?
Thanks,
Ralf
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.
diff --git a/NEWS b/NEWS
index d8d692e..9c12714 100644
--- a/NEWS
+++ b/NEWS
@@ -9,6 +9,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)=
_LT_TAGVAR(hardcode_libdir_separator, $1)=
_LT_TAGVAR(hardcode_minus_L, $1
LD_LIBRARY_PATH_64 on Solaris (was: [OMPI devel] make check (libtool?) failure on Solaris/SPARC (1.5rc5 and 1.4.3rc1))
], + [], [ignore], [ignore]) + AT_CHECK([mv inst/lib inst/lib$n]) +done +$CC $CPPFLAGS $CFLAGS -c main.c +mv inst/lib1 inst/lib +AT_CHECK([$LIBTOOL --mode=link $CC $CFLAGS $LDFLAGS -no-install -o main$EXEEXT ]dnl +[main.$OBJEXT -Linst/lib -la], [], [ignore], [ignore]) +mv inst/lib inst/lib1 + +sep= +eval test -n \\$$shlibpath_var\ sep=: +auxsep= +eval test -n \\$$aux_shlibpath_var\ auxsep=: + +# Prerequisite: setting shlibpath_var can be used to actually find the library. +# We cannot use $LIBTOOL because we want to verify the semantics of the +# libtool.m4 settings and not rely on stuff inside the libtool script. +AT_CHECK([eval $shlibpath_var=\$inst/lib1\$sep\$$shlibpath_var ./main\$EXEEXT || exit 77], +[], [ignore], [ignore]) + +# Hypothesis: aux_shlibpath_var can be used to find the library. +AT_CHECK([eval $aux_shlibpath_var=\$inst/lib1\$auxsep\$$aux_shlibpath_var ./main\$EXEEXT], +[], [ignore], [ignore]) + +# Hypothesis: setting shlibpath_var or aux_shlibpath_var right is *necessary* +# to find the moved library. +AT_CHECK([./main\$EXEEXT || exit 1], [1], [ignore], [ignore]) +AT_CHECK([eval $shlibpath_var=\$inst/lib2\$sep\$$shlibpath_var ./main\$EXEEXT], +[42], [ignore], [ignore]) +AT_CHECK([eval $aux_shlibpath_var=\$inst/lib2\$auxsep\$$aux_shlibpath_var ./main\$EXEEXT], +[42], [ignore], [ignore]) + +# Hypothesis: aux_shlibpath_var, if set, overrides shlibpath_var. +AT_CHECK([eval $shlibpath_var=\$inst/lib2\$sep\$$shlibpath_var ]dnl +[ $aux_shlibpath_var=\$inst/lib1\$auxsep\$$aux_shlibpath_var ]dnl +[./main\$EXEEXT], [], [ignore], [ignore]) +AT_CHECK([eval $shlibpath_var=\$inst/lib1\$sep\$$shlibpath_var ]dnl +[ $aux_shlibpath_var=\$inst/lib2\$auxsep\$$aux_shlibpath_var ]dnl +[./main\$EXEEXT], [42], [ignore], [ignore]) + +# TODO: Semantics for dlopening. + +AT_CLEANUP Adjust existing testsuite tests for aux_shlibpath_var. * tests/demo/Makefile.am (hc-libpath): Also set $aux_shlibpath_var if appropriate. * tests/pdemo/Makefile.am (hc-libpath): Likewise. * tests/link-order2.at (Link order of deplibs): If $aux_shlibpath_var is set, prepend to that, instead of prepending to $shlibpath_var. * tests/shlibpath.at (shlibpath_overrides_runpath): Likewise. * tests/lt_dlopenext.at (lt_dlopenext error messages): Also try finding the variable by setting $aux_shlibpath_var if aux_shlibpath_var is nonempty. diff --git a/tests/demo/Makefile.am b/tests/demo/Makefile.am index a3c6144..8324f36 100644 --- a/tests/demo/Makefile.am +++ b/tests/demo/Makefile.am @@ -127,11 +127,15 @@ hc-libpath: $(hell_OBJECTS) $(hell_DEPENDENCIES) $(libdir)/libhello.la @rm -f hc-libpath @echo You may ignore any linking errors from the following command: @$(SET_HARDCODE_FLAGS); \ - eval `$(LIBTOOL) --config | grep '^shlibpath_var='`; \ + eval `$(LIBTOOL) --config | $(EGREP) '^(aux_)?shlibpath_var='`; \ + if test -z $$aux_shlibpath_var \ +|| eval test -z \\aux_shlibpath_var\; then \ + aux_shlibpath_var=innocent_var; \ + fi; \ libdir=$(libdir); \ flag=`eval echo \$$hardcode_libdir_flag_spec\`; \ - echo $$shlibpath_var=./$(objdir) $(CC) $(CFLAGS) $(LDFLAGS) -o $@ $(hell_OBJECTS) -lhello $(LIBS) $(LIBM) $$flag || echo unsupported $@; \ - eval $$shlibpath_var=./$(objdir) $(CC) $(CFLAGS) $(LDFLAGS) -o $@ $(hell_OBJECTS) -lhello $(LIBS) $(LIBM) $$flag || echo unsupported $@ + echo $$aux_shlibpath_var=./$(objdir) $$shlibpath_var=./$(objdir) $(CC) $(CFLAGS) $(LDFLAGS) -o $@ $(hell_OBJECTS) -lhello $(LIBS) $(LIBM) $$flag || echo unsupported $@; \ + eval $$aux_shlibpath_var=./$(objdir) $$shlibpath_var=./$(objdir) $(CC) $(CFLAGS) $(LDFLAGS) -o $@ $(hell_OBJECTS) -lhello $(LIBS) $(LIBM) $$flag || echo unsupported $@ hc-minusL: $(hell_OBJECTS) $(hell_DEPENDENCIES) @rm -f hc-minusL diff --git a/tests/link-order2.at b/tests/link-order2.at index a6eea0e..5ba3c32 100644 --- a/tests/link-order2.at +++ b/tests/link-order2.at @@ -1,6 +1,6 @@ # link-order2.at -- test link order of deplibs-*- Autotest -*- # -# Copyright (C) 2006, 2007, 2008 Free Software Foundation, Inc. +# Copyright (C) 2006, 2007, 2008, 2010 Free Software Foundation, Inc. # Written by Ralf Wildenhues, 2006 # # This file is part of GNU Libtool. @@ -47,7 +47,7 @@ AT_SETUP([Link order of deplibs]) AT_KEYWORDS([libtool]) AT_KEYWORDS([interactive])dnl running 'wrong' may cause a popup window. -eval `$LIBTOOL --config | $EGREP '^(shlibpath_var|allow_undefined_flag)='` +eval `$LIBTOOL --config | $EGREP '^((aux_)?shlibpath_var|allow_undefined_flag)='` undefined_setting=-no-undefined shared_fails=no @@ -108,9 +108,16 @@ for type_of_depdepl in libtool non-libtool; do addpath=$defbindir fi sep= -eval test -n \\$$shlibpath_var\ sep=: -eval $shlibpath_var
Re: Fix linking from only convenience archives with gfortran on Darwin.
Hi Peter, thanks for the quick feedback! * Peter O'Gorman wrote on Thu, Oct 14, 2010 at 10:49:00PM CEST: On 10/14/2010 02:27 PM, Ralf Wildenhues wrote: The following patch should fix this. Paul, any chance you could try out the patch on your system? OK to add your nameemail to THANKS? OK to commit? (I do have access to a darwin system, but no gfortran installed there, so I cannot test this.) With this patch, and make check TESTS= TESTSUITEFLAGS=-k convenience, I get: ... 33: C convenience archives ok 34: C++ convenience archivesok 35: F77 convenience archivesok 36: FC convenience archives ok Do these last two fail without the patch tho? If not, which gfortran version do you have, and what is ./libtool --tag=FC --config ? Thanks, Ralf
Re: bindir.at takes forever.
* Peter Rosin wrote on Thu, Oct 14, 2010 at 11:32:20PM CEST: Den 2010-10-14 21:48 skrev Ralf Wildenhues: Changes over the previous patch version: - removed some loop iterations in the inner test, for efficiency, to address Peter's report, - correctly SKIP the test if tempdir creation fails. OK to commit both patches? Thanks for doing this! I have one minor nit with these patches which I have included inline. Other than that, the patches seem to cut the test time in about half. Still long, but this shaves off many minutes. BTW, the bindir tests still pass on MSYS/MSVC. Cool, thanks for the review. I have squashed in this incremental diff before pushing. Cheers, Ralf diff --git a/ChangeLog b/ChangeLog index 379e609..b071b92 100644 --- a/ChangeLog +++ b/ChangeLog @@ -9,7 +9,7 @@ require a major version number in the $libdir file name, for AIX without runtimelinking. If tmpdir creation fails, skip the test. Use fewer bindir directory names for testing, to speed - up the test. + up the test. Also mention MSVC style DLL name in comment. Report by Peter Rosin. tests: remove unneeded 'bindir compile check' test. diff --git a/tests/bindir.at b/tests/bindir.at index 3fa185c..4e2fecc 100644 --- a/tests/bindir.at +++ b/tests/bindir.at @@ -271,10 +271,10 @@ do AT_CHECK([$LIBTOOL --mode=install $lt_INSTALL libfoo.la $libdir], [], [ignore], [ignore]) AT_CHECK([$LIBTOOL --mode=install $lt_INSTALL main$EXEEXT $curdir/sbin/main$EXEEXT], [], [ignore], [ignore]) - # And ensure it went where we expect. Could be looking for any of 'cygfoo-0.dll', - # 'libfoo-0.dll', or 'libfoo.so.0'. We'll simplify this check by taking advantage - # of the fact that if it's a DLL, it has to go in bindir, so we'll not check for - # both forms in libdir. + # And ensure it went where we expect. Could be looking for any of + # 'cygfoo-0.dll', 'libfoo-0.dll', 'foo-0.dll', or 'libfoo.so.0'. We'll + # simplify this check by taking advantage of the fact that if it's a DLL, + # it has to go in bindir, so we'll not check for both forms in libdir. if $bindirneeded; then AT_CHECK([test -f $libdir/../bin/???foo-0.dll || ls $libdir/../bin/*foo*0*], [], [ignore], [ignore]) else
libtool-next patch queue
Hi Gary, I promised I would look at your patch queue for rewriting bootstrap. You pushed it to the libtool-next branch, so let me go through the patches in that queue in order (re-stating this so everybody is on the same page here, some of the messages involved unfortunately went off-list for completely unrelated reasons; apologies for that). The patch queue goes from dd5b4f06557a4c5ec7b06d7814b95ecd63ab63b8^ to 0280c3687962199479258741cef4f32a2ccb8ffd and for reference, I will just quote patches one by one here and/or in followup mails, as appropriate. The first three patches in the queue have previously been reviewed already and their re-roll looks good to me. I have merged these three into master now: From dd5b4f06557a4c5ec7b06d7814b95ecd63ab63b8 Mon Sep 17 00:00:00 2001 From: Gary V. Vaughan g...@gnu.org Date: Wed, 1 Sep 2010 14:41:52 +0700 Subject: [PATCH 01/17] maint: rearrange Makefile.am in preparation for a follow-up patch. * Makefile.am (Libtool scripts.): Move this section below the `Bootstrap.' section... (libtoolize.in): ...except this one which is generated at bootstrap time, and was added into the `Bootstrap.' section. (Libltdl.): Move this section below the `Libtool scripts.' section. From c9497cc81cc46ce8848452240a323266440c4cb9 Mon Sep 17 00:00:00 2001 From: Gary V. Vaughan g...@gnu.org Date: Thu, 23 Sep 2010 17:00:08 +0700 Subject: [PATCH 02/17] maint: don't leak developer GREP, SED etc into distribution file. * Makefile.am: Having rearranged the file, now apply the actual changes to follow-up. (edit): Split into two parts... (bootstrap_edit): ...substitutions that should happen at bootstrap time... (configure_edit): ...and substitutions that should not happen until configure time. * Makefile.am (libltdl/m4/ltversion.m4, libltdl/config/ltmain.sh) (libtoolize.in, tests/package.m4): Use bootstrap_edit. (libtoolize, tests/defs): Use configure_edit. * HACKING (Release Procedure): Remove the note to workaround the bug fixed by this changeset. * NEWS (Bug fixes): Mention that this bug is now fixed. Reported by Joerg Sonnenberger. From a2bb0c980f2b50ab31fedd18bb4890843b3d399a Mon Sep 17 00:00:00 2001 From: Gary V. Vaughan g...@gnu.org Date: Fri, 24 Sep 2010 12:51:36 +0700 Subject: [PATCH 03/17] libtool: remove redundant unsubstituted shell var defaults. * Makefile.am (libltdl/config/ltmain.sh): Boilerplate code from libltdl/config/general.m4 sets some default shell variables designed to be substituted by `$(configure_edit)'. Actually, `libtool' uses the language tag values for those variables, and `ltmain.m4sh' is not passed through `$(configure_edit)', so they are just noise. Edit them out at bootstrap time. The next patch needs fixes. I'll followup. Cheers, Ralf
Re: PATCH RFA: Add Go support
* Ian Lance Taylor wrote on Wed, Oct 13, 2010 at 07:31:04PM CEST: Ralf Wildenhues writes: Do you have, or are working on, an Automake patch for Go support? I do not have an automake patch, although that is a logical next step. I've been using libtool with a Makefile.am which uses this definition: LTGOCOMPILE = $(LIBTOOL) --tag GO --mode=compile $(GCCGO) $(INCLUDES) \ $(AM_GOFLAGS) $(GOFLAGS) and then runs $(LTGOCOMPILE) as needed. Adding Go support to automake may be a little tricky as Go requires a slightly different compilation model: you must pass all files that are in the same package to the compiler at once. You can't compile them separately. That is not a big problem per se. However, how would you implement build parallelism? Inside gccgo? Should it eventually have jobserver support, received from make? What if files reside in subdirs (of the current directory, or of $srcdir), will objects be created in subdirs or in the current directory (and how would we avoid creation of files below $srcdir in a VPATH build, given that $srcdir is a concept not known to the compiler a priori)? Or maybe it has no objects at all? Can the user split up large projects into multiple pieces, either by separate Makefile.am files for separate directories, or somehow separately compiling the set of sources in one directory, maybe by library or by program compiled? If the latter is to be supported, then things like overlapping sources become a problem (i.e., both libfoo and libbar use baz.o). Can you send output of ./libtool --tag=GO --config for Libtool with Go support enabled? You need to patch Libtool's configure.ac to enable Go support (this should be part of the patch as well). Attached. Thanks, that looks quite reasonable. Testsuite additions (to the new testsuite) would be nice, like one setup where Go is the only language enabled (to verify that object and executable extension computation work etc). We can write those tests if you're not familiar with Autotest. Can you suggest a test that I can look at to see what this should look like? Off-hand I don't know an ideal candidate, but you can look at template.at for a way to do it manually (by using the libtool script generated in the toplevel, and not using Automake) would give coverage of compile and link mode. For a complete configure example, you need to setup at least a minimal configure.ac, and run LT_AT_AUTOCONF, LT_AT_CONFIGURE etc. The helper macros are defined in tests/testsuite.at. For example tests/early-libtool.at uses them. Again, this is something we can probably write easily for you (just it will be until the weekend for me). Updated patch attached (two patches from git format-patch, let me know if there is a better way to send this). You can just merge them to one, for example with: git rebase -i HEAD~2 which will open a file in an editor. Replace the edit in the second line with squash, save, exit, edit the combined log entry. If you have changes in your tree to tack onto the most recent commit, you can use 'git commit -a --amend'. Both strategies assume that the amended-to commits are not published in a public git repository yet (i.e., nobody has code that depends on them exactly). But we can do this kind of fixup too. Thanks, Ralf
Re: PATCH RFA: Add Go support
Hello Ian, thanks for the patch! * Ian Lance Taylor wrote on Tue, Oct 12, 2010 at 11:42:56PM CEST: This patch adds support for the Go programming language to libtool. Go is described at http://golang.org/ . I'm not very familiar with libtool. This patch is mostly a cut-and-paste job. It is enough to let me use automake with LIBTOOL to build libraries from Go code. Do you have, or are working on, an Automake patch for Go support? The patch requires a patch which I've proposed for autoconf: http://lists.gnu.org/archive/html/autoconf-patches/2010-10/msg4.html I'm not sure how to handle a libtool patch which requires an autoconf patch. Perhaps this can not be committed until the next libtool release. We usually try to support older Autoconf as well (currently back to 2.59), so that people don't need to upgrade all at once. When only macros from Autoconf proper are missing (as opposed to macros from other third parties), they can be treated similarly to how AC_PROG_SED is treated with a backup in libtool.m4. There might be an ordering issue between the definition of AC_PROG_GO and the AC_PROVIDE_IFELSE([AC_PROG_GO], ...) because the latter essentially tacks code onto the former (this might be moot as a define vs. expand thing, haven't checked though). In any case I would appreciate any comments and any advice as to how to get this committed to libtool. Thanks. tests/suffix.test should be updated. Can you send output of ./libtool --tag=GO --config for Libtool with Go support enabled? You need to patch Libtool's configure.ac to enable Go support (this should be part of the patch as well). A NEWS entry would be good. Testsuite additions (to the new testsuite) would be nice, like one setup where Go is the only language enabled (to verify that object and executable extension computation work etc). We can write those tests if you're not familiar with Autotest. I haven't checked things in detail yet, but since it is new functionality, the chance for regression is not so high. Thanks, Ralf
Re: somewhat misleading -no-undefined documentation
* Ralf Wildenhues wrote on Sat, Oct 09, 2010 at 12:27:35PM CEST: 2010-10-09 Simon Josefsson si...@... Matěj Týč matej@... Ralf Wildenhues ralf.wildenh...@... docs: improve description of -no-undefined. * doc/libtool.texi (Link mode): Fix -no-undefined description. (Inter-library dependencies): Use Windows not AIX as example system. Clarify need for symbol resolution at library creation time. No comments, I've pushed the patch now. Cheers, Ralf
Re: [PATCH] Add missing sysroot resolution
Hi Paolo, * Paolo Bonzini wrote on Sat, Oct 09, 2010 at 10:43:12AM CEST: I'm applying this patch since it's pretty obvious. Thank you. Is this fixing (part) of the reported bug? Do you know how to expose it, so we can cover it in the testsuite? For future sysroot patches, feel free to also (or first) commit them to the sysroot branch and merge them to master. Thanks, Ralf * libltdl/config/ltmain.m4sh (func_mode_link): Resolve sysroot when fetching the install directory of dependent libraries. Reported by Lionel Landwerlin llandwer...@gmail.com, patch by Khem Raj raj.k...@gmail.com. * THANKS: Reorder entries, add Khem and Lionel.
Re: [PATCH] Add missing sysroot resolution
* Paolo Bonzini wrote on Sat, Oct 09, 2010 at 10:55:44AM CEST: On 10/09/2010 10:51 AM, Ralf Wildenhues wrote: * Paolo Bonzini wrote on Sat, Oct 09, 2010 at 10:43:12AM CEST: I'm applying this patch since it's pretty obvious. Is this fixing (part) of the reported bug? Lionel pointed us to the patch, so I assumed it fixed all of it. I still haven't built his stuff. It looks really interesting, as does OpenEmbedded, and it's really cool that the sysroot feature is already getting this much exposure. I was worried that it would remain confined in the unused feature limbo and would bitrot. It's also nice because it shows that these people _are_ autoreconfing/relibtoolizing as part of their build systems. It gives me much more confidence on the backwards-compatibility of libtool 2.4! Indeed! Good you say this (all of the above), because I forgot to mention any of it. Do you know how to expose it, so we can cover it in the testsuite? Not yet, I'll look into it next week. I need to build Lionel's recipe and then distill a testcase. Cool. Thanks. For future sysroot patches, feel free to also (or first) commit them to the sysroot branch and merge them to master. Ok, I was undecided about the status of the sysroot branch. Oh, I don't care much either way, but as long as we're still fixing things with, might as well document the fixes on the branch. For some kind of future code-archeology niceness or so. ;-) Cheers, Ralf
Re: cwrapper generates long strings.
* Peter Rosin wrote on Sun, Oct 03, 2010 at 08:28:47PM CEST:
Den 2010-10-03 09:01 skrev Ralf Wildenhues:
+for i in 25 50 75 100 125 150 175 200 225 250
+do
+ PATH=$PATH$PATH_SEPARATOR/somewhere-that-eksists-not
Does $LIBTOOL or the autotest machinery ever intentionally try to run
commands that won't exist in $PATH within this shell?
I don't think so, and it is a really hard question to answer too.
Indeed.
I'm kinda wondering whether we should at least delimit our use of
nonexistent files and directories to a common subtree, like below
/nonexistent or so. I realize we're getting near bike shedding
issues though, so how about we cross that bridge when we get to it,
and leave your patch as is for now.
If so, then we
might get the odd bug report from security-hardened distributions that
complain about read or execute accessses to non-allowed parts of the
file system.
Using $PATH$PATH_SEPARATOR$PATH seemed like a much quicker way
to make the length explode so I didn't like that.
OK.
This length doesn't yet trigger the compiler string literal length
limit; not sure whether it should?
That's not reliable anyway as most compilers support so long strings
that it's hard to tickle it.
FWIW, that is not necessary. It would be sufficient if it were tickled
with the one compiler in question.
On a tangent, another bug is that linking
doesn't fail (libtool returns zero) when building the cwrapper fails.
I think that's a separate issue from this one, which is why I haven't
mixed them up previously.
OK, good.
Another nit in that area is that there are
multiple levels of $opt_dry_run || { which seems superfluous, but
that might be intentional in order to keep the code copy-paste-safe?
Not sure. I don't have much sympathy for copy-paste-safety, because
I dislike the kludge that copy-paste is. Functions should be used
instead. So yes, I guess a cleanup is a good idea, after ensuring that
the code really works fine with the outer opt_dry_run enclosing.
Do we have to cater to the case where the environment is very large
already? I'm not sure, we might want to deal with it when crossing
that bridge only, if it's hard to know off-hand.
Are your three above paragraphs nits and part of what I need to
address, or just notes for the future?
They started out as nits, but I guess they've become notes by now.
So go ahead with your patch, please.
+# try to make sure the test is relevant
+AT_CHECK([grep ' *fputs' $objdir/lt-usea.c /dev/null])
Rather than redirecting stdout, put [ignore] in the third argument.
Certainly possible, but I didn't think anyone would be interested in a
couple of hundred lines of boilerplate in the log. I don't really care
though, so if you still think [ignore] is a good idea, then ok.
Ah yes. Autoconf 2.64 provides stdout-nolog for this, but I guess you
can keep the code the way it is, for compatibility.
Thanks,
Ralf
Re: [PATCH] Add test case for 69e77671 (cwrapper PATH manipulation order)
Hi Charles,
* libt...@cwilson.fastmail.fm wrote on Sun, Oct 03, 2010 at 11:15:17PM CEST:
* tests/cwrapper.at: Add new test 'cwrapper and installed shared
libraries.'
OK with nits addressed. You may want to use a ChangeLog and/or --author
entry that suitably documents the main author of the patch.
Thanks,
Ralf
--- a/tests/cwrapper.at
+++ b/tests/cwrapper.at
@@ -134,3 +134,73 @@ done
AT_CLEANUP
+
+AT_SETUP([cwrapper and installed shared libraries])
+AT_KEYWORDS([libtool])
+
+# make sure existing libtool is configured for shared libraries
+AT_CHECK([$LIBTOOL --features | grep 'disable shared libraries' exit 77],
+ [1], [ignore])
Let's be positive:
AT_CHECK([$LIBTOOL --features | grep 'enable shared libraries' || exit 77],
[], [ignore])
+# FIXME with shared_fails for this test on AIX
+# copy from link-order2.at:
+eval `$LIBTOOL --config | $EGREP '^(shlibpath_var|allow_undefined_flag)='`
+
+undefined_setting=-no-undefined
+shared_fails=no
+case $host_os,$LDFLAGS,$allow_undefined_flag in
+aix*,*-brtl*,*) ;;
+aix*) shared_fails=yes ;;
+darwin*,*,*-flat_namespace*) undefined_setting= ;;
+darwin*,*,*) shared_fails=yes ;;
+esac
+# end of copy from link-order2.at
+
+LDFLAGS=$LDFLAGS $undefined_setting
Let's replace these 15 lines with
LDFLAGS=$LDFLAGS -no-undefined
because I don't see how this test should need to depend on them at all.
Since the test is explicitly about the cwrapper, I'd probably prefer to
skip it on systems that have a problem with the test but don't use the
cwrapper anyway. If you agree then I can just test this later and we
keep the simple code for now.
+inst=`pwd`/inst
+libdir=$inst/lib
+bindir=$inst/bin
+mkdir $inst $libdir $bindir
+
+# we must build foo library in a separate directory to avoid on some
+# platforms shared library to be loaded from current directory
I have trouble parsing this sentence, and it is lacking punctuation and
capitalization. How about this?
# Build the library in a separate directory to avoid the special case
# of loading from the current directory.
+mkdir foo
+cd foo
+# build and install old library version
+AT_DATA([a.c], [[
+int liba_ver (void) { return(1); }
Please no parens for argument to return, that is not a function.
Three instances.
+]])
+$LIBTOOL --mode=compile --tag=CC $CC $CPPFLAGS $CFLAGS -c a.c
+$LIBTOOL --mode=link $CC $CFLAGS $LDFLAGS -version-info=0.0.0 -o liba.la
-rpath $libdir a.lo
+$LIBTOOL --mode=install $lt_INSTALL liba.la $libdir
Is there any, however unlikely, chance that these $LIBTOOL commands fail
on some system or setup? Then they should be wrapped in
AT_CHECK([...], [], [ignore], [ignore])
+# build a new library version
+AT_DATA([a.c], [[
+int liba_ver (void) { return(2); }
+]])
+$LIBTOOL --mode=compile --tag=CC $CC $CPPFLAGS $CFLAGS -c a.c
+$LIBTOOL --mode=link $CC $CFLAGS $LDFLAGS -version-info=0.0.0 -o liba.la
-rpath $libdir a.lo
Ditto.
+cd ..
+
+# build and run test application
+AT_DATA([m.c], [[
+extern int liba_ver (void);
+int main (void)
+{
+ int r = (liba_ver () == 2) ? 0 : 1;
+ return(r);
+}
+]])
+
+$LIBTOOL --mode=compile --tag=CC $CC $CPPFLAGS $CFLAGS -c m.c
+
+$LIBTOOL --mode=link $CC $CFLAGS $LDFLAGS -o m1$EXEEXT m.$OBJEXT foo/liba.la
+LT_AT_EXEC_CHECK([./m1], [0], [ignore], [ignore], [])
+
+$LIBTOOL --mode=link $CC $CFLAGS $LDFLAGS -o m2$EXEEXT m.$OBJEXT foo/liba.la
-L$inst/lib
+LT_AT_EXEC_CHECK([./m2], [0], [ignore], [ignore], [])
+
+AT_CLEANUP
Re: cwrapper generates long strings.
* Peter Rosin wrote on Mon, Oct 04, 2010 at 10:02:15AM CEST: I wrote a loop appending the first PATH component until the length exceeds the limit. The longest possible PATH should be 499 characters this way, which seems OK to me, and it should have no wild components. Cool. Den 2010-10-04 07:00 skrev Ralf Wildenhues: * Peter Rosin wrote on Sun, Oct 03, 2010 at 08:28:47PM CEST: This length doesn't yet trigger the compiler string literal length limit; not sure whether it should? That's not reliable anyway as most compilers support so long strings that it's hard to tickle it. FWIW, that is not necessary. It would be sufficient if it were tickled with the one compiler in question. Since the compiler limit in this case is as large as 2048 (whoooa), which is about the same as you quoted for grep, I decided to not do that. Good point. The updated patch is fine. Thanks, Ralf Subject: [PATCH] cwrapper: split long lines when dumping the wrapper script. * libltdl/config/ltmain.m4sh (func_emit_cwrapperexe_src): If the wrapper script contains long lines, split them for readability and to conform with C standards. * tests/cwrapper.at (cwrapper string length): New test, making sure we don't regress.
Re: [PATCH] msvc: handle symbols from different files independently.
Hi Peter, * Peter Rosin wrote on Mon, Oct 04, 2010 at 01:25:42PM CEST: Den 2010-10-02 08:40 skrev Ralf Wildenhues: Skip if $NM != $DUMPBIN? But then you'd need to ensure DUMPBIN is set. It's a pest that you can have: DUMPBIN=link -dump NM=dumpbin -symbols or DUMPBIN=dumpbin NM=link -dump -symbols I.e. link -dump is a synonym for dumpbin. How for a slight improvement at least something that's bound to remain even if the symbol pipe is rewritten in sed or another language, e.g., looking whether ' UNDEF ' or 'Section length' is present? I redid it in the same manner the configure test is doing it instead. Definitely better, also than my suggestion above; thanks. Please consider moving testsuite additions which are clearly system- specific to other tests which are clearly system-specific, and grouping those testing the same systems, or family of systems (such as w32). And then using one AT_BANNER for a set of test groups. I moved it before deplibs-mingw.at and changed the banner to Windows tests., quietly fixing the cosmetic bug that deplibs-mingw.at isn't a darwin test to begin with. Ah, good. OK with nits below. One more iteration since I'm not sure if redoing the configure test is ok. Go! Thanks, Ralf Subject: [PATCH] msvc: handle symbols from different files independently. * libltdl/m4/libtool.m4 (_LT_CMD_GLOBAL_SYMBOLS) dumpbin, lt_cv_sys_global_symbol_pipe: Make all sections viable for symbol extraction again when the symbols from a new file starts. Fixes tests/tagdemo-make.test for MSVC 10. * tests/dumpbin-symbols.at: New test, making sure we don't regress. * Makefile.am (TESTSUITE_AT): Update.
Re: cwrapper generates long strings.
Hi Peter,
* Peter Rosin wrote on Sat, Oct 02, 2010 at 11:33:02PM CEST:
Den 2010-10-02 13:53 skrev Ralf Wildenhues:
Yes. Well, we might get the odd report about the Cygwin non-binmode
mount where the CR NL messes up things, but otherwise, it should work.
If you are on a text mount, it should fixup CR NL issues. If you have
CR NL files on a binary mount you deserve to suffer. So, a non-issue.
Cool. Thanks.
I used 250 at the limit in the test as the 79 characters from the string
splitter in ltmain might be doubled due to C string escapes and then I
added some extra margin for quotes and the , f); trailer. Still below
255 which might be an arbitrary limit in some grep implementations.
You can assume close to 2K as minimum limit for grep.
(Hmm, wonder why we didn't ever write down the value in autoconf.texi)
The patch is OK with nits addressed.
--- a/tests/cwrapper.at
+++ b/tests/cwrapper.at
@@ -134,3 +134,53 @@ done
AT_CLEANUP
+
+AT_SETUP([cwrapper string length])
+
+eval `$LIBTOOL --config | $EGREP '^(objdir)='`
+
+AT_DATA([liba.c],
+[[int liba_func1 (int arg)
+{
+ return arg + 1;
+}
+]])
+AT_DATA([usea.c],
+[[extern int liba_func1 (int arg);
+int main (void)
+{
+ int a = 2;
+ int b = liba_func1 (a);
+ if (b == 3) return 0;
+ return 1;
+}
+]])
+
+AT_CHECK([$LIBTOOL --mode=compile $CC $CPPFLAGS $CFLAGS -c liba.c],
+ [], [ignore], [ignore])
+AT_CHECK([$LIBTOOL --mode=link $CC $CFLAGS $LDFLAGS -no-undefined ]dnl
+ [-o liba.la -rpath /foo liba.lo],
+ [], [ignore], [ignore])
+AT_CHECK([$CC $CPPFLAGS $CFLAGS -c usea.c],
+ [], [ignore], [ignore])
+
+# make sure PATH is at least 250 chars, should force line breaks in lt-usea.c
+for i in 25 50 75 100 125 150 175 200 225 250
+do
+ PATH=$PATH$PATH_SEPARATOR/somewhere-that-eksists-not
Intended typo 'exists'? ;-)
Does $LIBTOOL or the autotest machinery ever intentionally try to run
commands that won't exist in $PATH within this shell? If so, then we
might get the odd bug report from security-hardened distributions that
complain about read or execute accessses to non-allowed parts of the
file system.
This length doesn't yet trigger the compiler string literal length
limit; not sure whether it should?
Do we have to cater to the case where the environment is very large
already? I'm not sure, we might want to deal with it when crossing
that bridge only, if it's hard to know off-hand.
+done
+export PATH
+
+AT_CHECK([$LIBTOOL --mode=link $CC $CFLAGS $LDFLAGS -no-fast-install ]dnl
+ [-o usea$EXEEXT usea.$OBJEXT liba.la],
+ [], [ignore], [ignore])
+
+# skip if no cwrapper is generated
+AT_CHECK([test -f $objdir/lt-usea.c || exit 77])
+
+# try to make sure the test is relevant
+AT_CHECK([grep ' *fputs' $objdir/lt-usea.c /dev/null])
Rather than redirecting stdout, put [ignore] in the third argument.
+# check for no overly long fputs
+AT_CHECK([grep ' *fputs.\{250\}' $objdir/lt-usea.c], [1])
+
+AT_CLEANUP
Cheers,
Ralf
Re: [PATCH] tests: don't use assert/abort on MSVC as they are interactive.
Hi Peter, * Peter Rosin wrote on Wed, Sep 29, 2010 at 11:21:11PM CEST: Den 2010-09-29 21:01 skrev Ralf Wildenhues: * Peter Rosin wrote on Wed, Sep 29, 2010 at 10:06:00AM CEST: Ok to push this one? I don't mind it, but I'll note that the patch will cause testsuite failures when no wrapper is actually used. This can happen - with --disable-shared passed toplevel, or on static-only systems, - on systems where a wrapper is not needed even in shared mode At least for lalib-syntax it will thus cause failure for the wrong reason (the current XFAIL hides that I guess). I think you are wrong here. Well, all the better then, both because that means the situation is better than feared, and because you're not letting yourself get distracted. lalib-syntax only looks at the 1st argument so the fact that I have added a 2nd argument should not matter in practice. We don't call it without arguments so its argc 2 check is just cosmetics. For demo-relink that is irrelevant, as demo/main.c ignores its arguments, tests/depdemo/main.c however also uses them. The only prior argument to depdemo/main.c that I could find was -alt, which is explicitly tested for in main(), so if an extra --lt- option bleeds in, it should be ignored and not cause any harm. I might have missed something though. So, I actually don't think the patch will affect the testsuite results. OK good. Hmm, --lt-no-interactive instead of --lt-no-popup, for consistency with check-(non)interactive? --lt-no-interactive is fine by me, but why not --lt-non-interactive? Hmm. Was thinking about how GCC does options, I guess, with -ffoo mapped to -fno-foo. no-interactive sounds weirder when spoken out, though. I'll think some more about the general issue. What I really would like is a bash shopt to set the error mode from the shell when running testsuites. Then we could really forget this issue. Either that or some way to make MSYS not force the default error mode so hard. I have tried to start MSYS with an inherited error mode, but I couldn't make it stick. I guess I need to start digging in the sources of those projects, and see if I can see what would be the best/easiest solution. That would indeed be cool. IIUC your followup post shows this isn't so easy though. So feel free to go ahead with the change. Thanks, Ralf
Re: [PATCH] msvc: handle symbols from different files independently.
Hi Peter,
* Peter Rosin wrote on Fri, Oct 01, 2010 at 01:38:42PM CEST:
Anyway, is this test case good enough? Should I find a better
way to skip on non-dumpbin runs? How?
Skip if $NM != $DUMPBIN? But then you'd need to ensure DUMPBIN is set.
How for a slight improvement at least something that's bound to remain
even if the symbol pipe is rewritten in sed or another language, e.g.,
looking whether ' UNDEF ' or 'Section length' is present?
Please consider moving testsuite additions which are clearly system-
specific to other tests which are clearly system-specific, and grouping
those testing the same systems, or family of systems (such as w32).
And then using one AT_BANNER for a set of test groups.
OK with nits below.
Thanks,
Ralf
Subject: [PATCH] msvc: handle symbols from different files independently.
* libltdl/m4/libtool.m4 (_LT_CMD_GLOBAL_SYMBOLS)
dumpbin, lt_cv_sys_global_symbol_pipe: Make all sections
viable for symbol extraction again when the symbols from a new
file starts. Fixes tests/tagdemo-make.test for MSVC 10.
* tests/dumpbin-symbols.at: New test, making sure we don't
regress.
* Makefile.am (TESTSUITE_AT): Update.
--- a/libltdl/m4/libtool.m4
+++ b/libltdl/m4/libtool.m4
@@ -3645,6 +3645,7 @@ for ac_symprfx in _; do
# which start with @ or ?.
lt_cv_sys_global_symbol_pipe=$AWK ['\
{last_section=section; section=\$ 3};\
+ /^COFF SYMBOL TABLE/{for(i in hide) delete hide[i]};\
/Section length .*#relocs.*(pick any)/{hide[last_section]=1};\
\$ 0!~/External *\|/{next};\
/ 0+ UNDEF /{next}; / UNDEF \([^|]\)*()/{next};\
--- /dev/null
+++ b/tests/dumpbin-symbols.at
+AT_BANNER([Symbol extraction])
+AT_SETUP([dumpbin -symbols section hiding])
+
+# I don't know of a stable way to create a pair of objects that
+# exhibits the potential problem, so this test fakes it by
+# testing with output from a case that do have the potential
+# problem.
+
+eval `$LIBTOOL --config | $EGREP '^(global_symbol_pipe)='`
+
+# This skip check is fragile, make lt_cv_nm_interface visible here instead?
+case $global_symbol_pipe in
+*last_section=section*) ;;
+*) AT_CHECK([exit 77]) ;;
+esac
+# Check if the _convenience symbol from section SECT3 in conv.lib is
+# present even if section SECT3 in foo.obj is hidden.
+AT_CHECK([eval cat dumpbin-output | $global_symbol_pipe], [], [stdout])
cat dumpbin-output | eval $global_symbol_pipe
ought to be sufficient. Or even
dumpbin-output eval $global_symbol_pipe
Thanks,
Ralf
Re: cwrapper generates long strings.
Hi Peter,
* Peter Rosin wrote on Fri, Oct 01, 2010 at 11:22:54PM CEST:
Subject: [PATCH] cwrapper: split long lines when dumping the wrapper script.
* libltdl/config/ltmain.m4sh (func_emit_cwrapperexe_src): If
the wrapper script contains long lines, split them for
readability and to conform with C standards.
OK with me with nits addressed. I see this as a fairly straightforward
way to work around the issue; we can still think about following Chuck's
proposal in due course even with this in place.
Nit 1: testsuite exposure. Should be fairly straightforward to set
PATH=$PATH$PATH_SEPARATOR$PATH
a couple of times until long enough (but not too long so that
environment plus command line length already go over the limit), then
build a library and a program linked against it, covering the path that
failed for you, no?
Thanks,
Ralf
--- a/libltdl/config/ltmain.m4sh
+++ b/libltdl/config/ltmain.m4sh
@@ -4268,9 +4268,14 @@ void lt_dump_script (FILE* f)
{
EOF
func_emit_wrapper yes |
- $SED -e 's/\([\\]\)/\\\1/g' \
--e 's/^/ fputs (/' -e 's/$/\\n, f);/'
-
+ $SED -n -e '
+s/^\(.\{79\}\)\(..*\)/\1\n\2/
\n is portable only in the regex part, but not in the replacement part.
For that you need backslash then literal newline.
+h
+s/\([\\]\)/\\\1/g
+s/$/\\n/
+s/\([^\n]*\).*/ fputs (\1, f);/p
Why not above, right after h, do s/\n.*// and then simplify this s
command?
+g
+D'
cat EOF
}
EOF
Re: [PATCH] msvc: handle symbols from different files independently.
Hi Peter,
* Peter Rosin wrote on Thu, Sep 30, 2010 at 09:06:16PM CEST:
Ok to push when I have tested with various MSVC versions?
I guess, but you should really add testsuite exposure.
Thanks,
Ralf
Subject: [PATCH] msvc: handle symbols from different files independently.
* libltdl/m4/libtool.m4 (_LT_CMD_GLOBAL_SYMBOLS)
dumpbin, lt_cv_sys_global_symbol_pipe: Make all sections
viable for symbol extraction again when the symbols from a new
file starts. Fixes tests/tagdemo-make.test for MSVC 10.
--- a/libltdl/m4/libtool.m4
+++ b/libltdl/m4/libtool.m4
@@ -3645,6 +3645,7 @@ for ac_symprfx in _; do
# which start with @ or ?.
lt_cv_sys_global_symbol_pipe=$AWK ['\
{last_section=section; section=\$ 3};\
+ /^COFF SYMBOL TABLE/{for(i in hide) delete hide[i]};\
/Section length .*#relocs.*(pick any)/{hide[last_section]=1};\
\$ 0!~/External *\|/{next};\
/ 0+ UNDEF /{next}; / UNDEF \([^|]\)*()/{next};\
Re: [PATCH] msvc: handle symbols from different files independently.
* Peter Rosin wrote on Thu, Sep 30, 2010 at 10:53:13PM CEST: Den 2010-09-30 21:25 skrev Ralf Wildenhues: * Peter Rosin wrote on Thu, Sep 30, 2010 at 09:06:16PM CEST: Ok to push when I have tested with various MSVC versions? I guess, but you should really add testsuite exposure. I don't know any controlled way to create a pair of object files that clash, should I just fake it and extract global_symbol_pipe from the libtool script and feed it example output that clashes, and check that the symbol isn't hidden? I guess. Hmm, from your first description I thought this was easier to reproduce. Thanks, Ralf
Re: [PATCH] tests: don't use assert/abort on MSVC as they are interactive.
Hi Peter, * Peter Rosin wrote on Wed, Sep 29, 2010 at 10:06:00AM CEST: Ok to push this one? I don't mind it, but I'll note that the patch will cause testsuite failures when no wrapper is actually used. This can happen - with --disable-shared passed toplevel, or on static-only systems, - on systems where a wrapper is not needed even in shared mode At least for lalib-syntax it will thus cause failure for the wrong reason (the current XFAIL hides that I guess). For demo-relink that is irrelevant, as demo/main.c ignores its arguments, tests/depdemo/main.c however also uses them. (This need for internal knowledge about when wrappers are used, is why I disliked the arguments to them; or am I misremembering and we have changed the wrappers to be used in more cases for some reason?) Hmm, --lt-no-interactive instead of --lt-no-popup, for consistency with check-(non)interactive? Thanks, Ralf Subject: [PATCH] tests: make more tests non-interactive on MSYS. * libltdl/config/ltmain.m4sh (func_emit_cwrapperexe_src): Recognize --lt-no-popup and set the w32 error mode so that Windows do not popup dialogs if the option is seen. * libltdl/config/ltmain.m4sh (func_parse_lt_options): Recognize --lt-no-popup and strip it out (with no side effect, there is no API for adjusting the w32 error mode from within a shell). * tests/demo-relink.test, tests/depdemo-relink.test: Use the above option to make the test non-interactive on MSYS. tests/lalib-syntax.at: Use the above option to make the test non-interactive on MSYS/MSVC (the MSVC version of assert/abort pops up an error dialog). * docs/libtool.texi (Wrapper executables): Document the new option of the wrapper.
pre-release update of LTDL_VERSION_INFO (was: [SCM] GNU Libtool branch, master, updated. v2.4-1-gf0ba93d)
Hello Gary, * Gary V. Vaughan wrote on Fri, Sep 24, 2010 at 10:12:10AM CEST: On 23 Sep 2010, at 00:30, Ralf Wildenhues wrote: * Gary V. Vaughan wrote on Wed, Sep 22, 2010 at 06:27:27PM CEST: * libltdl/Makefile.inc (LTDL_VERSION_INFO): We've added the static libprefix interface, so new version-info is C+1:0:R+1. libprefix is a *static* local undocumented variable, not public API. There was no reason to bump the API version for this. :-( Ugh. Sorry. Luckily there are still quite a lot of numbers left before we run out. That's not the point. The point is that on systems which compute the major version as CURRENT rather than CURRENT - AGE, this bump means that all dependent libraries need to be rebuilt. For the respective distribution packagers, I expect this to be several hours of extra work. This affects for example FreeBSD and systems derived from it. Incompatible changes (bumping CURRENT) are *very* costly for distributions, and more importantly, they typically hurt the acceptance rate of the software. I propose that to avoid this problem with future releases, that whoever commits a change that *does* affect LTDL_VERSION_INFO notes it in NEWS so that I don't make another mistake when I'm searching back up ChangeLog from the previous release commit to find things that affect the API versioning. If you agree, I'll add a note to HACKING. How about this alternative: the person doing the release posts the proposed patch to bump the version info for public review, it gets properly reviewed, then it gets committed? If you agree, I'm fine if that is documented in HACKING. The rationale for this approach is that it is easy to forget this requirement during development, both as developer and as reviewer, and it is less work to overlook all past changes at one time during the release. Of course API changes, compatible or not, should still be announced in NEWS, but they weren't this time, because there were none. It's part of release management to check and ensure that this is indeed correct. Thanks, Ralf
Re: [PATCH] Skip need_lib_prefix.at on systems without lib prefix on libraries.
Hi Peter, * Peter Rosin wrote on Fri, Sep 24, 2010 at 11:30:07AM CEST: Den 2010-09-24 06:20 skrev Ralf Wildenhues: The part about this patch which I'm unsure about is this: Does the testsuite otherwise cover well enough the fact that users may name their modules with or without leading 'lib' prefix (and with .la or .dll or .so suffix or so)? IOW, I'd like to be sure we're not hiding anything here. But that is not a problem with *this* patch. That's one of those gigantic tasks that Chuck mentions from time to time. This is not like the low max_cmd_len test. In both cases the libtool script is rigged to simulate weird conditions, but the need_lib_prefix test is rigging something that never happens on platforms that never create a lib prefix. You should also not confuse this prefix with the name of the .la file, the .la files are always allowed to have a lib prefix, this is about the real libraries. Ah, ok. We have plenty of tests that create -modules named module.la without the prefix, for example dlloader-api.la. I'm not sure what you mean by users naming their modules with various suffixes, as they must be named .la? No, they don't. On GNU/Linux, you ought to be able to, say, lt_dlopen(foo.so, ...) if you like. There are users of libltdl that do this. Of course, that requires the users to be aware of the system-specific naming issues, but ideally, some way like this should work on other systems, too. I get the feeling that I'm saying things that you already know, so I'm probably missing something. What? I don't think you are, apart from the above. And yes, I think (part of) the log entry from the initial test addition probably deserves to be a comment in the test, so we don't have to look it up again. Probably a good idea. I'll add some words before pushing anything, but I'd like this settled before doing anything further with the patch. In light of your response, and if my response above doesn't invalidate your reasoning, the patch is ok with me, with that comment added. Thanks, Ralf
Re: [PATCH] tests: import variables for MSVC.
Den 2010-09-24 19:30 skrev Charles Wilson: That is the typical approach. The drawback -- usually an acceptable one -- is that if you are building a stack of dependent DLLs: EXE -- C.DLL - B.DLL -- A.DLL Then (a) you must link exe using .obj's compiled as pic (e.g. with -DDLL_EXPORT, even tho the EXE *itself* is not a shared library). libtool does this by default IIRC. Huh? But automake won't go this way usually. With bin_PROGRAMS = foo foo_SOURCES = foo.c foo_LDADD = libc.la foo will be linked with foo.o (*not* created by libtool), and neither foo.lo nor .libs/foo.o will ever be created. Or, I am misunderstanding your statement, and going back to lurking mode. Cheers, Ralf
Re: [PATCH] tests: import variables for MSVC.
* Peter Rosin wrote on Fri, Sep 24, 2010 at 02:44:25PM CEST: Den 2010-09-24 07:21 skrev Ralf Wildenhues: Patch is ok with me if it keeps GCC working, and Chuck is ok with it. You meant to use __declspec everywhere not declspec, even in your text part of the mail, right? Yes indeed, I intended __declspec. I have revised the patch so that it handles building correctly (dllexport for dlls, not for static) and using the best way possible (still dllimports from from both dlls and static libs). For Cygwin I removed some dead code in tests/pdemo, similar code was deleted from tests/demo back in 2002 (see commit 45d16ee8bf4559d6b976bfd4d6482767f16eac95). I have verified that the Cygwin related cleanup does not affect the Cygwin testsuite results. I'll let Chuck and you hash out and decide all the details on this. One question though: will all of these '#ifdef _MSC_VER' cases need changing as soon as we add support for yet another w32 compiler? In that case, I think the strategy should be reconsidered. The idea is that the sources should ideally not need any, or at least not many, changes in the future. Relying on compiler defines seems like a suboptimal strategy, and should only be done if there is no other way. With this patch, the old testsuite SKIPs cdemo-undef and tagdemo-undef, FAILs demo-deplibs(1) and all the rest PASS (on MSYS/MSVC). So it is looking really nice. Cool. A documentation addition describing the most general case of annotations (multiple libraries, mixed static/shared, full MSVC + everything else support) plus simplifications for common cases, - no MSVC, - no shared/static mixing, - rely on auto-import, - ... would be good to have. Something from which I can deduce that your patch must be correct. That documentation would be nice, yes, and I plan to write something about that eventually. Is it a prerequisite for pushing this? No. But alongside the documentation, it would be good to have at least some testsuite exposure for all the code that we recommend. IOW, most of the testsuite now works with MSVC and all, so it ought to follow more or less the most general case of annotations. Then, we should have a couple of tests that simplify based on the assumption that we can rely on auto-import; these tests should be skipped when auto-import is not available, and they are for users whose code needs to rely on it anyway. Then a couple of tests that assume static/shared mixing does not happen. Etc. So that we can rely on our documentation to remain accurate, because we test it in the testsuite. Also, may I remind you that you promised a number of testsuite additions before the release. I have been digging in the archives for quite a bit, but I'm only finding http://lists.gnu.org/archive/html/libtool-patches/2010-09/msg00266.html What else have I promised? Oh, s/you promised/y'all promised/ ;-) Thanks, Ralf
Re: [PATCH v2 02/11] maint: don't leak developer GREP, SED etc into distribution file.
Hello Gary,
* Gary V. Vaughan wrote on Thu, Sep 23, 2010 at 05:21:19PM CEST:
I've pared this down to the absolute minimum necessary to fix the
bug it is targetting. I did run this through `make distcheck' (and
it passed), but most of the others following only got a cursory
`git clean -x -d -f ./bootstrap ./configure ./make all
check TESTS=tests/sh.test TESTSUITEFLAGS=1' unless noted otherwise.
Did you look at the output of the cursory check? Like, after this
patch, I get this in the output:
## ##
## @PACKAGE_STRING@ test suite. ##
## ##
See below for an explanation.
With this patch applied, the generated libtool script still contains
the following lines:
: ${EGREP=@EGREP@}
: ${FGREP=@FGREP@}
: ${GREP=@GREP@}
: ${LN_S=@LN_S@}
[...]
: ${SED=@SED@}
Now, the lines are all ineffective, because the tag variables (which
will be expanded before these lines) will set all of these variables.
Kind of ugly, but alright if you prefer to clean that up later.
Oh! I'd forgotten that AC_INIT_COMMANDS don't get run through the
AC_SUBST machinery :(
Unfortunately, I cannot parse this statement. What does
AC_INIT_COMMANDS have to do with these lines which come from
general.m4sh originally?
I'd like to tackle that separately. Unfortunately those settings
come from general.m4sh boilerplate and are required by libtoolize, so
it's not entirely straight forward.
Agreed.
I'm torn between running our
own minimal substitution to fill the values in from libtool.m4, or
having the make rule for libtool just edit them out. Thoughts?
Editing them out is fine. Again, fixing this later is fine with me,
too.
Okay to push this one now?
It is still not quite correct. See below.
* Makefile.am: Having rearranged the file, now apply the actual
changes to follow-up.
(edit): Split into two parts...
(bootstrap_edit): ...substitutions that should happen at bootstrap
time...
(configure_edit): ...and substitutions that should not happen until
configure time.
* Makefile.am (libltdl/m4/ltversion.m4, libltdl/config/ltmain.sh)
(libtoolize.in): Use bootstrap_edit.
This log line is not reflected in the patch contents. And in fact, with
the patch applied, the generated libtoolize script still has
untransformed strings:
$ head libtoolize | sed 's/^/| '
| #! /bin/sh
| # Generated from libtoolize.m4sh by GNU Autoconf 2.68.
|
| # libtoolize (GNU @PACKAGE@@TIMESTAMP@) @VERSION@
[...]
(libtoolize, tests/package.m4): Use configure_edit.
For tests/package.m4, this is the wrong thing to do; see below.
* HACKING (Release Procedure): Remove the note to workaround the
bug fixed by this changeset.
* NEWS (Bug fixes): Mention that this bug is now fixed.
Reported by Joerg Sonnenberger.
--- a/Makefile.am
+++ b/Makefile.am
@@ -75,26 +75,23 @@ EXTRA_DIST += bootstrap $(srcdir)/libtoolize.in
$(auxdir)/ltmain.m4sh \
CLEANFILES += libtool libtoolize libtoolize.tmp \
$(auxdir)/ltmain.tmp $(m4dir)/ltversion.tmp
-edit = sed \
- -e 's,@EGREP\@,$(EGREP),g' \
- -e 's,@FGREP\@,$(FGREP),g' \
- -e 's,@GREP\@,$(GREP),g' \
- -e 's,@LN_S\@,$(LN_S),g' \
- -e 's,@MACRO_VERSION\@,$(VERSION),g' \
- -e 's,@PACKAGE\@,$(PACKAGE),g' \
- -e 's,@PACKAGE_BUGREPORT\@,$(PACKAGE_BUGREPORT),g' \
- -e 's,@PACKAGE_URL\@,$(PACKAGE_URL),g' \
- -e 's,@PACKAGE_NAME\@,$(PACKAGE_NAME),g' \
- -e 's,@PACKAGE_STRING\@,$(PACKAGE_NAME) $(VERSION),g' \
- -e 's,@PACKAGE_TARNAME\@,$(PACKAGE),g' \
- -e 's,@PACKAGE_VERSION\@,$(VERSION),g' \
- -e 's,@SED\@,$(SED),g' \
- -e 's,@VERSION\@,$(VERSION),g' \
- -e 's,@aclocaldir\@,$(aclocaldir),g' \
- -e 's,@datadir\@,$(datadir),g' \
- -e 's,@pkgdatadir\@,$(pkgdatadir),g' \
- -e 's,@host_triplet\@,$(host_triplet),g' \
- -e 's,@prefix\@,$(prefix),g'
+## These are the replacements that need to be made at bootstrap time,
+## because they must be static in distributed files, and not accidentally
+## changed by configure running on the build machine.
+bootstrap_edit = sed \
+ -e 's,@MACRO_VERSION\@,$(VERSION),g' \
+ -e s,@MACRO_REVISION\@,$$correctver,g \
+ -e s,@MACRO_SERIAL\@,$$serial,g \
+ -e 's,@PACKAGE\@,$(PACKAGE),g' \
+ -e 's,@PACKAGE_BUGREPORT\@,$(PACKAGE_BUGREPORT),g' \
+ -e 's,@PACKAGE_URL\@,$(PACKAGE_URL),g' \
+ -e 's,@PACKAGE_NAME\@,$(PACKAGE_NAME),g' \
+ -e s,@package_revision\@,$$correctver,g \
+ -e 's,@PACKAGE_STRING\@,$(PACKAGE_NAME) $(VERSION),g' \
+ -e 's,@PACKAGE_TARNAME\@,$(PACKAGE),g' \
+ -e 's,@PACKAGE_VERSION\@,$(VERSION),g' \
+ -e s,@TIMESTAMP\@,$$TIMESTAMP,g \
+ -e 's,@VERSION\@,$(VERSION),g'
## We build ltversion.m4 here, instead of from config.status,
## because config.status
Re: [PATCH v2 07/11] build: make better use of automatic variables in `Makefile.am'.
Hi Gary, this isn't a review, I'm just adding a couple of hints that come to mind at first glance. * Gary V. Vaughan wrote on Thu, Sep 23, 2010 at 05:21:24PM CEST: Rules are getting shorter and more readable again now. I'm assuming there are no portability problems with $@ and $^ in regular rules? $@ is portable. $^ is not portable. These things are all documented. Here's the Posix page for make: http://www.opengroup.org/onlinepubs/9699919799/utilities/make.html here are the Autoconf manual sections about portable make: http://www.gnu.org/software/autoconf/manual/html_node/Portable-Make.html If there are, at least keeping this change in a separate patch makes it easy enough to omit or amend. Thanks. Please amend and resubmit, I will review then. Now that these rules are all executing from the build tree, there's no need to manually check all the paths match the current directory, or keep long hand-typed duplicate paths scattered around. We can use $@ (and $^ in some places) knowing that they're still correct when we've stayed in the same directory they were calculated for. Okay to push? * Makefile.am (libtoolize, libtoolize.in, libltdl/Makefile.am) (libltdl/config/mkstamp, libltdl/config/ltmain.m4sh) (libltdl/m4/ltversion.m4, tests/testsuite,.tests/defs.in): Make better use of automatic variables. Cheers, Ralf
Re: [PATCH] Skip need_lib_prefix.at on systems without lib prefix on libraries.
Hello Peter, * Peter Rosin wrote on Fri, Sep 17, 2010 at 08:44:43AM CEST: need_lib_prefix.at currently fails with MSVC. I think the test is there to ensure that weird systems continue to work even if the testsuite is running on a normal system. weird in this case are systems with need_lib_prefix set to unknown and normal are those with it set to no. However, there are even weirder systems where need_lib_prefix should perhaps be set to never (i.e. MSVC) but that currently simply sets it to no. never would perhaps be more appropriate since preopen doesn't work right if libs have a lib prefix. I think OS/2 is affected in the same way as MSVC, but I have no means to test that. The below patch makes the need_lib_prefix.at test skip for the even weirder systems, i.e. those where libname_spec does not prefix library names with lib. Ok to push? You may want to compare this patch with thread http://lists.gnu.org/archive/html/libtool-patches/2009-01/msg00174.html which instead makes the test pass for the even weirder systems, but I don't think that is really desired. Why should the code be changed to accommodate a contrived test case? Because this would never happen in the wild, right? The part about this patch which I'm unsure about is this: Does the testsuite otherwise cover well enough the fact that users may name their modules with or without leading 'lib' prefix (and with .la or .dll or .so suffix or so)? IOW, I'd like to be sure we're not hiding anything here. And yes, I think (part of) the log entry from the initial test addition probably deserves to be a comment in the test, so we don't have to look it up again. Subject: [PATCH] Skip need_lib_prefix.at on systems without lib prefix on libraries. * tests/need_lib_prefix.at [MSVC, OS/2]: Skip this test on systems that do not have libraries prefixed with lib. Thanks, Ralf
Re: [PATCH] msvc: don't try to export import descriptors.
Hi Peter, * Peter Rosin wrote on Fri, Sep 24, 2010 at 12:39:13AM CEST: With the patch posted with subject: [PATCH] tests: import variables for MSVC. I found that libtool tries to put some bad symbols in the generated symbol lookup table leading to errors such as this: Ok to push? Yes, with nit below addressed. Subject: [PATCH] msvc: don't try to export import descriptors. * libltdl/m4/libtool.m4 (_LT_LINKER_SHLIBS) [cygwin, mingw] [pw32, cegcc] cl*, exclude_expsyms: Don't export symbols in import libraries related to describing what dll(s) the import library is importing. Fixes problem in tests/demo-make.test and some other tests. --- a/libltdl/m4/libtool.m4 +++ b/libltdl/m4/libtool.m4 @@ -4492,7 +4492,9 @@ m4_if([$1], [CXX], [ ;; cygwin* | mingw* | cegcc*) case $cc_basename in -cl*) ;; +cl*) + _LT_TAGVAR(exclude_expsyms, $1)=['_GLOBAL_OFFSET_TABLE_|_GLOBAL__F[ID]_.*|_NULL_IMPORT_DESCRIPTOR|_IMPORT_DESCRIPTOR_.*'] Does cl generate _GLOBAL_OFFSET_TABLE_ symbols, or _GLOBAL__F* ones? If yes, is the leading underscore for the former optional? I'm guessing no for both of these, which means you can omit them here. I'm also guessing that GCC won't generate them either on w32, but really not so sure about that; and the MSVC case is easier because we don't risk regressions in leaving them out for now. Same below, of course. + ;; *) _LT_TAGVAR(export_symbols_cmds, $1)='$NM $libobjs $convenience | $global_symbol_pipe | $SED -e '\''/^[[BCDGRS]][[ ]]/s/.*[[ ]]\([[^ ]]*\)/\1 DATA/;s/^.*[[ ]]__nm__\([[^ ]]*\)[[ ]][[^ ]]*/\1 DATA/;/^I[[ ]]/d;/^[[AITW]][[ ]]/s/.* //'\'' | sort | uniq $export_symbols' _LT_TAGVAR(exclude_expsyms, $1)=['[_]+GLOBAL_OFFSET_TABLE_|[_]+GLOBAL__[FID]_.*|[_]+head_[A-Za-z0-9_]+_dll|[A-Za-z0-9_]+_dll_iname'] @@ -5064,6 +5066,7 @@ _LT_EOF # The linker will not automatically build a static lib if we build a DLL. # _LT_TAGVAR(old_archive_from_new_cmds, $1)='true' _LT_TAGVAR(enable_shared_with_static_runtimes, $1)=yes + _LT_TAGVAR(exclude_expsyms, $1)=['_GLOBAL_OFFSET_TABLE_|_GLOBAL__F[ID]_.*|_NULL_IMPORT_DESCRIPTOR|_IMPORT_DESCRIPTOR_.*'] _LT_TAGVAR(export_symbols_cmds, $1)='$NM $libobjs $convenience | $global_symbol_pipe | $SED -e '\''/^[[BCDGRS]][[ ]]/s/.*[[ ]]\([[^ ]]*\)/\1,DATA/'\'' | $SED -e '\''/^[[AITW]][[ ]]/s/.*[[ ]]//'\'' | sort | uniq $export_symbols' # Don't use ranlib _LT_TAGVAR(old_postinstall_cmds, $1)='chmod 644 $oldlib' Thanks, Ralf
Re: [PATCH] tests: import variables for MSVC.
Hi Peter, * Peter Rosin wrote on Fri, Sep 24, 2010 at 12:25:14AM CEST: Subject: [PATCH] tests: import variables for MSVC. * tests/depdemo/sysdep.h (EXTERN): New define, saying how to declare variables that might need to be imported. * tests/depdemo/l1/l1.h, tests/depdemo/l2/l2.h, tests/depdemo/l3/l3.h, tests/depdemo/l4/l4.h: Use it. * tests/demo/foo.h (EXTERN): New define, saying how to declare variables that might need to be imported. Use it. * tests/pdemo/foo.h (EXTERN) [MSVC]: Make MSVC import variables if needed. Patch is ok with me if it keeps GCC working, and Chuck is ok with it. You meant to use __declspec everywhere not declspec, even in your text part of the mail, right? A documentation addition describing the most general case of annotations (multiple libraries, mixed static/shared, full MSVC + everything else support) plus simplifications for common cases, - no MSVC, - no shared/static mixing, - rely on auto-import, - ... would be good to have. Something from which I can deduce that your patch must be correct. Of course, if libtool can somehow help with this any more, so much the better. But I'm less optimistic on this than I was those five years ago. :-/ Also, may I remind you that you promised a number of testsuite additions before the release. Thanks, Ralf
Re: libtool-2.2.11a on AIX 5.3 current git master 2010-08-25 /status
* Rainer Tammer wrote on Wed, Sep 22, 2010 at 09:35:38AM CEST:
--- a/README
+++ b/README
@@ -319,6 +319,17 @@ notice and this notice are preserved. This file is
offered as-is,
without warranty of any kind.
+6. Platform specific notes
We already have doc/notes.{texi,txt}.
Cheers,
Ralf
Re: [SCM] GNU Libtool branch, master, updated. v2.4-1-gf0ba93d
Hello Gary, * Gary V. Vaughan wrote on Wed, Sep 22, 2010 at 06:27:27PM CEST: * libltdl/Makefile.inc (LTDL_VERSION_INFO): We've added the static libprefix interface, so new version-info is C+1:0:R+1. libprefix is a *static* local undocumented variable, not public API. There was no reason to bump the API version for this. :-( Ralf
Re: [PATCH 1/r47] maint: help2man targets should rely on the binaries they call.
Hi Eric, * Eric Blake wrote on Wed, Sep 22, 2010 at 07:37:58PM CEST: On 09/22/2010 11:35 AM, Ralf Wildenhues wrote: * Gary V. Vaughan wrote on Wed, Sep 22, 2010 at 07:05:48PM CEST: * Makefile.am (doc/libtool.1, doc/libtoolize.1): Don't rely on the intermediate files, since they might have changed without giving make the opportunity to update the actual binaries that help2man calls in time. No, because 'libtool' is created in the build tree, and the manpages are distributed. Distributed files may not depend on undistributed files, as that breaks building from a read-only source tree. Moreover, help2man is something the user is expected to not have to install prior to building Libtool. Is it acceptable instead to use a nested $(MAKE) invocation prior to running help2man to ensure the binary is up-to-date? Can you show a patch so I can see what you mean? There are differences in semantics between GNU and some non-GNU make implementations in the way that some of the latter may always consider some prerequisite updated if they invoked the rule for updating the prerequisite. I'm hoping these makes die out, but we aren't quite there yet. Cheers, Ralf
Fix regression in command-line length computation.
Oh brother, I just found another regression. :-(
func_fallback_echo isn't even defined inside configure unless we haven't
found a better $ECHO. We should be trying to forkexec an external
utility with the test string, so that we are actually testing the right
limit.
I'm pushing the fix below, which I've checked by using set -x
generously and disabling the getconf mechanism, on GNU/Linux.
One should note that recent Linux kernels do not actually have a limit
on the maximum total command-line length any more, but they do have a
limit on the maximum length of a single command-line argument. Now,
ignoring the presence of getconf for a moment, I figured we should maybe
be able to exploit this, but there's a glitch: our testing of
expr X$cmd : .*
inside both libtool.m4 and ltmain.sh passes the whole command-line as
one argument to expr. It /might/ be possible to get around this in
practice by using XSI shell internals if possible (and eventually we
should be trying something to that extent anyway for efficiency
reasons), but the whole area is sufficiently subtle that I would like
to postpone any further non-regression-fixing action to well later.
Thanks,
Ralf
Fix regression in command-line length computation.
* libltdl/m4/libtool.m4 (LT_CMD_MAX_LEN): Use `env echo' rather
than possibly-undefined func_fallback_echo, to ensure we fork
and exec for this test.
* NEWS: Update.
Regression introduced in v2.2.6-39-g9c3d4d8.
diff --git a/NEWS b/NEWS
index 6e8e0fe..90e33f7 100644
--- a/NEWS
+++ b/NEWS
@@ -4,7 +4,8 @@ New in 2.4.2 2010-12-??: git version 2.4.1a, Libtool team:
* Bug fixes:
- - None yet!
+ - The generic approximation of the command line length limit (when getconf is
+not available) works again. Regression introduced in v2.2.6-39-g9c3d4d8.
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 d812584..6aebb63 100644
--- a/libltdl/m4/libtool.m4
+++ b/libltdl/m4/libtool.m4
@@ -1639,7 +1639,7 @@ AC_CACHE_VAL([lt_cv_sys_max_cmd_len], [dnl
# If test is not a shell built-in, we'll probably end up computing a
# maximum length that is only half of the actual maximum length, but
# we can't tell.
- while { test X`func_fallback_echo $teststring$teststring
2/dev/null` \
+ while { test X`env echo $teststring$teststring 2/dev/null` \
= X$teststring$teststring; } /dev/null 21
test $i != 17 # 1/2 MB should be enough
do
Re: [PATCH 1/r47] maint: help2man targets should rely on the binaries they call.
* Eric Blake wrote on Wed, Sep 22, 2010 at 08:19:28PM CEST: On 09/22/2010 12:13 PM, Ralf Wildenhues wrote: Is it acceptable instead to use a nested $(MAKE) invocation prior to running help2man to ensure the binary is up-to-date? Can you show a patch so I can see what you mean? diff --git i/Makefile.am w/Makefile.am index 6e29a29..f74708c 100644 --- i/Makefile.am +++ w/Makefile.am @@ -327,8 +327,10 @@ update_mans = \ PATH=.$(PATH_SEPARATOR)$$PATH; export PATH; \ $(HELP2MAN) --output=$@ $(srcdir)/doc/libtool.1: $(srcdir)/$(auxdir)/ltmain.sh + $(MAKE) libtool $(update_mans) --help-option=--help-all libtool When -jN has been passed, the two makes may both try to update 'libtool' at the same time, leading to a race. $(srcdir)/doc/libtoolize.1: $(srcdir)/libtoolize.in + $(MAKE) libtoolize $(update_mans) libtoolize Likewise here. Cheers, Ralf
Re: [PATCH 2/4] maint: rearrange Makefile.am in preparation for a follow-up patch.
Hi Gary, * Gary V. Vaughan wrote on Wed, Sep 22, 2010 at 07:05:49PM CEST: * Makefile.am (Libtool scripts.): Move this section below the `Bootstrap.' section... (libtoolize.in): ...except this one which is generated at bootstrap time, and was added into the `Bootstrap.' section. (Libltdl.): Move this section below the `Libtool scripts.' section. This move-only patch is fine with me. I am kind of wondering whether we should wait a little bit for other deal-breaking regressions necessitating an updated release, but then again, in that case we can (and should!) start a maint branch off of v2.4-2-g67bbe04 and do a 2.4b from there. Thanks, Ralf
Re: [PATCH 1/r47] maint: help2man targets should rely on the binaries they call.
* Eric Blake wrote on Wed, Sep 22, 2010 at 08:30:08PM CEST: On 09/22/2010 12:22 PM, Ralf Wildenhues wrote: * Eric Blake wrote on Wed, Sep 22, 2010 at 08:19:28PM CEST: $(srcdir)/doc/libtool.1: $(srcdir)/$(auxdir)/ltmain.sh + $(MAKE) libtool $(update_mans) --help-option=--help-all libtool When -jN has been passed, the two makes may both try to update 'libtool' at the same time, leading to a race. Any ideas on how to avoid such a race? 1) .NOTPARALLEL: Is not a good idea because it will make 'make -j3 check' slow again. :-/ And if you require non-parallel builds, then you can again rely on the fact that Posix make will update prerequisites in the order listed, so that all you need to ensure is that all-am depends on 'libtool' earlier than it depends on '$(srcdir)/doc/libtool.1'. 2) Use a subdir Makefile.am in doc, as SUBDIRS is a serializer. Update the manpage in doc/Makefile.am, and have 'SUBDIRS = . doc' in toplevel so that it is updated first. 3) GNU make could use order-only prerequisites, but that is far too unportable, as many practical GNU make installations are too old still. 4) BUILT_SOURCES = libtool libtoolize Wait ... we are using (4) already. Why does it not work? IOW, I don't see the failure mode which this patch is supposed to fix. Please show a verbose make log exhibiting the failure. I'm guessing there is a different actual reason for the failure. Thanks, ralf
Re: [PATCH 1/r47] maint: help2man targets should rely on the binaries they call.
Hello Gary, * Gary V. Vaughan wrote on Wed, Sep 22, 2010 at 10:29:44PM CEST: On 23 Sep 2010, at 00:35, Ralf Wildenhues wrote: * Gary V. Vaughan wrote on Wed, Sep 22, 2010 at 07:05:48PM CEST: * Makefile.am (doc/libtool.1, doc/libtoolize.1): Don't rely on the intermediate files, since they might have changed without giving make the opportunity to update the actual binaries that help2man calls in time. No, because 'libtool' is created in the build tree, and the manpages are distributed. Distributed files may not depend on undistributed files, as that breaks building from a read-only source tree. Moreover, help2man is something the user is expected to not have to install prior to building Libtool. Yuck. Another reason to always start afresh after making changes rather than relying on make to DTRT :( In my case, ltmain.sh was corrupted, but even though I fixed it, rerunning make ended up leaving the empty manpages generated by a libtool script that had no --version output, and *then* it proceeded to rebuild ltmain.sh. I can try to debug it, if you can show me how to reliably reproduce the failure. Is there no way to make sure help2man doesn't run until the programs it wants to call have been rebuilt, rather than building (and potentially distributing) manpages documenting options from the previous script? I outlined four separate possible approaches for this in another mail in this thread already. Cheers, Ralf
Re: [PATCH 1/r47] maint: help2man targets should rely on the binaries they call.
* Gary V. Vaughan wrote on Wed, Sep 22, 2010 at 10:36:01PM CEST: On 23 Sep 2010, at 01:22, Ralf Wildenhues wrote: * Eric Blake wrote on Wed, Sep 22, 2010 at 08:19:28PM CEST: On 09/22/2010 12:13 PM, Ralf Wildenhues wrote: Is it acceptable instead to use a nested $(MAKE) invocation prior to running help2man to ensure the binary is up-to-date? Can you show a patch so I can see what you mean? $(srcdir)/doc/libtool.1: $(srcdir)/$(auxdir)/ltmain.sh + $(MAKE) libtool $(update_mans) --help-option=--help-all libtool When -jN has been passed, the two makes may both try to update 'libtool' at the same time, leading to a race. $(srcdir)/doc/libtoolize.1: $(srcdir)/libtoolize.in + $(MAKE) libtoolize $(update_mans) libtoolize Likewise here. How about a putting the shell code for libtoolize.in - libtoolize transformation and writing: $(srcdir)/doc/libtoolize.1: $(srcdir)/libtoolize.in $(generate_libtoolize) $(update_mans) libtoolize That will not help, because 'make' may still run it in parallel with the commands from the 'libtoolize' rule. Cheers, Ralf
Re: [PATCH 4/4] maint: simplify and improve safety of bootstrap process.
Hi Gary, * Gary V. Vaughan wrote on Wed, Sep 22, 2010 at 07:05:51PM CEST: I also posted this one before... this time rebased against post-2.4 release HEAD. Okay to push? Assuming strongly that this patch depends upon the semantics of 3/4 applied, I will review this patch after 3/4 is fixed. Thanks, Ralf * Makefile.am (bootstrap_files): List files that need to be generated at bootstrap time before `./configure make' can work. It turns out that this is considerably fewer files than we had thought necessary previously. (bootstrap-deps-prep): Ensure minimum set of required substitution variables are non-empty. (bootstrap-deps): Depend on `bootstrap' files. * bootstrap (Generate bootstrap dependencies): Now that `Makefile.am' is entirely responsible for rebuilding files at bootstrap time, we need only specify the new `bootstrap-deps' target, and supply values for the substitutions checked by `bootstrap-deps-prep'.
Re: [PATCH 3/4] maint: don't leak developer GREP, SED etc into distribution file.
Hi Gary,
* Gary V. Vaughan wrote on Wed, Sep 22, 2010 at 07:05:50PM CEST:
This is the second part of the patch I've split since the last
time I posted. I added Joerg as reporter, and he is already
named in THANKS.
Okay to push?
With this patch applied, the generated libtool script still contains
the following lines:
: ${EGREP=@EGREP@}
: ${FGREP=@FGREP@}
: ${GREP=@GREP@}
: ${LN_S=@LN_S@}
[...]
: ${SED=@SED@}
Now, the lines are all ineffective, because the tag variables (which
will be expanded before these lines) will set all of these variables.
Kind of ugly, but alright if you prefer to clean that up later.
Secondly, with this patch, and with the nits I wrote inline in the patch
below fixed, still freebsd-make (which is from the freebsd-buildutils
7.0-2 Debian package, and is a somewhat older FreeBSD make built for
GNU/Linux) keeps on rerunning aclocal each time I invoke make. This
means something is not quite right in the rebuild rules, and it will
probably show up with at least one of the major BSD systems' make
implementations. Please fix and repost, I will finish review then.
In case of doubt it might be easier to not try to change the actual
dependency graph at all, but merely the rules, which should be enough
to fix the problem you are targeting.
Thanks,
Ralf
* Makefile.am: Having rearranged the file, now apply the actual
changes to follow-up.
(LT_M4SH): Call $(M4SH) with the libtool m4sh directory at the
front of the search path.
(rebuild): Set the shell variable `revision' rather than
`correctver' for clarity.
(edit): Split into two parts...
(bootstrap_edit): ...substitutions that should happen at bootstrap
time...
(configure_edit): ...and substitutions that should not happen until
configure time.
* libtoolize.m4sh (package_revision): For consistency, and ease of
extraction when deciding whether libtoolize needs to be
regenerated.
* Makefile.am (libltdl/m4/ltversion.m4, libltdl/config/ltmain.sh)
(libtoolize.in): Much simplified - only rebuild if the
recalculated timestamp is newer than the timestamp recorded in the
target already; regenerate in one step without changing
directories, using `$(bootstrap_edit)'.
(libtoolize, libtool): Hugely simplified - since we already depend
on `libtoolize.in' and `libltdl/config/ltmain.sh' respectively,
no need to recheck version numbers; also they have the
`$(bootstrap_edit)' substitutions made already, so we can just
go ahead and process with `$(configure_edit)' whenever the
dependencies go out of date.
* Makefile.maint (commit, libltdl/config/mailnotify, bootstrap):
Likewise.
* HACKING (Release Procedure): Remove the note to workaround the
bug fixed by this changeset.
* NEWS (Bug fixes): Mention that this bug is now fixed.
Reported by Joerg Sonnenberger.
--- a/Makefile.am
+++ b/Makefile.am
@@ -43,6 +43,8 @@ noinst_LTLIBRARIES =
lib_LTLIBRARIES =
EXTRA_LTLIBRARIES=
+LT_M4SH = $(M4SH) -B $(srcdir)/$(auxdir)
+
auxdir = libltdl/config
m4dir= libltdl/m4
@@ -57,7 +59,7 @@ timestamp = set dummy `$(MKSTAMP) $(srcdir)`; shift; \
*) TIMESTAMP= ;; \
esac
-rebuild = rebuild=:; $(timestamp); correctver=$$1
+rebuild = rebuild=:; $(timestamp); revision=$$1
# -- #
@@ -75,26 +77,23 @@ EXTRA_DIST += bootstrap $(srcdir)/libtoolize.in
$(auxdir)/ltmain.m4sh \
CLEANFILES += libtool libtoolize libtoolize.tmp \
$(auxdir)/ltmain.tmp $(m4dir)/ltversion.tmp
-edit = sed \
- -e 's,@EGREP\@,$(EGREP),g' \
- -e 's,@FGREP\@,$(FGREP),g' \
- -e 's,@GREP\@,$(GREP),g' \
- -e 's,@LN_S\@,$(LN_S),g' \
- -e 's,@MACRO_VERSION\@,$(VERSION),g' \
- -e 's,@PACKAGE\@,$(PACKAGE),g' \
- -e 's,@PACKAGE_BUGREPORT\@,$(PACKAGE_BUGREPORT),g' \
- -e 's,@PACKAGE_URL\@,$(PACKAGE_URL),g' \
- -e 's,@PACKAGE_NAME\@,$(PACKAGE_NAME),g' \
- -e 's,@PACKAGE_STRING\@,$(PACKAGE_NAME) $(VERSION),g' \
- -e 's,@PACKAGE_TARNAME\@,$(PACKAGE),g' \
- -e 's,@PACKAGE_VERSION\@,$(VERSION),g' \
- -e 's,@SED\@,$(SED),g' \
- -e 's,@VERSION\@,$(VERSION),g' \
- -e 's,@aclocaldir\@,$(aclocaldir),g' \
- -e 's,@datadir\@,$(datadir),g' \
- -e 's,@pkgdatadir\@,$(pkgdatadir),g' \
- -e 's,@host_triplet\@,$(host_triplet),g' \
- -e 's,@prefix\@,$(prefix),g'
+## These are the replacements that need to be made at bootstrap time,
+## because they must be static in distributed files, and not accidentally
+## changed by configure running on the build machine.
+bootstrap_edit = \
+ -e 's,@MACRO_VERSION\@,$(VERSION),g' \
How come the *_edit variables lost their 'sed' command? Is that because
a later patch will use more than one of them inside one sed script? In
that case, OK with me.
+ -e s,@MACRO_REVISION\@,$$revision,g \
+ -e s,@MACRO_SERIAL\@,$$serial,g \
+ -e
Re: [PATCH] relax -rpath argument test for Snow Leopard
Hello, * Peter O'Gorman wrote on Thu, Sep 23, 2010 at 07:43:44AM CEST: On 09/22/2010 09:00 PM, Leo Davis wrote: I had to patch libtool in order to get shared libraries to build with the Snow Leopard '@rpath/' syntax which stands in for the place where the lib gets installed. I thought that this might be useful for more than just myself. Well, there is no method to encode @executable_path or @loader_path in the library install_name either. I always figured that people would just build as normal and then postprocess using install_name_tool(1) if they needed to. Why should libtool treat the Mac OS X @rpath differently to the other two special paths? More generally, $ORIGIN support (which is what a number of other linkers call it, IIUC) should be added completely if it's added, including a portable 'libtool' notation, testsuite coverage and fixing of fall-out, and correct treatment of the non-absolute paths throughout ltmain. I don't know how much work the latter would be, but guessing from the sysroot branch, there is work to do there. The most important question to this end is how to degrade gracefully on systems without such a feature. Cheers, Ralf
Re: [PATCH] maint: edit-readme-alpha shouldn't try to re-edit during dist.
* Gary V. Vaughan wrote on Tue, Sep 21, 2010 at 08:44:41AM CEST: With those addressed, and another successful distcheck, okay to push? Sure. Thanks, Ralf
Re: [PATCH] msvc: eliminate spaces in the library search path.
Hi Peter,
* Peter Rosin wrote on Tue, Sep 21, 2010 at 09:37:16AM CEST:
I know it's late for the release, but I'd like to squeeze this one in
too, if at all possible. After all, it doesn't affect anything but MSVC.
I have questions:
What does Charles have to say to this?
What is $LIB? Is this an API you just made up? If not, where is it
documented? Hmm, we used it before, so I guess that's not new.
Subject: [PATCH] msvc: eliminate spaces in the library search path.
* libltdl/m4/libtool.m4 (_LT_SYS_DYNAMIC_LINKER) [mingw, cygwin]
cl*, sys_lib_search_path_spec: The LIB path variable telling
where MSVC looks for libraries is with high probably containing
s/probably/probability/ ? If yes, I'd rather write is likely to
contain ...
directory names with spaces. Convert those directory names to
the short 8.3 dos form (i.e. without spaces) when storing them
DOS
in sys_lib_search_path_spec, as that is a space separated
variable.
--- a/libltdl/m4/libtool.m4
+++ b/libltdl/m4/libtool.m4
@@ -2313,15 +2313,46 @@ m4_if([$1], [],[
libname_spec='$name'
soname_spec='${libname}`echo ${release} | $SED -e
's/[[.]]/-/g'`${versuffix}${shared_ext}'
library_names_spec='${libname}.dll.lib'
-sys_lib_search_path_spec=$LIB
-if $ECHO $sys_lib_search_path_spec | [$GREP ';[c-zC-Z]:/' /dev/null];
then
- # It is most probably a Windows format PATH.
- sys_lib_search_path_spec=`$ECHO $sys_lib_search_path_spec | $SED -e
's/;/ /g'`
-else
- sys_lib_search_path_spec=`$ECHO $sys_lib_search_path_spec | $SED -e
s/$PATH_SEPARATOR/ /g`
-fi
-# FIXME: find the short name or the path components, as spaces are
-# common. (e.g. Program Files - PROGRA~1)
+
+case $build_os in
+mingw*)
+ sys_lib_search_path_spec=
+ lt_save_ifs=$IFS
+ # Doesn't work to have IFS=; so select some other char that is
+ # invalid in w32 file names.
+ IFS=?
+ for lt_path in `echo $LIB | tr ';' '?'`
You should use the fix that you discovered.
+ do
+IFS=$lt_save_ifs
+# Let DOS variable expansion print the short 8.3 style file name.
+lt_path=`cd $lt_path cmd //C for %i in (.) do @echo %~si`
Can you explain what this command does? I mean, no need to change the
patch, but I don't understand the %~si syntax and I can only infer the
%i and (...) bits, but can't tell whether they are correct, work by
accident, or something else. I'm willing to believe you, but it would
be nice to know for sure.
Can the command fail?
+sys_lib_search_path_spec=$sys_lib_search_path_spec $lt_path
+ done
+ IFS=$lt_save_ifs
+ # Convert to MSYS style.
+ sys_lib_search_path_spec=`$ECHO $sys_lib_search_path_spec | sed -e
's||/|g' -e 's| \\([[a-zA-Z]]\\):| /\\1|g' -e 's|^ ||'`
+ ;;
+cygwin*)
+ # Convert to unix form, then to dos form, then back to unix form
+ # but this time dos style (no spaces!) so that the unix form looks
+ # like /cygdrive/c/PROGRA~1:/cygdr...
+ sys_lib_search_path_spec=`cygpath --path --unix $LIB`
+ sys_lib_search_path_spec=`cygpath --path --dos
$sys_lib_search_path_spec`
+ sys_lib_search_path_spec=`cygpath --path --unix
$sys_lib_search_path_spec | $SED -e s/$PATH_SEPARATOR/ /g`
Can any of the cygpath commands fail?
What about LT_CYGPATH?
+ ;;
+*)
+ sys_lib_search_path_spec=$LIB
+ if $ECHO $sys_lib_search_path_spec | [$GREP ';[c-zC-Z]:/'
/dev/null]; then
+# It is most probably a Windows format PATH.
+sys_lib_search_path_spec=`$ECHO $sys_lib_search_path_spec | $SED
-e 's/;/ /g'`
+ else
+sys_lib_search_path_spec=`$ECHO $sys_lib_search_path_spec | $SED
-e s/$PATH_SEPARATOR/ /g`
+ fi
+ # FIXME: find the short name or the path components, as spaces are
+ # common. (e.g. Program Files - PROGRA~1)
Is this comment still relevant in light of the above changes?
Assuming yes, for the (*) case.
+ ;;
+esac
+
# DLL is installed to $(libdir)/../bin by postinstall_cmds
postinstall_cmds='base_file=`basename \${file}`~
dlpath=`$SHELL 21 -c '\''. $dir/'\''\${base_file}'\''i; echo
\$dlname'\''`~
Thanks,
Ralf
