Re: Bug 9210: fix to replace Linux with GNU/Linux where needed

[Ralf Wildenhues]

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: libtool.texi: copyright notice patch

[Ralf Wildenhues]

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: [PATCH] Correctly concat commands when export_symbols_cmds starts with some 'word'.

[Ralf Wildenhues]

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.

[Ralf Wildenhues]

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: [PATCH] tagdemo: Link to libfoo

[Ralf Wildenhues]

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: Updated patches: Re: bug#8441: Patches making libtool-2.4-1 build under GNU/Hurd

[Ralf Wildenhues]

* 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]
: 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: libtool and OpenMP problem

[Ralf Wildenhues]

* justin wrote on Mon, Mar 14, 2011 at 08:45:29AM CET:
> On 14/03/11 07:24, Ralf Wildenhues wrote:
> > 
> > Care to send a full patch, as per HACKING (in the git source tree)
> > and with ChangeLog entry?

> here you are.

* Rhys Ulerich wrote on Mon, Mar 14, 2011 at 03:54:09PM CET:
> 'Morning,
> 
> Included is a patch to fix an issue where OpenMP flags are discarded by 
> libtool.
> 
> This has popped up a couple of times.  For example,
>https://bugzilla.redhat.com/show_bug.cgi?id=679491
>http://lists.gnu.org/archive/html/bug-libtool/2010-12/msg9.html
>http://lists.gnu.org/archive/html/bug-libtool/2011-03/msg00015.html

Thanks to both of you, and sorry for my abysmal review speed.  I've
taken both patches you sent, mixed them together, wrapped long lines,
and committed in your name, as follows.

The "(tiny change)" just denotes that copyright papers have not been
signed.

Cheers,
Ralf

commit 1b76054f4763a28ae1b01fbeee86ba0c524d1923
Author: Justin Lecher <...>
Date:   Mon Mar 14 08:40:50 2011 +0100

Don't filter OPENMP flags (-openmp & -fopenmp) from linker lines.

If -fopenmp if passed to gcc during linking, it will take care to add all
necessary libs to link correctly for openmp support. Currently libtool 
filters
those flags, similar as it was the case with the threading flags. This 
change
handles the situation for the openmp support similar as before the thread
support was fixed.

http://lists.gnu.org/archive/html/bug-libtool/2010-12/msg9.html
http://lists.gnu.org/archive/html/bug-libtool/2011-03/msg00014.html

* libltdl/config/ltmain.m4sh (func_mode_link): Treat OpenMP
flags like pthreads flags.

Signed-off-by: Ralf Wildenhues 

diff --git a/ChangeLog b/ChangeLog
index 4ed09a3..bc7c2af 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,10 @@
+2011-03-22  Justin Lecher  <...>  (tiny change)
+   Rhys Ulerich  <...>  (tiny change)
+
+   Don't filter OPENMP flags (-openmp & -fopenmp) from linker lines.
+   * libltdl/config/ltmain.m4sh (func_mode_link): Treat OpenMP
+   flags like pthreads flags.
+
 2011-03-14  Ralf Wildenhues  
 
libtoolize: detect -I (without space) in ACLOCAL_AMFLAGS.
diff --git a/libltdl/config/ltmain.m4sh b/libltdl/config/ltmain.m4sh
index 766777f..9358ec5 100644
--- a/libltdl/config/ltmain.m4sh
+++ b/libltdl/config/ltmain.m4sh
@@ -4865,7 +4865,8 @@ func_mode_link ()
continue
;;
 
-  
-mt|-mthreads|-kthread|-Kthread|-pthread|-pthreads|--thread-safe|-threads)
+  -mt|-mthreads|-kthread|-Kthread|-pthread|-pthreads|--thread-safe \
+  |-threads|-fopenmp|-openmp|-mp|-xopenmp|-omp|-qsmp=*)
func_append compiler_flags " $arg"
func_append compile_command " $arg"
func_append finalize_command " $arg"
@@ -5369,7 +5370,8 @@ func_mode_link ()
lib=
found=no
case $deplib in
-   
-mt|-mthreads|-kthread|-Kthread|-pthread|-pthreads|--thread-safe|-threads)
+   -mt|-mthreads|-kthread|-Kthread|-pthread|-pthreads|--thread-safe \
+|-threads|-fopenmp|-openmp|-mp|-xopenmp|-omp|-qsmp=*)
  if test "$linkmode,$pass" = "prog,link"; then
compile_deplibs="$deplib $compile_deplibs"
finalize_deplibs="$deplib $finalize_deplibs"

Re: Consider adding -I $macrodir

[Ralf Wildenhues]

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 -I (without space) in ACLOCAL_AMFLAGS.

* libtoolize.m4sh (func_scan_files): Also accept -I
(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

[Ralf Wildenhues]

[ 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:
> +# 
> +# 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]

Re: Patches for libtool support on NAG Fortran compiler for Darwin OS

[Ralf Wildenhues]

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.

[Ralf Wildenhues]

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

[Ralf Wildenhues]

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

[Ralf Wildenhues]

[ 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(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 2>&1; then
+  LD="${LD-ld}_sol2"
+fi
+;;
   *)
if ${LD-ld} -64 -r -o conftest2.o conftest.o >/dev/null 2>&1; then
  LD="${LD-ld} -64"

links between PDF manuals

[Ralf Wildenhues]

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

[Ralf Wildenhues]

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(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.

[Ralf Wildenhues]

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 2>conftest.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 2>conftest.err
>_lt_result=$?
> -  if test -f conftest && test ! -s conftest.err && test $_lt_result = 0 
> && $GREP forced_load conftest 2>&1 >/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 2>&1 >/dev/null; then

Likewise.

Also, >/dev/null 2>&1  (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

[Ralf Wildenhues]

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: [patch libgfortran] path to libquadmath

[Ralf Wildenhues]

* 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  
> 
>   * ltmain.sh (relink): Use absolute path when hardcoding with -L.
> 

2011-01-09  John David Anglin(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: Oracle Solaris Studio 12.2 compiler incompatibility with libtool

[Ralf Wildenhues]

* 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]
> > > >>: Set to '-Qoption ld ' if we
> > > >>detect Sun Fortran version 8.4 or newer.
> > > >>Report by Terry Dontje.

Re: func_convert_file_cygwin_to_w32 woes

[Ralf Wildenhues]

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 
> 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

[Ralf Wildenhues]

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

[Ralf Wildenhues]

[ 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!

[Ralf Wildenhues]

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 , 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.
+Copyright (C) 2011 

Re: OS/2: command-line length limit

[Ralf Wildenhues]

* 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(tiny change)

Set command line length limit for OS/2.
* libltdl/m4/libtool.m4 (LT_CMD_MAX_LEN) [os2]
: 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: PATCH RFA: Add Go support

[Ralf Wildenhues]

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  

* 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 variables

Re: Oracle Solaris Studio 12.2 compiler incompatibility with libtool

[Ralf Wildenhues]

* 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]
> >>: 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 2>&1 | 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: wrong postdep_objects for CXX when using "-flto -fuse-linker-plugin"

[Ralf Wildenhues]

* 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(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: PIC flags not found for mpif77(ifort)

[Ralf Wildenhues]

* 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: ping: [PATCH libtool] hardcoded path to dependent shared libraries on 32-bit hpux (libquadmath)

[Ralf Wildenhues]

* 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  
> > 
> > * 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: OS/2: command-line length limit

[Ralf Wildenhues]

* 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

Re: PIC flags not found for mpif77(ifort)

[Ralf Wildenhues]

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

OS/2: command-line length limit (was: Enhanced OS/2 port)

[Ralf Wildenhues]

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: Enhanced OS/2 port

[Ralf Wildenhues]

* 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: Enhanced OS/2 port

[Ralf Wildenhues]

[ 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   (tiny change)
Ralf Wildenhues  

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 r

Re: PIC flags not found for mpif77(ifort)

[Ralf Wildenhues]

* 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: PIC flags not found for mpif77(ifort)

[Ralf Wildenhues]

Hello Christian,

* Christian Rössel wrote on Fri, Dec 10, 2010 at 02:56:51PM CET:
> ./configure --enable-shared F77=mpif77 ...
> 
> where mpif77 translates to
> 
> ifort -I/opt/parastation/mpi2-intel/include
> -L/opt/parastation/mpi2-intel/lib -Wl,-rpath
> -Wl,/opt/parastation/mpi2-intel/lib -lmpich -lpthread
> -L/opt/parastation/lib64 -Wl,-rpath,/opt/parastation/lib64
> -Wl,--enable-new-dtags -lpscom -lrt
> 
> configure fails in finding PIC flags (mpicc (icc) and mpicxx (icpc) PIC
> flags are discovered though):
> 
> configure:17627: checking for mpif77 option to produce PIC
> configure:17899: result:
> 
> There is no more output concerning the PIC flags in config.log.
> With F77=ifort everything works as expected:
> 
> configure:16805: checking for ifort option to produce PIC
> configure:17077: result: -fPIC

Yeah, that's because libtool.m4 macros partly match by name, unless the
compiler claims to be GCC.  A bit dumb, sure, but it's not easy to avoid
because portable testing of these flags is not trivial.  We might have
to think about a more general way to extract the compiler name from an
MPI driver (-show and -showme come to mind).

For the moment you should be able to work around it using
  configure lt_cv_prog_compiler_pic_F77=-fPIC \
lt_cv_prog_compiler_pic_FC=-fPIC \

but I'm not sure if you also need fixes for missing -static and -Wl,
flags (lt_prog_compiler_wl_F77 and lt_prog_compiler_static_F77 ...).
This requires Libtool >= 2.4.

Alternatively, the untested patch below should help as well.  Can you
try it out?

Thanks for the report,
Ralf

Fix PIC flags with mpif77 using ifort on GNU/Linux.

* libltdl/m4/libtool.m4 (_LT_COMPILER_PIC) [linux]:
Match Intel compiler also using $CC -V output, to avoid false
negatives with compiler drivers like mpif77.
Report by Christian Rössel.

diff --git a/libltdl/m4/libtool.m4 b/libltdl/m4/libtool.m4
index 1f61140..e735c75 100644
--- a/libltdl/m4/libtool.m4
+++ b/libltdl/m4/libtool.m4
@@ -4338,6 +4338,11 @@ m4_if([$1], [CXX], [
  _LT_TAGVAR(lt_prog_compiler_static, $1)='-Bstatic'
  _LT_TAGVAR(lt_prog_compiler_wl, $1)='-Wl,'
  ;;
+*Intel*\ [CF]*Compiler*)
+ _LT_TAGVAR(lt_prog_compiler_wl, $1)='-Wl,'
+ _LT_TAGVAR(lt_prog_compiler_pic, $1)='-fPIC'
+ _LT_TAGVAR(lt_prog_compiler_static, $1)='-static'
+ ;;
esac
;;
   esac

Re: libtool --help: honor $AUTOCONF, $AUTOMAKE

[Ralf Wildenhues]

* 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: docs: Libtool configuration diagram.

[Ralf Wildenhues]

* 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 and CUDA

[Ralf Wildenhues]

* 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: Libtool and CUDA

[Ralf Wildenhues]

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: Libtool and CUDA

[Ralf Wildenhues]

Hi Peter,

* Peter O'Gorman wrote on Mon, Dec 06, 2010 at 05:23:12AM CET:
> On 12/05/2010 09:34 PM, Ralf Wildenhues wrote:
> 
> >Does this patch fix things for you?  As far as I see, you should be
> >getting -fPIC passed instead of -fno-common, so it's not completely
> >clear that this is right, or what other changes MacPorts has done to
> >their glibtool code over upstream Libtool.  Please also send 'glibtool
> >--config' output.
> >
> >OK to apply?
> 
> Unless Pawel reports that it works for him, no. This doesn't make
> sense to me.

Why?

> MacPorts doesn't appear to have patched their libtool at all:
> http://trac.macports.org/browser/trunk/dports/devel/libtool/Portfile

OK.  The installed glibtool is quite certainly configured to use gcc not
nvcc.  If you configure libtool to use nvcc though, the current code
would get '-Xcompiler -fPIC' on darwin.  I only have nvcc.pdf from an
older version that didn't provide documentation for MacOS installation,
but it didn't mention PIC code at all, which is not too surprising given
that the Cuda-specific parts don't care all that much about what happens
on the CPU.  So IMVHO it would make sense to just pass through the PIC
flag to the underlying gcc compiler driver, whatever the flag is.
What am I missing?

Thanks,
Ralf

> >_LT_TAGVAR(lt_prog_compiler_wl, $1)='-Xlinker '
> >-  _LT_TAGVAR(lt_prog_compiler_pic, $1)='-Xcompiler -fPIC'
> >+  if test -n "$_LT_TAGVAR(lt_prog_compiler_pic, $1)"; then
> >+_LT_TAGVAR(lt_prog_compiler_pic, $1)="-Xcompiler 
> >$_LT_TAGVAR(lt_prog_compiler_pic, $1)"
> >+  fi

Re: Libtool and CUDA

[Ralf Wildenhues]

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)
: 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: Oracle Solaris Studio 12.2 compiler incompatibility with libtool

[Ralf Wildenhues]

* 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]
>   : 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 2>&1 | 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: Oracle Solaris Studio 12.2 compiler incompatibility with libtool

[Ralf Wildenhues]

* Ralf Wildenhues wrote on Thu, Nov 18, 2010 at 09:23:17PM CET:
> 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

That should've been 'Sun Studio 5.9'.

> 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]
>   : Set to '-Qoption ld ' if we
>   detect Sun Fortran version 8.4 or newer.
>   Report by Terry Dontje.

libtool --help: honor $AUTOCONF, $AUTOMAKE

[Ralf Wildenhues]

I came across an interesting bug: the perl coverage output for a full
run of the Automake test suite was showing a single invocation of the
installed automake program, rather than the uninstalled
  $builddir/tests/automake-1.11a

which should have been run.

Some tracking revealed that this happened in automake/tests/subobj9.test
which looks innocent enough.  Turns out that it comes from './libtool
--help' which tries to be helpful in printing some 'automake --version'
output.  This is flawed for a couple of reasons: the automake command at
the time './libtool --help' is run may be unrelated to the automake used
for bootstrapping the package; also, the user may have wanted to use an
override by setting $AUTOMAKE.

Now, the issue could be fixed with the two patches below, to Libtool and
Automake, respectively.  Question is whether we could do better than
that:

In Libtool, getopt.m4sh is used for the libtoolize and libtool scripts.
For libtoolize, it seems appropriate to do as below.  For libtool, the
best answer would be the Autoconf and Automake versions used to
bootstrap the package that created this particular libtool script.

Comments before I apply?

Thanks,
Ralf

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.

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.

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
  }

docs: Libtool configuration diagram.

[Ralf Wildenhues]

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: [patch] allow --with-pic to accept package names

[Ralf Wildenhues]

Hello,

* Ollie Wild wrote on Fri, Nov 19, 2010 at 02:46:46AM CET:
> On Wed, Nov 10, 2010 at 1:41 PM, Ralf Wildenhues wrote:
> >
> > I'm pushing the patch with the diff below squashed in, hope you
> > don't mind.
> 
> Ralf, being as you're a dual libtool / GCC maintainer, what is the
> process for getting libtool changes pushed to GCC?  Do I just wait for
> a new libtool release, or is it reasonable / preferred to send
> individual patches to GCC as well?

Well, we want to import the newer Libtool files in GCC, esp. in order to
get LTO fixed, but the current libtool.m4 will cause --with-sysroot
regressions because GCC's and Libtool's idea of that switch are
different.  Paolo, have you had any chance to look into this yet?

Generally, importing files from Libtool to GCC is documented in
<http://gcc.gnu.org/codingconventions.html>; you typically copy them
over, and either do a full build with --enable-maintainer-mode, or run
autoreconf -v in every directory containing a configure script.  And
of course test the resulting patch in every way you can conceive of it
causing regressions.  ;-)

Changes to Libtool files should first be proposed and pushed upstream
then imported into GCC, in general.

Cheers,
Ralf

Re: Oracle Solaris Studio 12.2 compiler incompatibility with libtool

[Ralf Wildenhues]

* 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  

Fix $wl setting for Solaris Studio 12.2 f90 on GNU/Linux.
* libltdl/m4/libtool.m4 (_LT_COMPILER_PIC) [linux]
: 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 2>&1 | 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: Rebuild menus in the manual.

[Ralf Wildenhues]

* Eric Blake wrote on Mon, Nov 15, 2010 at 05:17:54PM CET:
> On 11/14/2010 10:10 AM, Ralf Wildenhues wrote:
> > 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.)
> 
> You can also add an @anchor{old name} next to the new name, to avoid
> having to create manual symlinks (the existence of the anchor will mean
> that the old name still goes somewhere in the web).  For example, see
> how autoconf.texi @node Specifying Target Triplets has an
> @anchor{Specifying Names}.

Nice!  I wasn't aware of that, thanks.  That means we can deal with node
renames and similar changes in the manual completely internally, that is
definitely better than hacking around it in some places.

I'm pushing the patch now.

Cheers,
Ralf

Rebuild menus in the manual.

[Ralf Wildenhues]

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
 
 @node

Re: Eliminate hardcode_libdir_flag_spec_ld tag variable.

[Ralf Wildenhues]

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)
> : Remove all instances of the tag
> variable.
> (_LT_LINKER_SHLIBS) [linux, xlf] :
> 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

Re: LD_LIBRARY_PATH_64 on Solaris

[Ralf Wildenhues]

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)
> : 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: libtool does not recognize lib64 -- Update to Olly Betts' patch

[Ralf Wildenhues]

Hello, and sorry for the looong delay,

* Toshio Kuratomi wrote on Thu, Oct 21, 2010 at 08:18:58PM CEST:
> On Mon, Sep 20, 2010 at 2:17 PM, Toshio Kuratomi  wrote:
> > On Mon, Sep 20, 2010 at 10:25:06PM +0200, Ralf Wildenhues wrote:
> >> > Anything I need to do to get this looked at?
> >>
> >> I'm looking at it.  The patch has issues, the approach itself has issues
> >> too, and is definitely not ready for the upcoming release.
> >>
> >> Details when I have them sorted out.
> >>
> > No problem, thsanks for looking.
> >
> > /me Awaits list of things to work on :-)
> 
> 
> ping?  I'm happy to take up where Ollie left off to improve the
> approach but I need to know what the issues that need to be resolved
> are :-)  There were no mentioned issues (except first run speed) when
> Olly first proposed his patch:
> http://lists.gnu.org/archive/html/libtool-patches/2010-06/msg00146.html

I haven't tested it much, so it would be nice if somebody could try out a
few distros/versions.  On one system here, there are dangling links in
/usr/lib, and it seems to take *very* (I mean *really*) long for
ldconfig to finish (maybe even hang?).

The code mistreats cross-compilation, but the code we have now does that
in the same way, so no big difference.

The patch uses \? in sed which is unportable to non-GNU sed, but can be
replaced by \{0,1\} portably (when the s delimiter is also changed from
comma to, say, |):
  /sbin/ldconfig -N -X -v 2>/dev/null | sed 's|^\(/.*\):\( 
(.*)\)\{0,1\}$|\1|p;d'

(Ignore that Solaris sed won't cope, see above note about cross issues.)

Are there any distros where ldconfig is not in /sbin, or the output
format varies?  Should we consider using the old code as fall-back,
at least when ldconfig dies or errors out for some reason?

One big issue is that the patch will add the wrong bitness directories
to the search path also, which means that libtool will find libraries
wrongly, and if there are .la files there also easily cause link
failures and such.  I'm not exactly sure how to fix this.

I'm not sure if this list is exhaustive.

Thanks,
Ralf

Re: Fix cwrapper test failure with --disable-static.

[Ralf Wildenhues]

* Charles Wilson wrote on Wed, Nov 10, 2010 at 11:23:52PM CET:
> On 11/10/2010 4:07 PM, Ralf Wildenhues wrote:
> > * Charles Wilson wrote on Wed, Nov 10, 2010 at 09:46:54PM CET:
> >> 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).
> 
> I thought that in those cases, the .lo file would redirect to the
> regular, non-pic .o but I guess what actually happens is that you get
> neither the .lo NOR the .libs/.o pic file, and you see only the non-pic .o.

I'm not sure I follow.

If you pass --disable-static, then a command to build an .lo file will
build that, plus the .libs/.o PIC file.  There just will not be an .o
file outside of the .libs directory.

We could of course do 'test -f m.$OBJEXT || o=$objdir/m.$OBJEXT'
or something like that, but I didn't really want to make the code
more complicated than necessary.

> > automake-generated code also compiles
> > program sources without libtool, so the change was, to me, the canonical
> > one.
> 
> Meh...only if the target is explicitly *.o   If it's .lo, then
> $(LTCOMPILE) is used, and then libtool generates either or both of the
> .o's itself, as determined by the system defaults and/or
> --enable-{shared,static}.

Sure.  But automake will let the target explicitly be *.$(OBJEXT) for
objects to be linked into programs.

> > Is there a portability issue associated with it?
> 
> I don't think so. It was simply a stylistic question: we're testing
> libtool, so...use libtool. :-)

Sure.  But we are allowed to test it in the same way that it is commonly
used.  ;-)

Cheers,
Ralf

Re: [patch] allow --with-pic to accept package names

[Ralf Wildenhues]

Hi Ollie,

* Ollie Wild wrote on Mon, Nov 08, 2010 at 05:09:44AM CET:
> On Sat, Oct 23, 2010 at 2:32 AM, Ralf Wildenhues wrote:
> >
> > 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.  ;-)
> 
> Here's an updated patch which includes a new test, documentation, and
> fixed variable names.  Please take another look.

> 2010-11-07  Ollie Wild  
> 
>   Modify --with-pic to support per-package configurations.
>   * libltdl/m4/libtool.m4:  Modify --with-pic to accept a list of
>   package names.  Modelled off --enable-shared.
>   * tests/with-pic.at: New test.
>   * Makefile.am (TESTSUITE_AT): Add tests/with-pic.at.
>   * doc/libtool.texi (LT_INIT): Enhance documentation of
>   --with-pic configure flag.
>   * NEWS (New features): Mention that --with-pic now accepts a
>   comma-separated list of package names.

Thanks.  The patch looks good to me, with only trivial nits:
the testsuite addition should be sorted under the 'libtool script
generation' banner rather than with the sysroot tests, and I don't
think that it is necessary to skip the test if static libraries are
disabled: your --disable-shared will (should!) lead to static libs
being enabled everywhere.

I'm pushing the patch with the diff below squashed in, hope you
don't mind.

Cheers,
Ralf

diff --git a/Makefile.am b/Makefile.am
index 53c8e8b..66f38b1 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -502,6 +502,7 @@ TESTSUITE_AT= tests/testsuite.at \
  tests/ctor.at \
  tests/exceptions.at \
  tests/early-libtool.at \
+ tests/with-pic.at \
  tests/no-executables.at \
  tests/deplibs-ident.at \
  tests/configure-iface.at \
@@ -511,8 +512,7 @@ TESTSUITE_AT= tests/testsuite.at \
  tests/darwin.at \
  tests/dumpbin-symbols.at \
  tests/deplibs-mingw.at \
- tests/sysroot.at \
- tests/with-pic.at
+ tests/sysroot.at
 
 EXTRA_DIST += $(srcdir)/$(TESTSUITE) $(TESTSUITE_AT) 
$(srcdir)/tests/package.m4
 
diff --git a/tests/with-pic.at b/tests/with-pic.at
index a80535b..c01e5d7 100644
--- a/tests/with-pic.at
+++ b/tests/with-pic.at
@@ -26,8 +26,6 @@ eval `$LIBTOOL --config | $EGREP '^(pic_flag|FGREP)='`
 
 AT_CHECK([test "z$pic_flag" != "z" || exit 77])
 AT_CHECK([test "$at_srcdir" != . || exit 77])
-AT_CHECK([$LIBTOOL --features | $FGREP 'enable static libraries' || exit 77],
-[], [ignore], [ignore])
 
 CONFIGURE=$abs_top_srcdir/tests/demo/configure
 : ${MAKE=make}

Re: Fix cwrapper test failure with --disable-static.

[Ralf Wildenhues]

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

Fix cwrapper test failure with --disable-static.

[Ralf Wildenhues]

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: ltmain.sh patch: -all-dynamic option

[Ralf Wildenhues]

* 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

[Ralf Wildenhues]

* 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: [patch] allow --with-pic to accept package names

[Ralf Wildenhues]

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


Please indicate whether you are still working on any of those issues,
and which.

Thanks,
Ralf

> 2010-10-21  Ollie Wild  
> 
>   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: ltmain.sh patch: -all-dynamic option

[Ralf Wildenhues]

Hello Karl-Andre',

* 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:

> *** ltmain.sh.orig   Sat Oct 30 11:35:37 2010
> --- ltmain.sh   Sat Oct 30 11:37:50 2010
> ***
> *** 5173,5178 
> --- 5173,5185 
>   fi
>   prefer_static_libs=yes
>   ;;
> + -all-dynamic)
> +   if test "$build_libtool_libs" = no; then
> + func_warning "unable to build only dynamic libraries in this 
> configuration"
> +   fi
> +   build_old_libs=no
> +   prefer_static_libs=no
> + ;;
> -static)
>   if test -z "$pic_flag" && test -n "$link_static_flag"; then
> dlopen_self=$dlopen_self_static
> 
> Would it be possible to have this kind of functionality included in
> the official libtool distribution?

Thanks for the report and patch.  What does -all-dynamic bring you that
either of the following won't?
- configure with --disable-static,
- add --tag=disable-static to AM_LIBTOOLFLAGS or libfoo_la_LIBTOOLFLAGS.

Thanks,
Ralf

Re: PATCH RFA: Add Go support

[Ralf Wildenhues]

Hello Ian,

let's move this part of the discussion to the automake@ list.
And sorry for delays, I cannot help that ATM.

* Ian Lance Taylor wrote on Wed, Oct 13, 2010 at 09:58:49PM CEST:
> Ralf Wildenhues writes:
> > * 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?
> 
> Note that when I say a package I don't mean an entire program.  A
> package in Go is like a single library, or what some languages call a
> module.  E.g., the standard Go library has a fmt package, an os package,
> a math package, etc.  When compiling Go, you must pass all files in a
> package to the compiler at the same time.  In principle part of the
> compilation of a single package could be parallelized, but not in any
> simple or straightforward way.  You can group many different Go packages
> together into a single .a or .so file.

OK.  So IIUC one example dependency graph would be something like this:

  ( sin.go cos.go exp.go ) -> math.OBJEXT -> libfem.so
  ( grid.go solver.go )-> sub/pdesolve.OBJEXT ---^

where the sets of .go files are distinct, the sets of object files
("packages") cannot be derived from their inputs (neither their names
nor their contents?) but rather specified only in the makefile, and
objects are subsumed in (static or shared) libraries or in programs
as usual.  OBJEXT may be o or obj (for w32) or lo (for libtool).

We need a bit of new notation for this, and we need to teach automake
about languages that shouldn't have renamed objects even in the presence
of per-object flags.

With libtool, naming wouldn't sound so hard, one could just go with
something like:

lib_LTLIBRARIES = libfem.la
libfem_la_LIBADD = math.lo sub/pdesolve.lo  # yes, _LIBADD
math_lo_SOURCES = sin.go cos.go exp.go
sub_pdesolve_lo_SOURCES = grid.go solver.go

Without libtool, we could canonify $(OBJEXT) as _o:

bin_PROGRAMS = fem
fem_LDADD = math.$(OBJEXT) sub/pdesolve.$(OBJEXT)
math_o_SOURCES = sin.go cos.go exp.go
sub_pdesolve_o_SOURCES = grid.go solver.go

but that looks fairly ugly to me already.  Better ideas?

I'm sure users will ask to generalize the scheme for other languages,
where Automake operates differently now.  I'm not yet sure whether that
is a reason to worry or a good thing.  ;-)


> > 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?
> 
> Only one object file is created for each package.  It can go wherever.

Should a package be an installable entity?  At that point we should
think about using a separate new _PRIMARY for it.

> > 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?
> 
> Sure.
> 
> > If the latter is to be supported, then
> > things like overlapping sources become a problem (i.e., both libfoo and
> > libbar use baz.o).
> 
> That can not happen, because baz.go can only be in one package.

Setups like the following are not possible in theory?

if WANT_FEATURE_IN_FOO
foo_lo_SOURCES += baz.go
else
if WANT_FEATURE_IN_BAR
bar_lo_SOURCES += baz.go
endif
endif

Thanks,
Ralf

Re: [RFC] w32 and Libtool.

[Ralf Wildenhues]

Hi Peter,

* Peter Rosin wrote on Mon, Nov 01, 2010 at 10:12:01AM CET:
> For PDF and DVI, the text looks like this:
> 
>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 (see Section “Options specific to i386 PE targets” in Using ld, the GNU 
> linker).
> 
> But the link in the PDF document is only useful to open the ld.pdf file,
> I'm not successful in getting the link to take me further than that no
> matter how I feebly try to put it.

Could you report this bit to bug-texinfo, please?

Thanks, also for your work on the patch!
Ralf

Re: [RFC] w32 and Libtool.

[Ralf Wildenhues]

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: libtool-2.2.10: print vs. printf

[Ralf Wildenhues]

[ 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: [RFC] w32 and Libtool.

[Ralf Wildenhues]

[ 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, au

Re: libtool-2.2.10: print vs. printf

[Ralf Wildenhues]

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

[Ralf Wildenhues]

Hello Ollie,

* Ollie Wild wrote on Fri, Oct 22, 2010 at 06:32:08PM CEST:
> 2010-10-21  Ollie Wild  
> 
>   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])

LD_LIBRARY_PATH_64 on Solaris (was: [OMPI devel] "make check" (libtool?) failure on Solaris/SPARC (1.5rc5 and 1.4.3rc1))

[Ralf Wildenhues]

[ moving from open-mpi-devel to libtool-patches ]

Hello Paul, all,

this took quite a bit longer than I expected, and it also turned out
to be quite a bit longer than I initially expected.  ;-)

> * Paul H. Hargrove wrote on Thu, Aug 26, 2010 at 10:14:22PM CEST:
> >  I just had a thought on this one:  In my environment on this
> > platform I have LD_LIBRARY_PATH_32 and LD_LIBRARY_PATH_64 set.  It
> > seems possible to me that this is causing the loader to ignore the
> > LD_LIBRARY_PATH setting that libtool's wrapper script sets when
> > executing uninstalled programs in the build directory, as during
> > "make check".
> >  So, I tried removing these from my environment and editing
> > ~/.bashrc not to set them.  The result is a SUCCESSful "make check"!

Yep.  Quoting ld.so.1(1) from Solaris 10 (Sparc):

 Each environment variable can be specified with a _32 or _64
 suffix.   This  makes  the  environment  variable  specific,
 respectively, to 32-bit or 64-bit processes.  This  environ-
 ment  variable  overrides  any  non-suffixed  version of the
 environment variable that may  be  in  effect.   Environment
 variables  specified without a value, that have a _32 or _64
 suffix, effectively cancel any associated  generic  environ-
 ment variable setting.

Here's what I think are the semantics relevant to Libtool:

- programs executed by libtool might be 32 or 64 bits, so in the most
general case we need the settings from up to two of the three variables
LD_LIBRARY_PATH LD_LIBRARY_PATH_32 LD_LIBRARY_PATH_64, in the following
named L, L32, and L64.

- we cannot assume L, L32, and L64 are set the same at configure time as
they are at, say, runtime of uninstalled executables.

- we cannot blindly append :$L to L32 if L32 is already set, because the
entries from L could actually contain old libraries not to be used (for
all programs not from us, we want to ensure an error is still an error).
Or they could contain unwanted 64bit libraries.  Same of course with 32
and 64 roles swapped.

- we cannot prepend $L32: to L and then unset L32, because those
directories could also contain bogus 64bit libraries then loaded by
64bit helper programs.  Likewise with roles swapped.

- a quick test shows that if you have a directory with 64bit liba.so.1
and one later with 32bit liba.so.1, then if both directories are in one
of the paths, the runtime linker will load the right one and not print
complaints about the wrong one found earlier.  Good.


Taken together, that means it should be possible to implement one of
these alternative strategies for a 32-bit build (analogous for 64bit of
course):

1) if L32 is already set, prepend to L32 in addition to prepending to L.

2) if L32 is already set, prepend to L32 instead of prepending to L.

(1) seems a bit safer for the case that we detect the bitness wrongly,
or the link editor behaves differently than the runtime linker;
(2) increases the environment less.

An actual implementation could thus be a new libtool variable
aux_shlibpath_var; if nonempty, we check whether the variable it names
is set, and if yes, we prepend to that instead of or additionally.


Now, how about other multi-ABI systems?

I checked IRIX, which has very similar runtime linker semantics
regarding the variables LD_LIBRARY64_PATH and LD_LIBRARYN32_PATH.

Hmm, IRIX also has _RLD_ROOT, _RLD64_ROOT and _RLDN32_ROOT, which in
hierarchy sit even before DT_RPATH, so could be (ab)used as alternate
shlibpath_var settings that override the runpath (unlike LD_LIBRARY_PATH
and sisters on this system) ...

HP-UX/hppa64, according to documentation, has in addition to SHLIB_PATH
also LD_LIBRARY_PATH.  The latter takes precedence over the former, but
does not turn the former off.  Of course either are only enabled when +s
has been used for linking (which we don't deal with quite correctly
yet).

OS X has DYLD_FALLBACK_LIBRARY_PATH, but it has lower precedence.

Note that this is not intended for systems which have environment
variables which differ in whether they override DT_RPATH (run path
entries encoded in the executable or library).


So, I've worked on a patch for this, and this is what I've come up with
so far.  I say so far, because the patch could probably do with a few
more testsuite additions and maybe some factoring, but I'm at a stage
where I'd like some preliminary review that what I'm doing is sensible
and will be welcome when finished.  It implements approach (2) above.

The two patches (well, slightly previous versions of them) have been
tested on IRIX, HP-UX/hppa64, Solaris/i386 with both the shlibpath_var
and the aux_shlibpath_var unset (no regression to previous test
results).  They have also been tested with LD_LIBRARY_PATH_32 set on
Solaris/i386, fixing all of several previous test failures.

I would test the final version again before pushing.

I'm a bit worried whether $host_cpu is a good indicator for bitness on
Solaris (it will be wrong if -m64 is put in CFLAGS rather

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))

[Ralf Wildenhues]

[ 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)
: Remove all instances of the tag
variable.
(_LT_LINKER_SHLIBS) [linux, xlf] :
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(h

libtool-next patch queue

[Ralf Wildenhues]

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 
> 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 
> 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 
> 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: bindir.at takes forever.

[Ralf Wildenhues]

* 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

Re: Fix linking from only convenience archives with gfortran on Darwin.

[Ralf Wildenhues]

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 name&email 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.

[Ralf Wildenhues]

[ moving from libtool@ to -patches ]

Hi Dave,

* Dave Korn wrote on Sun, Oct 03, 2010 at 01:15:46PM CEST:
> On 28/09/2010 21:36, Ralf Wildenhues wrote:
> > * Peter Rosin wrote on Tue, Sep 28, 2010 at 02:28:48PM CEST:
> >> I have been looking at the loops in tests/bindir.at and I see
> >> this:
> > 
> > bindir.at has several problems.
> 
>   Argh.  Sorry for the mess, it's the first and only libtool test I've ever
> written and I didn't have much to go on except copying from the others that
> seemed nearest what I wanted to do.  It certainly wouldn't hurt to cut down
> that inner loop down to a half or third of what it currently tests, I was just
> erring on the side of thoroughness.

Cool.  And no need to apologize, those are all things we should have
caught during review, or we can just fix now.  It's great that you have
provided a test case at all!

Anyway, here we go with bindir cleanup.  I have tested the following
couple of patches on native MinGW, Cygwin, GNU/Linux, and AIX (where it
fixes a spurious testsuite failure), as well as a GNU/Linux -> MinGW
cross.  All pass the bindir tests now.

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,
Ralf

tests: remove unneeded 'bindir compile check' test.

* tests/bindir.at (bindir compile check): Remove.

diff --git a/tests/bindir.at b/tests/bindir.at
index 40e67cc..ebe1baa 100644
--- a/tests/bindir.at
+++ b/tests/bindir.at
@@ -1,6 +1,6 @@
 # bindir.at -  Test the -bindir option
 #
-#   Copyright (C) 2009 Free Software Foundation, Inc.
+#   Copyright (C) 2009, 2010 Free Software Foundation, Inc.
 #   Written by Dave Korn, 2009
 #
 #   This file is part of GNU Libtool.
@@ -58,25 +58,8 @@
 # statement in libtool.m4sh around where the 'tdlname' variable is set.
 
 
-# Verify compiling works, and skip remaining tests if not.
-#
-
-AT_SETUP([bindir compile check])
-
-AT_DATA([simple.c] ,[[
-int main() { return 0;}
-]])
-
-$CC $CPPFLAGS $CFLAGS -o simple simple.c || noskip=false
-rm -f simple
-
-AT_CHECK([$noskip || (exit 77)])
-
-AT_CLEANUP
-
-
-# Now run the tests themselves.  First a simple test that we can
-# build and run an executable with a couple of tiny libraries.
+# First a simple test that we can build and run an executable with a couple of
+# tiny libraries.
 
 AT_SETUP([bindir basic lib test])
 


Fix bindir check logic, and relax non-bindir case for AIX.

* tests/bindir.at (bindir install tests): Rewrite checks for
place of the installed shared library in two separate tests,
depending on whether -bindir is supposed to have an effect or
not.  In the positive case, make the test stricter so that we
reject libraries in $libdir.  In the negative case, do not
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.
Report by Peter Rosin.

diff --git a/tests/bindir.at b/tests/bindir.at
index ebe1baa..3fa185c 100644
--- a/tests/bindir.at
+++ b/tests/bindir.at
@@ -138,14 +138,14 @@ AT_CHECK([$LIBTOOL --mode=link --tag=CC $CC -o 
main$EXEEXT $CPPFLAGS $CFLAGS $LD
 # here, that will be covered by the later tests; we've rpath'd things
 # so that they can all be run in situ.
 
-LT_AT_NOINST_EXEC_CHECK([$LIBTOOL], [], [0], [ignore], [ignore], 
[--mode=execute ./main$EXEEXT])
+LT_AT_NOINST_EXEC_CHECK([./main])
 
 # Ensure libraries can be found on PATH, if we are on one
 # of the affected platforms, before testing the shared version.
 
 func_save_and_prepend_path $curdir/$objdir
 $bindirneeded && {
-  LT_AT_NOINST_EXEC_CHECK([$LIBTOOL], [], [0], [ignore], [ignore], 
[--mode=execute $objdir/main$EXEEXT])
+  LT_AT_NOINST_EXEC_CHECK([$objdir/main])
 }
 
 #  In fact, prepending the PATH as above is superfluous on the windows
@@ -182,7 +182,7 @@ case "$host_os" in
 esac
 
 eval "`$LIBTOOL --config | grep '^build_libtool_libs='`"
-AT_CHECK([test "$build_libtool_libs" = yes || (exit 77)])
+AT_CHECK([test "$build_libtool_libs" = yes || exit 77])
 
 
 # These routines save the PATH before a test and restore it after,
@@ -275,7 +275,11 @@ do
   # '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.
-  AT_CHECK([$bindirneeded && { test -f $libdir/../bin/???foo-0.dll || ls 
$libdir/../bin/*foo*0* 2>/dev/null ; } || ls $libdir/*foo*0* 2>/dev/null], [], 
[ignore], [ignore])
+  if $bindirneeded; then
+AT_CHECK([test -f $li

Fix linking from only convenience archives with gfortran on Darwin. (was: [libtool 2.2.10] testsuite: 28 29 102 failed)

[Ralf Wildenhues]

* Ralf Wildenhues wrote on Wed, Oct 13, 2010 at 08:35:52PM CEST:
> > Thanks for the report.  The failures are fairly benign, the only real
> > issue being that the GNU Fortran compiler version on your system doesn't
> > like being handed convenience archives but no plain objects on the
> > command line:
> > 
> > * Paul Laight wrote on Mon, Aug 23, 2010 at 01:27:07PM CEST:
> > > ./convenience.at:151: $LIBTOOL --tag=F77 --mode=link $F77 $FFLAGS 
> > > $LDFLAGS -o liba12.la liba1.la liba2.la -rpath /notexist
> > > stderr:
> > > i686-apple-darwin8-gfortran-4.2: no input files; unwilling to write 
> > > output files
> > > stdout:
> > > libtool: link: gfortran -dynamiclib -Wl,-undefined -Wl,dynamic_lookup -o 
> > > .libs/liba12.0.dylib   -Wl,-force_load,./.libs/liba1.a 
> > > -Wl,-force_load,./.libs/liba2.a -install_name  
> > > /notexist/liba12.0.dylib -compatibility_version 1 -current_version 1.0 
> > > -Wl,-single_module
> > > ./convenience.at:151: exit code was 1, expected 0
> > > 28. convenience.at:109: 28. F77 convenience archives 
> > > (convenience.at:109): FAILED (convenience.at:151)

Looking at this again, it isn't the gfortran version that differs here
from other reports where test doesn't fail, but rather the system: it
fails on darwin because $whole_archive_flag_spec doesn't pass any
archive names without -Wl,... prefix, which in turn makes gfortran think
there is a problem.  The actual issue seems to be present even in
current GCC.

The following patch should fix this.  Paul, any chance you could try out
the patch on your system?  OK to add your name&email to THANKS?

OK to commit?  (I do have access to a darwin system, but no gfortran
installed there, so I cannot test this.)

Thanks,
Ralf

Fix linking from only convenience archives with gfortran on Darwin.

* libltdl/m4/libtool.m4 (_LT_DARWIN_LINKER_FEATURES): Update
macro comment header.
[darwin, F77, FC] : Set to yes if
whole_archive_flag_spec is nonempty.  Fixes convenience.at test
suite failures with gfortran 4.2 on Darwin.
* THANKS: Update.
Report by Paul Laight.

diff --git a/libltdl/m4/libtool.m4 b/libltdl/m4/libtool.m4
index 5c4e29c..de417b6 100644
--- a/libltdl/m4/libtool.m4
+++ b/libltdl/m4/libtool.m4
@@ -1035,8 +1035,8 @@ _LT_EOF
 ])
 
 
-# _LT_DARWIN_LINKER_FEATURES
-# --
+# _LT_DARWIN_LINKER_FEATURES([TAG])
+# -
 # Checks for linker and compiler features on darwin
 m4_defun([_LT_DARWIN_LINKER_FEATURES],
 [
@@ -1047,6 +1047,8 @@ m4_defun([_LT_DARWIN_LINKER_FEATURES],
   _LT_TAGVAR(hardcode_shlibpath_var, $1)=unsupported
   if test "$lt_cv_ld_force_load" = "yes"; then
 _LT_TAGVAR(whole_archive_flag_spec, $1)='`for conv in $convenience\"\"; do 
test  -n \"$conv\" && new_convenience=\"$new_convenience 
${wl}-force_load,$conv\"; done; func_echo_all \"$new_convenience\"`'
+m4_case([$1], [F77], [_LT_TAGVAR(compiler_needs_object, $1)=yes],
+  [FC],  [_LT_TAGVAR(compiler_needs_object, $1)=yes])
   else
 _LT_TAGVAR(whole_archive_flag_spec, $1)=''
   fi

Re: PATCH RFA: Add Go support

[Ralf Wildenhues]

* 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

[Ralf Wildenhues]

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]

* Ralf Wildenhues wrote on Sat, Oct 09, 2010 at 12:27:35PM CEST:
> 2010-10-09  Simon Josefsson  
>   Matěj Týč 
>   Ralf Wildenhues  
> 
>   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: somewhat misleading -no-undefined documentation

[Ralf Wildenhues]

[ adding libtool-patches ]

Hi Matěj,

* Matěj Týč wrote on Sun, Oct 03, 2010 at 12:12:00AM CEST:
> I have thought so far that if you want to make a DLL, you can't get
> involved with any other library, because libtool needs -no-undefined
> flag in order to make DLLs and you are supposed to use it only if the
> library is self-contained.
> I was quite surprised when I have cheated libtool, supplied the
> -no-undefined parameter and it worked although I thought that it
> shouldn't and after some investigation, I have stumbled across an old
> mailing list thread, where another person had the same issue:
> http://lists.gnu.org/archive/html/libtool/2006-03/msg00012.html
> Having looked at the documentation thoroughly, I had to admit that the
> documentation is correct, but if you try to read through it quickly, it
> is likely that you leave with the impression expressed in the beginning
> of this e-mail.
> Therefore I suggest that you stress this in the documentation, feel free
> to use this patch (there is also a patch if you look at the old
> message).

Thanks for the report and patch.

> --- a/doc/libtool.texi
> +++ b/doc/libtool.texi
> @@ -1517,7 +1517,8 @@ of library paths.  Useful if the program is only
> used in the build tree,
>  e.g., for testing or generating other files.
>  
>  @item -no-undefined
> -Declare that @var{output-file} does not depend on any other libraries.
> +Declare that @var{output-file} does not depend on any other libraries
> +in the sense that after linking it will not have any unresolved
> symbols.
>  Some platforms cannot create shared libraries that depend on other
>  libraries (@pxref{Inter-library dependencies}).

This isn't quite right yet, because it may be misinterpreted in a way
that symbols may not even be resolved to dependent libraries.  I don't
think we support such systems any more, if there still are any more of
them out there.

> @@ -3263,7 +3264,8 @@ library systems and simple dynamic library
> systems.
>  
>  Some platforms, such as AIX, do not even allow you this
>  flexibility.  In order to build a shared library, it must be entirely
> -self-contained (that is, have references only to symbols that are found
> +self-contained or it must have dependencies known at the link time
> +(that is, have references only to symbols that are found
>  in the @file{.lo} files or the specified @samp{-l} libraries), and you
>  need to specify the @option{-no-undefined} flag.  By default, libtool
>  builds only static libraries on these kinds of platforms.

Good point.

I kinda like Simon's patch you referenced (wow, that's old!), so how
about this patch which takes from both your suggestions?
(I'm attributing this to Simon because he got it started, for lack of a
better way to specify multiple authors in a git commit.)

Thanks,
Ralf

2010-10-09  Simon Josefsson  
Matěj Týč 
Ralf Wildenhues  

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.

diff --git a/doc/libtool.texi b/doc/libtool.texi
index cd5a181..076b67b 100644
--- a/doc/libtool.texi
+++ b/doc/libtool.texi
@@ -1517,9 +1517,12 @@ of library paths.  Useful if the program is only used in 
the build tree,
 e.g., for testing or generating other files.
 
 @item -no-undefined
-Declare that @var{output-file} does not depend on any other libraries.
-Some platforms cannot create shared libraries that depend on other
-libraries (@pxref{Inter-library dependencies}).
+Declare that @var{output-file} does not depend on any libraries other
+than the ones listed on the command line, i.e., after linking, it will
+not have unresolved symbols.  Some platforms require all symbols in
+shared libraries to be resolved at library creation (@pxref{Inter-library
+dependencies}), and using this parameter allows @command{libtool} to
+assume that this will not happen.
 
 @item -o @var{output-file}
 Create @var{output-file} from the specified objects and libraries.
@@ -3261,12 +3264,13 @@ in order to guarantee that all the required libraries 
are found.  This
 restriction is only necessary to preserve compatibility with static
 library systems and simple dynamic library systems.
 
-Some platforms, such as AIX, do not even allow you this
+Some platforms, such as Windows, do not even allow you this
 flexibility.  In order to build a shared library, it must be entirely
-self-contained (that is, have references only to symbols that are found
-in the @file{.lo} files or the specified @samp{-l} libraries), and you
-need to specify the @option{-no-undefined} flag.  By default, libtool
-builds only static libraries on these kinds of platforms.
+self-co

Re: [RFC PATCH] Strip trailing slashes from libdir and destdir

[Ralf Wildenhues]

* Paolo Bonzini wrote on Sat, Oct 09, 2010 at 10:51:34AM CEST:
> I found this patch at OpenEmbedded,
> http://lists.linuxtogo.org/pipermail/openembedded-devel/2010-October/025133.html
> 
> It looks to me like the code can be simplified by unconditionally
> stripping trailing slashes from $libdir and $destdir (i.e. not
> introducing the new variables).  Ideas?

Probably ok, but I'd really like coverage for the bug this fixes.
I know there is a bug, it's been reported more than once, but I
don't recall that I had an exposer.

The Automake 1.11+ code exposed this IIRC, because it started installing
more than one library at once, and with a directory as destination
argument (rather than directory/libfile.la).

Thanks,
Ralf

> * libltdl/config/ltmain.m4sh (func_mode_install): Check if
> $destdir ends with $libdir only after stripping trailing slashes
> from both.  Patch from Gary Thomas  and
> Nitin A Kamble .

For people added to THANKS you can omit email addresses in the
ChangeLog.

> --- a/libltdl/config/ltmain.m4sh
> +++ b/libltdl/config/ltmain.m4sh
> @@ -2164,8 +2164,15 @@ func_mode_install ()
>   func_append dir "$objdir"
>  
>   if test -n "$relink_command"; then
> +  # Strip any trailing slash from the destination.
> +  func_stripname '' '/' "$libdir"
> +  destlibdir=$func_stripname_result
> +
> +  func_stripname '' '/' "$destdir"
> +  s_destdir=$func_stripname_result

The indentation is wrong.

> # Determine the prefix the user has applied to our future dir.
> -   inst_prefix_dir=`$ECHO "$destdir" | $SED -e "s%$libdir\$%%"`
> +   inst_prefix_dir=`$ECHO "X$s_destdir" | $Xsed -e "s%$destlibdir\$%%"`
>  
> # Don't allow the user to place us outside of our expected
> # location b/c this prevents finding dependent libraries that
> @@ -2173,7 +2180,7 @@ func_mode_install ()
> # At present, this check doesn't affect windows .dll's that
> # are installed into $libdir/../bin (currently, that works fine)
> # but it's something to keep an eye on.
> -   test "$inst_prefix_dir" = "$destdir" && \
> +   test "$inst_prefix_dir" = "$s_destdir" && \
>   func_fatal_error "error: cannot install \`$file' to a directory not 
> ending in $libdir"
>  
> if test -n "$inst_prefix_dir"; then

Re: [PATCH] Add missing sysroot resolution

[Ralf Wildenhues]

* 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: [PATCH] Add missing sysroot resolution

[Ralf Wildenhues]

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 ,
> patch by Khem Raj .
> * THANKS: Reorder entries, add Khem and Lionel.

Re: [PATCH] msvc: handle symbols from different files independently.

[Ralf Wildenhues]

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)
> : 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.

[Ralf Wildenhues]

* 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] Add test case for 69e77671 (cwrapper PATH manipulation order)

[Ralf Wildenhues]

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.

[Ralf Wildenhues]

* 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: cwrapper generates long strings.

[Ralf Wildenhues]

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: cwrapper generates long strings.

[Ralf Wildenhues]

[ dropped bug-libtool ]

* Peter Rosin wrote on Sat, Oct 02, 2010 at 01:42:02PM CEST:
> Den 2010-10-02 08:32 skrev Ralf Wildenhues:
> >> +$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.
> 
> Ok, so replacing with
> 
> s/^\(.\{79\}\)\(..*\)/\1\
> \2/
> 
> is portable?

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.

> >> +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'
> 
> Because then we no longer know if the C-string "\n" at the end of the
> line (added by the 's/$/\\n/' statement) should be inserted or not.
> The trick is to add it and then cut it out if the string was too long
> (contains a literal newline from the s command).  We can only have
> the "\n" for the final chunk, otherwise the output will be riddled
> with too many newlines.

Ah yes, thinko of mine, thanks for explaining.

Cheers,
Ralf

Re: cwrapper generates long strings.

[Ralf Wildenhues]

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.

[Ralf Wildenhues]

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)
> : 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: [PATCH] tests: don't use assert/abort on MSVC as they are interactive.

[Ralf Wildenhues]

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.

[Ralf Wildenhues]

* 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] msvc: handle symbols from different files independently.

[Ralf Wildenhues]

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)
> : 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] tests: don't use assert/abort on MSVC as they are interactive.

[Ralf Wildenhues]

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.

Re: [PATCH] tests: don't use assert/abort on MSVC as they are interactive.

[Ralf Wildenhues]

Hello Peter,

* Peter Rosin wrote on Tue, Sep 28, 2010 at 08:08:13PM CEST:
> Ok to push?

Avoiding assert doesn't seem like a scalable solution: lots of packages
use assert for testing.  assert is ANSI C.  We use assert in slist.at.
Is there a way to avoid popups?

Hmm, or, if there is no way, then I guess you're saying popups are ok if
it only happens for unexpected failures.  Then I don't have a good
argument against the patch any more.

Thanks,
Ralf

> From f17e568aea90ea2def14d0d0825da927b4a2421d Mon Sep 17 00:00:00 2001
> From: Peter Rosin 
> Date: Tue, 28 Sep 2010 20:02:22 +0200
> Subject: [PATCH] tests: don't use assert/abort on MSVC as they are 
> interactive.
> 
> * tests/lalib-syntax.at (main.c): Rewrite to not use assert as
> assert in turn calls abort which pops up a dialog on MSVC.

Re: [PATCH] tests: check if sys_lib_search_path_spec works on MSVC.

[Ralf Wildenhues]

Hi Peter,

* Peter Rosin wrote on Mon, Sep 27, 2010 at 04:37:17PM CEST:
> Ok to push? Passes with MSVC, MinGW/gcc and Cygwin/gcc. If I trivially
> break the compile step, it skips as designed.

Interesting.  If it were late in the release cycle, I'd be a bit wary
of this patch without a fair amount of system testing, but since we're
fairly early I think we should try it, with nits below addressed.

Please do merge the test into the tests/search-path.at file though
(if it helps you you can remove my author tag from it, or add yourself)
and name it "sys_lib_search_path on w32" or so.

A couple of questions below.

Thanks,
Ralf

> Subject: [PATCH] tests: check if sys_lib_search_path_spec works on MSVC.
> 
> * tests/sys-lib.at: New test, catching regressions in
> v2.2.10-207-g09142ea.
> * Makefile.am (TESTSUITE_AT): Update.


> +AT_SETUP([sys_lib])
> +AT_KEYWORDS([libtool])
> +LDFLAGS="$LDFLAGS -no-undefined"
> +
> +AT_DATA([gc.c],
> +[[#include 
> +HCURSOR get_cursor (void)
> +{
> +  return GetCursor ();
> +}
> +]])
> +
> +eval "`$LIBTOOL --config | grep '^build_libtool_libs='`"
> +AT_CHECK([test "$build_libtool_libs" = yes || (exit 77)])

No need for the subshell for exit 77.

> +AT_CHECK([$LIBTOOL --mode=compile --tag=CC --tag=disable-static \
> +   $CC $CPPFLAGS $CFLAGS -o gc.lo -c gc.c || exit 77],
> +  [], [ignore], [ignore])

Why the --tag=disable-static here?

> +# Ok, compile was fine, then it should be possible to link too.
> +
> +AT_CHECK([$LIBTOOL --mode=link --tag=CC --tag=disable-static \
> +   $CC $CFLAGS $LDFLAGS -o libgc.la gc.lo -rpath /nowhere -luser32],
> +  [], [ignore], [ignore])
> +
> +# If -luser32 was found, then libtool will build a shared library,
> +# otherwise libtool will fall back to creating a static library.

Will creating a static library work if you used --tag=disable-static
above?

> +AT_CHECK([grep old_library=\'\' libgc.la], [], [ignore])
> +
> +AT_CLEANUP

Re: [PATCH] tests: import variables for MSVC.

[Ralf Wildenhues]

* 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] tests: import variables for MSVC.

[Ralf Wildenhues]

> 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] Skip need_lib_prefix.at on systems without lib prefix on libraries.

[Ralf Wildenhues]

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

pre-release update of LTDL_VERSION_INFO (was: [SCM] GNU Libtool branch, master, updated. v2.4-1-gf0ba93d)

[Ralf Wildenhues]

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