Re: libtool.texi: copyright notice patch

2011-09-04 Thread 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: Bug 9210: fix to replace Linux with GNU/Linux where needed

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

2011-06-27 Thread 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: libtool mingw cross compile problems

2011-05-18 Thread Ralf Wildenhues
* Ralf Wildenhues wrote on Wed, May 18, 2011 at 09:13:32PM CEST:
 * Erik de Castro Lopo wrote on Tue, May 17, 2011 at 12:21:35PM CEST:
  The problem is the generation of a test program in a sub-directory.
  The test program that should be generated is:
  
  G72x/g72x_test.$(EXEEXT)
  
  which executes a a wrapper script in G72x/.libs/ . Unfortunately
  for Linux - windows cross compiles, the G72x/g72x_test.$(EXEEXT)
  executable isn't being generated. There is however a bash script
  G72x/.libs/g72x_test_ltshwrapper.
 
 Please provide more details.  For example a small Makefile.am snippet
 that reproduces the problem for you.

Aw darn, now that I sent this mail I see you already sent this to the
automake list.  Please don't send to two lists without at least hinting
that you've already sent things elsewhere, or better a URL or Xpost with
Followup.

In this case I would like to see the output of
  make clean  make; make g72x_test

Thanks,
Ralf

___
https://lists.gnu.org/mailman/listinfo/libtool


Re: [PATCH 01/10] Add -shortname option.

2011-04-15 Thread 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: QNX6 patch

2011-04-12 Thread Ralf Wildenhues
Hello Sean,

* Sean Boudreau wrote on Mon, Apr 11, 2011 at 05:32:25PM CEST:
 Here's a patch for qnx that I've been using for a while.
 I'd like to try to get it integrated.

Thank you for the patch.  Unfortunately, we cannot take it as it is,
because there are several bits of information missing, and some things
look problematic.

First off, the patch needs a GNU-style ChangeLog entry (see the
ChangeLog file for existing entries).  We can write it if you have
problems with it, but you should at least try.  Did you write the
patch?  Were others also involved?

Then, we'd like to see how both the old and the new Libtool testsuites
fare with this patch on QNX6 (and maybe older releases if relevant?),
and whether the patch fixes any test failures that were present
previously (and it would be good to see verbose test logs for those as
well).

More comments inline.

 --- libtool-2.4~/libltdl/m4/libtool.m42010-09-22 04:41:19.0 
 -0400
 +++ libtool-2.4/libltdl/m4/libtool.m4 2011-04-11 11:13:24.0 -0400
 @@ -2651,9 +2651,10 @@
;;
  
  *nto* | *qnx*)
 -  version_type=qnx
 +  version_type=linux

Whoa, this is a very heavy change.  This has the chance to break
virtually all existing QNX setups, turn installed libraries that have
been built without this change incompatible to libraries that use the
change.

Such a change needs a very good rationale, usually including a pointer
to system documentation for why the old version semantics are not
adequate (any more?), for why maybe a newer system release changed
semantics, or some other reason.  If we do this change for a new system
version, that can be acceptable, but then older versions should not be
affected.

That said, I have no idea how large the user base for Libtool and
Libtool-using packages on QNX is.  You might be the only person building
packages there, I cannot tell.  Please share such information, as much
as you have it.

Jasons remark about this being different from the QNX style makes me
doubt the validity of this change even more.  libtool should be
emulating the native shared library semantics as much as possible in
order to fit in.

need_lib_prefix=no
need_version=no
 +  sys_lib_search_path_spec=/lib /usr/lib

This looks benign.

library_names_spec='${libname}${release}${shared_ext}$versuffix 
 ${libname}${release}${shared_ext}$major $libname${shared_ext}'
soname_spec='${libname}${release}${shared_ext}$major'
shlibpath_var=LD_LIBRARY_PATH
 @@ -3245,7 +3246,7 @@
;;
  
  *nto* | *qnx*)
 -  lt_cv_deplibs_check_method=pass_all
 +  'match_pattern /lib[[^/]]+(\.so|S\.a)$'

This looks like a typo.  The resulting shell code is erroneous
(tries to execute a program named match_pattern /
You meant to assign the contents of the added line to the variable
named in the removed line.

;;
  
  openbsd*)
 @@ -5289,6 +5290,8 @@
;;
  
  *nto* | *qnx*)
 +  _LT_TAGVAR(archive_cmds, $1)='$CC -shared $libobjs $deplibs 
 $compiler_flags ${wl}-soname $wl$soname -o $lib'
 +  _LT_TAGVAR(archive_expsym_cmds, $1)='$CC -shared $libobjs $deplibs 
 $compiler_flags ${wl}-soname $wl$soname ${wl}-retain-symbols-file 
 $wl$export_symbols -o $lib'

Please check whether adding $pic_flag to both added commands lets them
still work.

;;
  
  openbsd*)
 @@ -6495,7 +6498,12 @@
   ;;
  
*nto* | *qnx*)
 -_LT_TAGVAR(ld_shlibs, $1)=yes
 +_LT_TAGVAR(archive_cmds, $1)='$CC -shared $libobjs $deplibs 
 $compiler_flags ${wl}-soname $wl$soname -o $lib'
 +_LT_TAGVAR(archive_expsym_cmds, $1)='$CC -shared $libobjs $deplibs 
 $compiler_flags ${wl}-soname $wl$soname ${wl}-retain-symbols-file 
 $wl$export_symbols -o $lib'

Likewise.

 +_LT_TAGVAR(hardcode_libdir_flag_spec, $1)='-R$libdir'
 +_LT_TAGVAR(hardcode_direct, $1)=yes
 +_LT_TAGVAR(hardcode_shlibpath_var, $1)=no
 +output_verbose_link_cmd='echo'

These additions look OK to me.

   ;;
  
openbsd2*)

Thanks again,
Ralf

___
http://lists.gnu.org/mailman/listinfo/libtool


[SCM] GNU Libtool branch, master, updated. v2.4-52-g1ea9302

2011-04-10 Thread Ralf Wildenhues
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project GNU Libtool.

The branch, master has been updated
   via  1ea9302bd1eadf25b466fcd7e8697e4bef111493 (commit)
  from  1b76054f4763a28ae1b01fbeee86ba0c524d1923 (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -
commit 1ea9302bd1eadf25b466fcd7e8697e4bef111493
Author: Svante Signell s...@kth.se
Date:   Sun Apr 10 10:17:21 2011 +0200

Set shlibpath_overrides_runpath for the Hurd.

* libltdl/m4/libtool.m4 (_LT_SYS_DYNAMIC_LINKER) [gnu]
shlibpath_overrides_runpath: Set to no.
* THANKS: Update.

Signed-off-by: Ralf Wildenhues ralf.wildenh...@gmx.de

---

Summary of changes:
 ChangeLog |7 +++
 THANKS|4 +++-
 libltdl/m4/libtool.m4 |1 +
 3 files changed, 11 insertions(+), 1 deletions(-)

diff --git a/ChangeLog b/ChangeLog
index bc7c2af..ff936ae 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,10 @@
+2011-04-10  Svante Signell  s...@kth.se  (tiny change)
+
+   Set shlibpath_overrides_runpath for the Hurd.
+   * libltdl/m4/libtool.m4 (_LT_SYS_DYNAMIC_LINKER) [gnu]
+   shlibpath_overrides_runpath: Set to no.
+   * THANKS: Update.
+
 2011-03-22  Justin Lecher  j...@gentoo.org  (tiny change)
Rhys Ulerich  rhys.uler...@gmail.com  (tiny change)
 
diff --git a/THANKS b/THANKS
index 08d7077..da43e65 100644
--- a/THANKS
+++ b/THANKS
@@ -180,6 +180,7 @@
   Stephan Kulowco...@kde.org
   Steve Ellcey s...@cup.hp.com
   Steven M. Schultzs...@wlv.iipo.gtegsc.com
+  Svante Signell   s...@kth.se
   Sven Verdoolaege sk...@liacs.nl
   Terry D. Dontje  terry.don...@sun.com
   Tim Mooney   moo...@dogbert.cc.ndsu.nodak.edu
@@ -202,7 +203,8 @@
 
 -- 
   Copyright (C) 1996, 1998, 1999, 2001, 2002, 2003, 2004, 2005, 2006,
-2007, 2008 Free Software Foundation, Inc.
+2007, 2008, 2009, 2010, 2011 Free Software Foundation,
+Inc.
   Written by Gord Matzigkeit, 1996
 
   This file is part of GNU Libtool.
diff --git a/libltdl/m4/libtool.m4 b/libltdl/m4/libtool.m4
index 5cc027b..2ed41b7 100644
--- a/libltdl/m4/libtool.m4
+++ b/libltdl/m4/libtool.m4
@@ -2519,6 +2519,7 @@ gnu*)
   library_names_spec='${libname}${release}${shared_ext}$versuffix 
${libname}${release}${shared_ext}${major} ${libname}${shared_ext}'
   soname_spec='${libname}${release}${shared_ext}$major'
   shlibpath_var=LD_LIBRARY_PATH
+  shlibpath_overrides_runpath=no
   hardcode_into_libs=yes
   ;;
 


hooks/post-receive
-- 
GNU Libtool



[SCM] GNU Libtool branch, master, updated. v2.4-53-gd5d35c4

2011-04-10 Thread Ralf Wildenhues
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project GNU Libtool.

The branch, master has been updated
   via  d5d35c47e16b18158bf4984cc4371366d373bb2f (commit)
  from  1ea9302bd1eadf25b466fcd7e8697e4bef111493 (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -
commit d5d35c47e16b18158bf4984cc4371366d373bb2f
Author: Kurt Roeckx k...@roeckx.be
Date:   Sun Apr 10 10:22:43 2011 +0200

tagdemo: do not rely on picking up symbols from indirect deps.

* tests/tagdemo/Makefile.am: Link to all libraries that the
demo application uses.

Signed-off-by: Ralf Wildenhues ralf.wildenh...@gmx.de

---

Summary of changes:
 ChangeLog |6 ++
 tests/tagdemo/Makefile.am |4 ++--
 2 files changed, 8 insertions(+), 2 deletions(-)

diff --git a/ChangeLog b/ChangeLog
index ff936ae..dcfab26 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,9 @@
+2011-04-10  Kurt Roeckx  k...@roeckx.be
+
+   tagdemo: do not rely on picking up symbols from indirect deps.
+   * tests/tagdemo/Makefile.am: Link to all libraries that the
+   demo application uses.
+
 2011-04-10  Svante Signell  s...@kth.se  (tiny change)
 
Set shlibpath_overrides_runpath for the Hurd.
diff --git a/tests/tagdemo/Makefile.am b/tests/tagdemo/Makefile.am
index e945c25..295e7b6 100644
--- a/tests/tagdemo/Makefile.am
+++ b/tests/tagdemo/Makefile.am
@@ -1,6 +1,6 @@
 ## Makefile.am -- Process this file with automake to produce Makefile.in
 ##
-##   Copyright (C) 2003, 2004, 2005 Free Software Foundation
+##   Copyright (C) 2003, 2004, 2005, 2011 Free Software Foundation
 ##   Written by Gary V. Vaughan, 2003
 ##
 ##   This file is part of GNU Libtool.
@@ -47,7 +47,7 @@ noinst_HEADERS = foo.h baz.h conv.h
 bin_PROGRAMS = tagdemo
 
 tagdemo_SOURCES = main.cpp
-tagdemo_LDADD = libbaz.la
+tagdemo_LDADD = libbaz.la libfoo.la
 
 libtool: $(LIBTOOL_DEPS)
$(SHELL) ./config.status --recheck


hooks/post-receive
-- 
GNU Libtool



Re: Updated patches: Re: bug#8441: Patches making libtool-2.4-1 build under GNU/Hurd

2011-04-10 Thread 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]
shlibpath_overrides_runpath: Set to no.
* THANKS: Update.

diff --git a/libltdl/m4/libtool.m4 b/libltdl/m4/libtool.m4
index 5cc027b..2ed41b7 100644
--- a/libltdl/m4/libtool.m4
+++ b/libltdl/m4/libtool.m4
@@ -2519,6 +2519,7 @@ gnu*)
   library_names_spec='${libname}${release}${shared_ext}$versuffix 
${libname}${release}${shared_ext}${major} ${libname}${shared_ext}'
   soname_spec='${libname}${release}${shared_ext}$major'
   shlibpath_var=LD_LIBRARY_PATH
+  shlibpath_overrides_runpath=no
   hardcode_into_libs=yes
   ;;
 



Re: [PATCH] tagdemo: Link to libfoo

2011-04-10 Thread 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: debbugs, and a FAQ, for Autotools

2011-04-05 Thread Ralf Wildenhues
* Glenn Morris wrote on Tue, Apr 05, 2011 at 11:46:21PM CEST:
 Ralf Wildenhues wrote (on Tue, 5 Apr 2011 at 23:30 +0200):
 
  Thank you!  Could you also list libtool on http://debbugs.gnu.org/?
 
 Umm, I did. Maybe you have a stale cache?

I guess.  It works now.

Thank you Glenn for taking care of this!
Ralf

___
http://lists.gnu.org/mailman/listinfo/libtool


Re: Example in libtool manual gives wrong dependencies w/ automake.

2011-04-02 Thread Ralf Wildenhues
Hello Nick,

* Nick Bowler wrote on Fri, Apr 01, 2011 at 04:04:21PM CEST:
 I'm working on a project which uses libltdl to load modules, and I've
 set it up in a manner pretty similar to what's described in the libtool
 manual (10.3 Linking with dlopened modules, http://xrl.us/bjk9e5).
 In that section, the manual recommends to use a weak library interface.
 
 However, the example given in the manual does not work because
 the generated makefile lacks dependencies from libloader.la to
 libinterface.la's objects.

Indeed.  The reference to the internal *_OBJECTS variable is surprising.
It would be cleaner to have a libfoo_conv.la convenience
(noinst_LTLIBRARIES) archive that had the same sources as libfoo.la and
add that to libbar_la_LIBADD.

A patch to fix libtool.texi to this end would be appreciated.

  Here's a simplified and complete
 version of the example in the libtool manual:
 
   % cat Makefile.am 'EOF'
   lib_LTLIBRARIES = libbar.la libfoo.la
 
   libfoo_la_SOURCES = foo.c
 
   libbar_la_SOURCES = bar.c
   libbar_la_LDFLAGS = -weak libfoo.la
   libbar_la_LIBADD  = $(libfoo_la_OBJECTS)
   EOF

   % ./configure -q  make
 CC bar.lo
 CCLD   libbar.la
   libtool: link: `foo.lo' is not a valid libtool object
   make: *** [libbar.la] Error 1
 
 Looking at the generated Makefile.in, we see this is because libbar.la
 doesn't have any dependency on foo.lo.  We can add it to the
 Makefile.am:
 
   libbar_la = libbar.la
   $(libbar_la): $(libfoo_la_OBJECTS)
 
 and now it will build.  So, should automake support the example in the
 libtool manual, or does the libtool manual need to be fixed?  If the
 latter, is the above workaround a good one?

I see several workarounds.  The one I described above is clean.
Another would be to compute libbar_la_DEPENDENCIES manually, e.g.:
  libbar_la_DEPENDENCIES = $(libfoo_la_OBJECTS)

In a real-life situation, there are other dependencies, so you'd prefer
to use
  EXTRA_libbar_la_DEPENDENCIES = $(libfoo_la_OBJECTS)

so automake will still compute libbar_la_DEPENDENCIES
(available only in git Automake, will be in 1.12; sorry).

One thing that I wonder about is why you actually need the foo code to
be both in libfoo and libbar.  If possible, then code should only ever
exist in one shared library.  (I may be missing details from the
dlpreopen machinery here now, it's been a while ... feedback as to what
worked for you appreciated.)


As to whether automake should be able to look through $(*_OBJECTS)
references in _LIBADD and add them to _DEPENDENCIES: yes that too
seems like a viable idea.  'info Automake Program and Library
Variables' is currently vague about this case (but it can be, since
_OBJECTS are supposed to be internal details).

So there really are two issues here, one in libtool.texi and one in
Automake.  Thanks for reporting them.

Cheers,
Ralf

___
http://lists.gnu.org/mailman/listinfo/libtool


Re: debbugs, and a FAQ, for Autotools

2011-04-01 Thread Ralf Wildenhues
Let's pick this up again, but for Libtool only for now.

[ http://lists.gnu.org/archive/html/automake/2011-02/msg00025.html ]

* Ralf Wildenhues wrote on Sun, Feb 13, 2011 at 07:12:02PM CET:
 [ Cross post; Reply-To and Mail-Followup-To set.  Please followup to
   the automake list only, to avoid excessive spammage.  Thank you.  ]

 I've been advertising debbugs before, I think we should be a good
 example.  So, two proposals:
 
 1) Autoconf and Libtool should also use debbugs.
 
 bug-automake has switched a few months ago, and I find it helpful to
 avoid losing reports.  Given that we never have enough time on our
 hands, it becomes more important to not lose track.

Do any Libtool developers or regulars have any issue with this?
We do keep forgetting about bug reports, and we do have contributors
that only work every once in a while, and for both it would seem to
be useful to have a list of open issues.

Eric had concerns that it would be difficult to tell which package a bug
was against.  The Sender: header shows this, however, so I don't see it
as a big problem (unless your MUA cannot be configured to show this
particular header).  Or we could modify debbugs to provide some more
hints.

If there is no disagreement by, let's say Monday, Glenn could you then
set up debbugs for the bug-libtool list?

Thanks,
Ralf

___
http://lists.gnu.org/mailman/listinfo/libtool


Re: libtool relinks all shared libraries when make install is performed

2011-03-29 Thread Ralf Wildenhues
Hello Markus,

* Markus Franke wrote on Wed, Mar 23, 2011 at 05:18:53PM CET:
 we have a large C++ project containing of several modules which each get 
 compiled into seperate shared libraries. Our directory structure looks 
 somehow as follows:
[...]

 When performing the make install step all the libraries and binaries get 
 installed to our prefix directory /opt/kmt. This currently takes very 
 long (~20 minutes) as libtool relinks all libraries.
[...]

Wow.  That's terrible.

 How can I avoid this additional relinking step during make install?

Generally, --enable-fast-install should be the switch to avoid it.
However, it is not possible to do on every system, and not fully
optimized on all systems where it could be made to work.  Unfortunately,
GNU/Linux is one of the latter ones where Libtool still needs a bit of
work.

Thanks for the bug report,
Ralf

___
http://lists.gnu.org/mailman/listinfo/libtool


Re: About libtool supporting parallel make install

2011-03-18 Thread Ralf Wildenhues
* Dan Nicholson wrote on Thu, Mar 17, 2011 at 11:47:38PM CET:
 On Thu, Mar 17, 2011 at 3:08 AM, Pacho Ramos pa...@gentoo.org wrote:
 
  https://bugzilla.gnome.org/show_bug.cgi?id=644896#c2
 
 This seems more legitimate. I looked at the Makefile.am's and they
 look reasonable to me. You have two libraries, one is in
 lib_LTLIBRARIES and the other is in pkglib_LTLIBRARIES. The pkglib one
 depends on the lib one.
 
 It seems that make is running install-libLTLIBRARIES and
 install-pkglibLTLIBRARIES in parallel. Each one of these these rules
 installs the libraries serially in a loop. However, if libtool is
 relinking the libraries, it really needs to wait until the
 prerequisite libraries from _other_ rules are installed. I'd bet if
 you do this:
 
 echo install-pkglibLTLIBRARIES: install-libLTLIBRARIES 
 src/backend/xml/Makefile
 
 it will work again. This seems like a bug in automake's libtool
 support to me, but I don't know how to fix it.

Yes, it's a bug in Automake/Libtool, but the workaround isn't quite
correct: you'd need something like

install-pkglibLTLIBRARIES = install-pkglibLTLIBRARIES
$(install-pkglibLTLIBRARIES): install-libLTLIBRARIES

because your proposed workaround will cause automake to not emit its
install-pkglibLTLIBRARIES rule at all.  Yes, depending on automake not
seeing through variables when determining target names is ugly, I know.
(It's also so widespread by now that we can't easily change that issue.)

I've posted some ideas to fix the original bug before, on an automake or
libtool list; but nothing finished.  :-/

Cheers,
Ralf

___
http://lists.gnu.org/mailman/listinfo/libtool


Re: About libtool supporting parallel make install

2011-03-18 Thread Ralf Wildenhues
Hello Pacho,

* Pacho Ramos wrote on Fri, Mar 18, 2011 at 11:48:51AM CET:
 We have some downstream opened bugs with similar cases, would you mind
 asking for help with them here in the future once their respective
 upstream refuse to fix the issues?

Feel free to come to this mailing list for help about Libtool issues.

Cheers,
Ralf

___
http://lists.gnu.org/mailman/listinfo/libtool


Re: About libtool supporting parallel make install

2011-03-18 Thread Ralf Wildenhues
Pacho,

hope you're reading the list.  Mail from me to you bounces because some
MTA near your end is over-eagerly using SPF to reject legitimate mail.

Rakf

* Ralf Wildenhues wrote on Fri, Mar 18, 2011 at 08:43:21PM CET:
 Hello Pacho,
 
 * Pacho Ramos wrote on Fri, Mar 18, 2011 at 11:48:51AM CET:
  We have some downstream opened bugs with similar cases, would you mind
  asking for help with them here in the future once their respective
  upstream refuse to fix the issues?
 
 Feel free to come to this mailing list for help about Libtool issues.
 
 Cheers,
 Ralf

___
http://lists.gnu.org/mailman/listinfo/libtool


[SCM] GNU Libtool branch, master, updated. v2.4-50-g39f84c6

2011-03-14 Thread Ralf Wildenhues
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project GNU Libtool.

The branch, master has been updated
   via  39f84c6eba7557d73e6dacae3afb40a164c62ba1 (commit)
  from  6a6de36e4c652fd0eba739c209a3b43ae7a41a5b (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -
commit 39f84c6eba7557d73e6dacae3afb40a164c62ba1
Author: Ralf Wildenhues ralf.wildenh...@gmx.de
Date:   Mon Mar 14 07:30:53 2011 +0100

libtoolize: detect -Idir (without space) in ACLOCAL_AMFLAGS.

* libtoolize.m4sh (func_scan_files): Also accept -Idir
(without intervening space) in ACLOCAL_AMFLAGS.
* THANKS: Update.
Report from Jan Engelhardt.

Signed-off-by: Ralf Wildenhues ralf.wildenh...@gmx.de

---

Summary of changes:
 ChangeLog   |8 
 THANKS  |1 +
 libtoolize.m4sh |   17 ++---
 3 files changed, 19 insertions(+), 7 deletions(-)

diff --git a/ChangeLog b/ChangeLog
index 528e404..4ed09a3 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,11 @@
+2011-03-14  Ralf Wildenhues  ralf.wildenh...@gmx.de
+
+   libtoolize: detect -Idir (without space) in ACLOCAL_AMFLAGS.
+   * libtoolize.m4sh (func_scan_files): Also accept -Idir
+   (without intervening space) in ACLOCAL_AMFLAGS.
+   * THANKS: Update.
+   Report from Jan Engelhardt.
+
 2011-03-04  Peter O'Gorman  pe...@pogma.com
 
On Mac OS X try .dylib as well as .so with lt_dlopenext
diff --git a/THANKS b/THANKS
index 0b03320..08d7077 100644
--- a/THANKS
+++ b/THANKS
@@ -109,6 +109,7 @@
   Jakub Bogusz qbo...@pld-linux.org
   Jacob Meuser jake...@jakemsr.com
   James Su james...@gmail.com
+  Jan Engelhardt   jeng...@medozas.de
   Jay Krelljay.kr...@cornell.edu
   Jeff Squyres jsquy...@lam-mpi.org
   Jeremy C. Reed   r...@reedmedia.net
diff --git a/libtoolize.m4sh b/libtoolize.m4sh
index 844698c..cd15c58 100644
--- a/libtoolize.m4sh
+++ b/libtoolize.m4sh
@@ -556,8 +556,8 @@ func_scan_files ()
 # Hunt for ACLOCAL_AMFLAGS in `Makefile.am' for a `-I' argument.
 
 my_sed_aclocal_flags='
-/^[ ]*ACLOCAL_[A-Z_]*FLAGS[ ]*=/ {
-   s,^[^=]*=[   ]*\(.*\), \1,
+/^[ ]*ACLOCAL_[A-Z_]*FLAGS[ ]*=[]*/ {
+   s,,,
q
}
d'
@@ -568,11 +568,14 @@ func_scan_files ()
   am_macrodir=$arg
   break
 else
-  if test X$arg = X-I; then
-my_macrodir_is_next=:
-  else
-my_macrodir_is_next=false
-  fi
+ case $arg in
+   -I) my_macrodir_is_next=: ;;
+   -I*)
+ am_macrodir=`$ECHO $arg | sed 's,^-I,,'`
+ break
+ ;;
+   *) my_macrodir_is_next=false ;;
+ esac
 fi
   done
 fi


hooks/post-receive
-- 
GNU Libtool



Re: Consider adding -I $macrodir

2011-03-14 Thread 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 -Idir (without space) in ACLOCAL_AMFLAGS.

* libtoolize.m4sh (func_scan_files): Also accept -Idir
(without intervening space) in ACLOCAL_AMFLAGS.
* THANKS: Update.
Report from Jan Engelhardt.

diff --git a/libtoolize.m4sh b/libtoolize.m4sh
index 844698c..cd15c58 100644
--- a/libtoolize.m4sh
+++ b/libtoolize.m4sh
@@ -556,8 +556,8 @@ func_scan_files ()
 # Hunt for ACLOCAL_AMFLAGS in `Makefile.am' for a `-I' argument.
 
 my_sed_aclocal_flags='
-/^[ ]*ACLOCAL_[A-Z_]*FLAGS[ ]*=/ {
-   s,^[^=]*=[   ]*\(.*\), \1,
+/^[ ]*ACLOCAL_[A-Z_]*FLAGS[ ]*=[]*/ {
+   s,,,
q
}
d'
@@ -568,11 +568,14 @@ func_scan_files ()
   am_macrodir=$arg
   break
 else
-  if test X$arg = X-I; then
-my_macrodir_is_next=:
-  else
-my_macrodir_is_next=false
-  fi
+ case $arg in
+   -I) my_macrodir_is_next=: ;;
+   -I*)
+ am_macrodir=`$ECHO $arg | sed 's,^-I,,'`
+ break
+ ;;
+   *) my_macrodir_is_next=false ;;
+ esac
 fi
   done
 fi



Re: Consider adding -I $macrodir

2011-03-14 Thread 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 -Idir (without space) in ACLOCAL_AMFLAGS.

* libtoolize.m4sh (func_scan_files): Also accept -Idir
(without intervening space) in ACLOCAL_AMFLAGS.
* THANKS: Update.
Report from Jan Engelhardt.

diff --git a/libtoolize.m4sh b/libtoolize.m4sh
index 844698c..cd15c58 100644
--- a/libtoolize.m4sh
+++ b/libtoolize.m4sh
@@ -556,8 +556,8 @@ func_scan_files ()
 # Hunt for ACLOCAL_AMFLAGS in `Makefile.am' for a `-I' argument.
 
 my_sed_aclocal_flags='
-/^[ ]*ACLOCAL_[A-Z_]*FLAGS[ ]*=/ {
-   s,^[^=]*=[   ]*\(.*\), \1,
+/^[ ]*ACLOCAL_[A-Z_]*FLAGS[ ]*=[]*/ {
+   s,,,
q
}
d'
@@ -568,11 +568,14 @@ func_scan_files ()
   am_macrodir=$arg
   break
 else
-  if test X$arg = X-I; then
-my_macrodir_is_next=:
-  else
-my_macrodir_is_next=false
-  fi
+ case $arg in
+   -I) my_macrodir_is_next=: ;;
+   -I*)
+ am_macrodir=`$ECHO $arg | sed 's,^-I,,'`
+ break
+ ;;
+   *) my_macrodir_is_next=false ;;
+ esac
 fi
   done
 fi

___
http://lists.gnu.org/mailman/listinfo/libtool


Re: Mac OS X .dylib not working

2011-03-04 Thread 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:
 +# http://sources.redhat.com/autobook/autobook/autobook_169.html
 +# so if it needs changes, be sure to notify the Autobook authors
 +# about them.

 +int
 +main (int argc, const char *argv[])
 +{
 +  char *errormsg = NULL;
 +  lt_dlhandle module = NULL;
 +  entrypoint *run = NULL;
 +  int errors = 0;

Isn't this lacking
  LTDL_SET_PRELOADED_SYMBOLS();

or was that needed only for static libs (which you've excluded earlier)?

 +  if (argc != 3)
 +{
 +  fprintf (stderr, USAGE: main MODULENAME ARGUMENT\n);
 +  exit (EXIT_FAILURE);
 +}
 +
 +  /* Initialise libltdl. */
 +  errors = lt_dlinit ();
 +
 +  /* Set the module search path. */
 +  if (!errors)
 +{
 +  const char *path = getenv (MODULE_PATH_ENV);
 +
 +  if (path != NULL)
 +errors = lt_dlsetsearchpath (path);
 +}
 +
 +  /* Load the module. */
 +  if (!errors)
 +module = lt_dlopenext (argv[1]);
 +
 +  /* Find the entry point. */
 +  if (module)
 +{
 +  run = (entrypoint *) lt_dlsym (module, run);
 +
 +  /* In principle, run might legitimately be NULL, so
 + I don't use run == NULL as an error indicator
 + in general. */
 +  errormsg = dlerrordup (errormsg);
 +  if (errormsg != NULL)
 +{
 +  errors = lt_dlclose (module);
 +  module = NULL;
 +}
 +}
 +  else
 +errors = 1;
 +
 +  /* Call the entry point function. */
 +  if (!errors)
 +{
 +  int result = (*run) (argv[2]);
 +  if (result  0)
 +errormsg = strdup (module entry point execution failed);
 +  else
 +printf (\t= %d\n, result);
 +}
 +
 +  /* Unload the module, now that we are done with it. */
 +  if (!errors)
 +errors = lt_dlclose (module);
 +
 +  if (errors)
 +{
 +  /* Diagnose the encountered error. */
 +  errormsg = dlerrordup (errormsg);
 +
 +  if (!errormsg)
 +{
 +  fprintf (stderr, %s: dlerror() failed.\n, argv[0]);
 +  return EXIT_FAILURE;
 +}
 +}
 +
 +  /* Finished with ltdl now. */
 +  if (!errors)
 +if (lt_dlexit () != 0)
 +  errormsg = dlerrordup (errormsg);

I'm not particularly fond of this coding style, where ownership
information essentially gets lots once an error occurs in any
of the commands.  Might be ok for a test like this, but not such
a good example for users.  lt_dlexit could be warranted even if
some error occurred before.  Anyway, I won't reject the patch for
this.

 +  if (errormsg)
 +{
 +  fprintf (stderr, %s: %s.\n, argv[0], errormsg);
 +  free (errormsg);
 +  exit (EXIT_FAILURE);
 +}
 +
 +  return EXIT_SUCCESS;
 +}
 +
 +/* Be careful to save a copy of the error message,
 +   since the  next API call may overwrite the original. */
 +static char *
 +dlerrordup (char *errormsg)
 +{
 +  char *error = (char *) lt_dlerror ();
 +  if (error  !errormsg)
 +errormsg = strdup (error);
 +  return errormsg;
 +}
 +]])

 +if test $shlibpath_var = PATH; then

This looks wrong; shouldn't it be != here?  Otherwise, ...

 +  $unset shlibpath_var || shlibpath_var=
 +fi
 +rm $libdir/simple-module.la

... this has only a small chance of succeeding.

 +rm $libdir/libsimple-dylib.la
 +
 +for dir in inst/lib $libdir; do
 +  LT_AT_EXEC_CHECK([./ltdl-loader], [], [stdout], [ignore],
 + [$dir/simple-module World])
 +  AT_CHECK([grep Hello, World stdout], [], [ignore])
 +  LT_AT_EXEC_CHECK([./ltdl-loader], [], [stdout], [ignore],
 + [$dir/libsimple-dylib World])
 +  AT_CHECK([grep Hello, World stdout], [], [ignore])
 +done
 +
 +AT_CLEANUP



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

2011-03-01 Thread 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



Re: -soname passed directly to the compiler

2011-02-15 Thread Ralf Wildenhues
* tom fogal wrote on Tue, Feb 15, 2011 at 06:34:44PM CET:
 Hi, sorry for the slow response.

No worries.

 Ralf Wildenhues writes:
  Hmm, even libtool 1.5.26 should be detecting mpicc as gcc but
  apparently it isn't.  You could look in config.log to find out why.
  I'd really really suggest using a newer Libtool though [. . .]
 
 Just wanted to follow up for the archives.  I upgraded libtool but hit
 lots of strange issues.  Ended up upgrading both autoconf and automake
 too, which of course were also a few years old.
 
 I was still hitting issues, now with libtool trying to execute X--gcc
 or something like that; it seemed to be a common problem, from google
 searches, yet nobody had a concrete answer.  I'm afraid I don't either:
 my solution was to stash my current changes and `git clean -df'.  I
 don't version control configure, aclocal.m4, config.* etc., and so this
 got me a virgin tree.
 
 At that point 'libtoolize --copy --force  autoreconf -vi' got me a
 working build system.  There must have been some sort of state which
 was not getting overwritten from the above w/o cleaning out the whole
 tree, but I do not know what it was, exactly.

I want to add this to the to-be-written FAQ.  I have half an idea of
where that bug comes from but would like to make sure.  Please specify
exactly which Autoconf, Automake, and Libtool versions you used before
upgrading, and then, in which order you upgraded which tool to what
newer version.

Thanks,
Ralf

___
http://lists.gnu.org/mailman/listinfo/libtool


debbugs, and a FAQ, for Autotools

2011-02-13 Thread Ralf Wildenhues
[ Cross post; Reply-To and Mail-Followup-To set.  Please followup to
  the automake list only, to avoid excessive spammage.  Thank you.  ]

Hello everyone,

I've been advertising debbugs before, I think we should be a good
example.  So, two proposals:

1) Autoconf and Libtool should also use debbugs.

bug-automake has switched a few months ago, and I find it helpful to
avoid losing reports.  Given that we never have enough time on our
hands, it becomes more important to not lose track.

See http://debbugs.gnu.org/ and linked pages for details.

2) Autotools should have a FAQ document.  Not of the sort of the FAQ
chapter that answers seven random questions and that has a 1 year+
latency until it is updated, but one that answers both totally-newbie
kinds of questions that get asked over and over again, or cross-tool
bug questions like the infamous libtool echo problem (which was due to
an incompatible m4sugar change).  A document that, ideally, eventually
obsoletes many of the third-party here's how autotools work, in quick
kinds of pages.

See e.g., this most recent thread which made the need so clear again:
http://thread.gmane.org/gmane.comp.sysutils.automake.patches/5672


For (2) I'd suggest a wiki if we GNU the infrastructure, but something
like a new page http://www.gnu.org/software/automake/Autotools-FAQ.html
would certainly be good.  (And yes, I've been arguing against wikis in
the past.  I was wrong.  Sue me.)


Now, I have very little spare time on my hands.  Any volunteers on
managing such a document?  Any people interested in contributing answers
or even only questions?  I wouldn't mind handing out commit privs to any
of the regulars on these lists.

Thanks for feedback,
Ralf

___
http://lists.gnu.org/mailman/listinfo/libtool


Re: -soname passed directly to the compiler

2011-02-13 Thread Ralf Wildenhues
Hello Tom,

* tom fogal wrote on Sun, Feb 13, 2011 at 10:23:30PM CET:
 A package we're converting to the autotools is having an issue building
 a library; it seems to think gcc supports a -soname option.
 
   /bin/sh ../libtool --tag=CC   --mode=link mpicc  -I/home/tfogal/sw/include
   -L/home/tfogal/sw/lib -o libH5Part.la -rpath
   /home/tfogal/dev/install-h5part/lib H5Part.lo H5PartAttrib.lo H5Block.lo
   H5BlockReadWrite.lo H5MultiBlock.lo H5MultiBlockReadWrite.lo  -lhdf5
   mpicc -shared  .libs/H5Part.o .libs/H5PartAttrib.o .libs/H5Block.o
   .libs/H5BlockReadWrite.o .libs/H5MultiBlock.o .libs/H5MultiBlockReadWrite.o
   -L/home/tfogal/sw/lib /home/tfogal/shigeru/lib/libhdf5.a -lc  -soname
   libH5Part.so.0 -o .libs/libH5Part.so.0.0.0
   gcc: libH5Part.so.0: No such file or directory
   gcc: unrecognized option '-soname'

 ltmain.sh (GNU libtool) 1.5.26 Debian 1.5.26-4+lenny1 (1.1220.2.493 2008/02/01
 16:58:18)

Hmm, even libtool 1.5.26 should be detecting mpicc as gcc but apparently
it isn't.  You could look in config.log to find out why.  I'd really
really suggest using a newer Libtool though, 2.4 is the current version,
and I'm not eager to debug issues in the 1.5 branch (which has been dead
for almost three years now) any more.

Thanks,
Ralf

___
http://lists.gnu.org/mailman/listinfo/libtool


[SCM] GNU Libtool branch, master, updated. v2.4-47-gd6f69ef

2011-02-07 Thread Ralf Wildenhues
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project GNU Libtool.

The branch, master has been updated
   via  d6f69ef647cb09d1baed104e769377f743a8aa8f (commit)
  from  86562ff7358179df2c44669c53525a86b3723312 (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -
commit d6f69ef647cb09d1baed104e769377f743a8aa8f
Author: Ralf Wildenhues ralf.wildenh...@gmx.de
Date:   Mon Feb 7 07:40:17 2011 +0100

docs: fix copyright years in PDF version of the manual.

* doc/libtool.texi: Fix copyright years.

---

Summary of changes:
 ChangeLog|5 +
 doc/libtool.texi |2 +-
 2 files changed, 6 insertions(+), 1 deletions(-)

diff --git a/ChangeLog b/ChangeLog
index 7165e8a..6e89fa8 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,8 @@
+2011-02-07  Ralf Wildenhues  ralf.wildenh...@gmx.de
+
+   docs: fix copyright years in PDF version of the manual.
+   * doc/libtool.texi: Fix copyright years.
+
 2011-02-01  Rainer Orth  r...@cebitec.uni-bielefeld.de  (tiny change)
 
Fix LD setting for 64-bit Solaris 2/x86.
diff --git a/doc/libtool.texi b/doc/libtool.texi
index 727a03d..72bb0fc 100644
--- a/doc/libtool.texi
+++ b/doc/libtool.texi
@@ -53,7 +53,7 @@ identical to this one except for the removal of this paragraph
 
 @page
 @vskip 0pt plus 1filll
-Copyright @copyright{} 2011 Free Software Foundation, Inc.
+Copyright @copyright{} 1996-2011 Free Software Foundation, Inc.
 
 Permission is granted to copy, distribute and/or modify this document
 under the terms of the GNU Free Documentation License, Version 1.3


hooks/post-receive
-- 
GNU Libtool



docs: fix copyright years in PDF version of the manual.

2011-02-07 Thread 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

2011-02-03 Thread 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



[SCM] GNU Libtool branch, master, updated. v2.4-45-g9196966

2011-01-31 Thread Ralf Wildenhues
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project GNU Libtool.

The branch, master has been updated
   via  9196966580f6853a31187a7a3c7e7ff36ef08982 (commit)
  from  286e87b1030c353d9cfc89dbb72d59e0391cb693 (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -
commit 9196966580f6853a31187a7a3c7e7ff36ef08982
Author: Rainer Orth r...@cebitec.uni-bielefeld.de
Date:   Tue Feb 1 07:34:26 2011 +0100

Fix LD setting for 64-bit Solaris 2/x86.

* libltdl/m4/libtool.m4 (_LT_ENABLE_LOCK) [*-*-solaris*):
Determine GNU ld options for 64-bit Solaris 2/x86.  Detect gld
2.21 _sol2 emulations.

Signed-off-by: Ralf Wildenhues ralf.wildenh...@gmx.de

---

Summary of changes:
 ChangeLog |7 +++
 libltdl/m4/libtool.m4 |   17 +++--
 2 files changed, 22 insertions(+), 2 deletions(-)

diff --git a/ChangeLog b/ChangeLog
index 8ff779b..ef4c27c 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,10 @@
+2011-02-01  Rainer Orth  r...@cebitec.uni-bielefeld.de  (tiny change)
+
+   Fix LD setting for 64-bit Solaris 2/x86.
+   * libltdl/m4/libtool.m4 (_LT_ENABLE_LOCK) [*-*-solaris*):
+   Determine GNU ld options for 64-bit Solaris 2/x86.  Detect gld
+   2.21 _sol2 emulations.
+
 2011-01-27  Peter O'Gorman  pe...@pogma.com
 
Don't loop through wrapper script arguments unnecessarily.
diff --git a/libltdl/m4/libtool.m4 b/libltdl/m4/libtool.m4
index 033c9a0..5cc027b 100644
--- a/libltdl/m4/libtool.m4
+++ b/libltdl/m4/libtool.m4
@@ -1374,14 +1374,27 @@ s390*-*linux*|s390*-*tpf*|sparc*-*linux*)
 CFLAGS=$SAVE_CFLAGS
   fi
   ;;
-sparc*-*solaris*)
+*-*solaris*)
   # Find out which ABI we are using.
   echo 'int i;'  conftest.$ac_ext
   if AC_TRY_EVAL(ac_compile); then
 case `/usr/bin/file conftest.o` in
 *64-bit*)
   case $lt_cv_prog_gnu_ld in
-  yes*) LD=${LD-ld} -m elf64_sparc ;;
+  yes*)
+case $host in
+i?86-*-solaris*)
+  LD=${LD-ld} -m elf_x86_64
+  ;;
+sparc*-*-solaris*)
+  LD=${LD-ld} -m elf64_sparc
+  ;;
+esac
+# GNU ld 2.21 introduced _sol2 emulations.  Use them if available.
+if ${LD-ld} -V | grep _sol2 /dev/null 21; then
+  LD=${LD-ld}_sol2
+fi
+;;
   *)
if ${LD-ld} -64 -r -o conftest2.o conftest.o /dev/null 21; then
  LD=${LD-ld} -64


hooks/post-receive
-- 
GNU Libtool



[SCM] GNU Libtool branch, master, updated. v2.4-46-g86562ff

2011-01-31 Thread Ralf Wildenhues
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project GNU Libtool.

The branch, master has been updated
   via  86562ff7358179df2c44669c53525a86b3723312 (commit)
  from  9196966580f6853a31187a7a3c7e7ff36ef08982 (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -
commit 86562ff7358179df2c44669c53525a86b3723312
Author: Ralf Wildenhues ralf.wildenh...@gmx.de
Date:   Tue Feb 1 07:48:39 2011 +0100

fix typo in ChangeLog

---

Summary of changes:
 ChangeLog |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/ChangeLog b/ChangeLog
index ef4c27c..7165e8a 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,7 +1,7 @@
 2011-02-01  Rainer Orth  r...@cebitec.uni-bielefeld.de  (tiny change)
 
Fix LD setting for 64-bit Solaris 2/x86.
-   * libltdl/m4/libtool.m4 (_LT_ENABLE_LOCK) [*-*-solaris*):
+   * libltdl/m4/libtool.m4 (_LT_ENABLE_LOCK) [*-*-solaris*]:
Determine GNU ld options for 64-bit Solaris 2/x86.  Detect gld
2.21 _sol2 emulations.
 


hooks/post-receive
-- 
GNU Libtool



Re: [libgo, build] Use convenience libraries to create .gox files

2011-01-31 Thread 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  ro@...  (tiny change)

Fix LD setting for 64-bit Solaris 2/x86.
* libltdl/m4/libtool.m4 (_LT_ENABLE_LOCK) [*-*-solaris*):
Determine GNU ld options for 64-bit Solaris 2/x86.  Detect gld
2.21 _sol2 emulations.

diff --git a/libltdl/m4/libtool.m4 b/libltdl/m4/libtool.m4
index 033c9a0..5cc027b 100644
--- a/libltdl/m4/libtool.m4
+++ b/libltdl/m4/libtool.m4
@@ -1374,14 +1374,27 @@ s390*-*linux*|s390*-*tpf*|sparc*-*linux*)
 CFLAGS=$SAVE_CFLAGS
   fi
   ;;
-sparc*-*solaris*)
+*-*solaris*)
   # Find out which ABI we are using.
   echo 'int i;'  conftest.$ac_ext
   if AC_TRY_EVAL(ac_compile); then
 case `/usr/bin/file conftest.o` in
 *64-bit*)
   case $lt_cv_prog_gnu_ld in
-  yes*) LD=${LD-ld} -m elf64_sparc ;;
+  yes*)
+case $host in
+i?86-*-solaris*)
+  LD=${LD-ld} -m elf_x86_64
+  ;;
+sparc*-*-solaris*)
+  LD=${LD-ld} -m elf64_sparc
+  ;;
+esac
+# GNU ld 2.21 introduced _sol2 emulations.  Use them if available.
+if ${LD-ld} -V | grep _sol2 /dev/null 21; then
+  LD=${LD-ld}_sol2
+fi
+;;
   *)
if ${LD-ld} -64 -r -o conftest2.o conftest.o /dev/null 21; then
  LD=${LD-ld} -64



links between PDF manuals

2011-01-29 Thread 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: how to debug unexpected dependency

2011-01-27 Thread Ralf Wildenhues
Hello Mirko,

* Mirko Vukovic wrote on Thu, Jan 27, 2011 at 06:31:04PM CET:
 A build of mpc on 64-bit RHEL5 fails.  I tracked down the cause to an entry
 in libmpc.la file:
 
 # Libraries that this one depends upon.
 dependency_libs='
 /usr/local/lib/libmpfr.la/home/nini/OpenFOAM/ThirdParty-1.7.0/platforms/linux64/gmp-5.0.1/lib/
 libgmp.la /usr/local/lib/libgmp.la'

 I am looking for ideas on how to debug this condition.

Usually, by looking at the output of the 'libtool --mode=link' command
that produces this library, with --debug added as first argument to
libtool.  In this (usually large!) trace output find out why this path
is searched at all.  That usually points to where the problem comes from.

If you have the trace but cannot decipher it, feel free to post it here,
gzip'ed.

Hope that helps.

Cheers,
Ralf

___
http://lists.gnu.org/mailman/listinfo/libtool


Re: How to create only executable files

2011-01-24 Thread Ralf Wildenhues
* Sergio Belkin wrote on Mon, Jan 24, 2011 at 11:42:25AM CET:
 Let's say that you have a library libfoo.so and you have on build tree a
 source file fred.c. You've created a test target that creat (with
 -no-install flag)  the  ELF  executable fred (note that has no extension).
 But libtool create also fred.o an ELF relocatable, is there a way that
 libtool create only the ELF excutable? What is the advantage of create an
 intermediate file?

Simplicity of (Automake+Libtool) implementation.
Absence of (non-esthetic) downsides for the user.

Cheers,
Ralf

___
http://lists.gnu.org/mailman/listinfo/libtool


Re: pic-only option not working as expected

2011-01-22 Thread Ralf Wildenhues
* John Calcote wrote on Sat, Jan 22, 2011 at 08:42:33PM CET:
 LT_INIT([disable-shared static pic-only])
 ...
 
 While playing with these options, I noticed that the 'disable-shared'
 and 'static' options seem to have the desired effect, but the 'pic-only'
 option does not. Whether I use 'pic-only' or not, I get the following
 output from 'configure --help':

I was just going to get to this patch tomorrow.  I haven't retested it
and am on a run now.  Can you try it?  Jose reported this to me
off-list.

Thanks,
Ralf

Fix LT_INIT([pic-only]) semantics.

* libltdl/m4/ltoptions.m4 (_LT_WITH_PIC): Use the macro argument
for setting the default for pic_mode.
* tests/pic.at: New file, new test.
* Makefile.am (TESTSUITE_AT): Update.
Reports by Jose Marchesi, Luke Mewburn, and John Calcote.

diff --git a/Makefile.am b/Makefile.am
index 15d9404..3c8f213 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -510,6 +510,7 @@ TESTSUITE_AT= tests/testsuite.at \
  tests/stresstest.at \
  tests/cmdline_wrap.at \
  tests/pic_flag.at \
+ tests/pic.at \
  tests/old-autotools.at \
  tests/darwin.at \
  tests/dumpbin-symbols.at \
diff --git a/libltdl/m4/ltoptions.m4 b/libltdl/m4/ltoptions.m4
index 5d9acd8..91876f0 100644
--- a/libltdl/m4/ltoptions.m4
+++ b/libltdl/m4/ltoptions.m4
@@ -344,7 +344,7 @@ m4_define([_LT_WITH_PIC],
   IFS=$lt_save_ifs
   ;;
 esac],
-[pic_mode=default])
+[pic_mode=m4_default([$1], [default])])
 
 test -z $pic_mode  pic_mode=m4_default([$1], [default])
 
diff --git a/tests/pic.at b/tests/pic.at
new file mode 100644
index 000..545d9cc
--- /dev/null
+++ b/tests/pic.at
@@ -0,0 +1,38 @@
+# pic.at -- LT_INIT(pic)   -*- Autotest -*-
+
+#   Copyright (C) 2010 Free Software Foundation, Inc.
+#
+#   This file is part of GNU Libtool.
+#
+# GNU Libtool is free software; you can redistribute it and/or
+# modify it under the terms of the GNU General Public License as
+# published by the Free Software Foundation; either version 2 of
+# the License, or (at your option) any later version.
+#
+# GNU Libtool is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with GNU Libtool; see the file COPYING.  If not, a copy
+# can be downloaded from  http://www.gnu.org/licenses/gpl.html,
+# or obtained by writing to the Free Software Foundation, Inc.,
+# 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
+
+
+AT_SETUP([pic-only])
+
+AT_DATA([configure.ac],
+[[AC_INIT
+AC_CONFIG_MACRO_DIR([m4])
+LT_INIT([pic-only])
+AC_OUTPUT
+]])
+
+mkdir m4
+LT_AT_BOOTSTRAP([--install], [], [ignore], [ignore], [], [], [ignore])
+AT_CHECK([./libtool --config | grep pic_mode], [], [pic_mode=yes
+])
+
+AT_CLEANUP

___
http://lists.gnu.org/mailman/listinfo/libtool


Re: [PATCH] libtool.m4: remove (incorrect) handling of FreeBSD 1.x

2011-01-20 Thread 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  ger...@pfeifer.com  (tiny change)

Remove support for FreeBSD 1.x.
* libltdl/m4/libtool.m4 (_LT_LINKER_SHLIBS)
(_LT_SYS_DYNAMIC_LINKER): Remove handling of freebsd1* which
soon would incorrectly match FreeBSD 10.0.
* NEWS, THANKS: Update.

diff --git a/NEWS b/NEWS
index 39eb771..dbad2ae 100644
--- a/NEWS
+++ b/NEWS
@@ -28,6 +28,7 @@ New in 2.4.2 2011-??-??: git version 2.4.1a, Libtool team:
 * Changes in supported systems or compilers:
 
   - Fixes for gfortran on Darwin, XL Fortran on GNU/Linux.
+  - Support for FreeBSD 1.x (outdated since 1994) has been removed.
 
 New in 2.4 2010-09-22: git version 2.2.11a, Libtool team:
 
diff --git a/libltdl/m4/libtool.m4 b/libltdl/m4/libtool.m4
index ba2d5e4..033c9a0 100644
--- a/libltdl/m4/libtool.m4
+++ b/libltdl/m4/libtool.m4
@@ -2455,10 +2455,6 @@ dgux*)
   shlibpath_var=LD_LIBRARY_PATH
   ;;
 
-freebsd1*)
-  dynamic_linker=no
-  ;;
-
 freebsd* | dragonfly*)
   # DragonFly does not have aout.  When/if they implement a new
   # versioning mechanism, adjust this.
@@ -5178,10 +5174,6 @@ _LT_EOF
   _LT_TAGVAR(hardcode_shlibpath_var, $1)=no
   ;;
 
-freebsd1*)
-  _LT_TAGVAR(ld_shlibs, $1)=no
-  ;;
-
 # FreeBSD 2.2.[012] allows us to include c++rt0.o to get C++ constructor
 # support.  Future versions do this automatically, but an explicit c++rt0.o
 # does not break anything, and helps significantly (at the cost of a little



Re: [PATCH] Darwin - verbose linker messages influence configure results.

2011-01-19 Thread 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 2conftest.err
  _lt_result=$?
 - if test -f libconftest.dylib  test ! -s conftest.err  test 
 $_lt_result = 0; then
 + # If there is a non-empty error log, and single_module
 + # appears in it, assume the flag caused a linker warning
 +if test -s conftest.err  $GREP single_module conftest.err; then
 +   cat conftest.err AS_MESSAGE_LOG_FD
 + # Otherwise, if the output was created with a 0 exit code from
 + # the compiler, it worked.
 + elif test -f libconftest.dylib  test $_lt_result = 0; then

-eq instead of =

 lt_cv_apple_cc_single_mod=yes
   else
 cat conftest.err AS_MESSAGE_LOG_FD
 @@ -994,6 +1000,7 @@ m4_defun_once([_LT_REQUIRED_DARWIN_CHECKS],[
   rm -rf libconftest.dylib*
   rm -f conftest.*
fi])
 +
  AC_CACHE_CHECK([for -exported_symbols_list linker flag],
[lt_cv_ld_exported_symbols_list],
[lt_cv_ld_exported_symbols_list=no
 @@ -1005,6 +1012,7 @@ m4_defun_once([_LT_REQUIRED_DARWIN_CHECKS],[
   [lt_cv_ld_exported_symbols_list=no])
   LDFLAGS=$save_LDFLAGS
  ])
 +
  AC_CACHE_CHECK([for -force_load linker flag],[lt_cv_ld_force_load],
[lt_cv_ld_force_load=no
cat  conftest.c  _LT_EOF
 @@ -1022,7 +1030,9 @@ _LT_EOF
echo $LTCC $LTCFLAGS $LDFLAGS -o conftest conftest.c 
 -Wl,-force_load,./libconftest.a AS_MESSAGE_LOG_FD
$LTCC $LTCFLAGS $LDFLAGS -o conftest conftest.c 
 -Wl,-force_load,./libconftest.a 2conftest.err
_lt_result=$?
 -  if test -f conftest  test ! -s conftest.err  test $_lt_result = 0 
  $GREP forced_load conftest 21 /dev/null; then
 +  if test -s conftest.err  $GREP force_load conftest.err; then
 + cat conftest.err AS_MESSAGE_LOG_FD
 +  elif test -f conftest  test $_lt_result = 0  $GREP forced_load 
 conftest 21 /dev/null; then

Likewise.

Also, /dev/null 21  (order matters!)

Are you really grepping the binary intentionally here, rather than the
.err file?

   lt_cv_ld_force_load=yes
else
   cat conftest.err AS_MESSAGE_LOG_FD




Re: Stop relink searching host directory when installation prefix provided

2011-01-16 Thread 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: Libtool sysroot RPATH problems

2011-01-12 Thread Ralf Wildenhues
Hello Richard,

* Richard Purdie wrote on Wed, Jan 12, 2011 at 12:06:13AM CET:
 Firstly, for the first time ever for us, it appears libtool is no longer
 relinking our libraries at install time.

That's weird, I don't think the sysroot feature should've caused this
change.  Not quite sure though.

 This is welcome as we're cross
 compiling to a sysroot and we'd never want to actually run them in situ
 so this could probably save us some build time. It does however mean we
 never go for a relink step so we're hitting codepaths and issues that
 I've never seen. For reference, we always used to set installed=no in
 our staged libraries prior to sysroot support since this let us hack
 around the lack of sysroot support easier.
 
 Anyhow, the problem I'm seeing is that the final library has an RPATH
 including the sysroot prefix when make is calling libtool with
 -rpath /usr/lib at link time. I looked at the code in ltmain.m4sh
 starting at line 7240 (see the end of the email for a quotation) and
 firstly, I don't understand why the func_replace_sysroot call is inside
 the $hardcode_libdir_separator test? Surely it should be outside it and
 happen whenever $hardcode_libdir_flag_spec is set?

Please show the --mode={link,install} commands plus all of their output,
also './libtool --config'.  Please also show how exactly you invoke
configure.  Thanks.

 Changing that helps a bit and I end up with an RPATH of =/usr/lib so
 the sysroot prefix is gone but the = is there. I suspect that isn't
 valid so I added the following code after the func_replace_sysroot call
 
 func_stripname '=' '' $libdir
 libdir=$func_stripname_result
 
 and then I get an RPATH of /usr/lib which is ok to a point.

The replacing of '=' can be achieved by running 'libtool --mode=finish
LIB' later, although I see we don't document this everywhere yet.

 Of course this is listed in $sys_lib_dlsearch_path_spec so shouldn't be
 getting added at all. Its coming to this function via $compile_rpath
 which is being set around line 5939 which in turn is coming from absdir.
 absdir is being compared against $sys_lib_dlsearch_path_spec but without
 adding/removing any sysroot prefixes.

Hmm, that sounds like a bug indeed.

 I'd really therefore like to ask what behaviour to be expecting from
 libtool before I try and write patches to fix any of this. To summarise
 some of my questions:

I can answer them only with more information, sorry.

Thanks,
Ralf

___
http://lists.gnu.org/mailman/listinfo/libtool


[SCM] GNU Libtool branch, master, updated. v2.4-40-ga55208d

2011-01-09 Thread Ralf Wildenhues
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project GNU Libtool.

The branch, master has been updated
   via  a55208d56bf723f68b245c6ea03ce3f36a2e23ba (commit)
  from  ce87974b8e4315c296629578f9abd089fda60412 (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -
commit a55208d56bf723f68b245c6ea03ce3f36a2e23ba
Author: Ralf Wildenhues ralf.wildenh...@gmx.de
Date:   Sun Jan 9 17:55:17 2011 +0100

Fix $wl setting for Solaris Studio 12.2 f90 on GNU/Linux.

* libltdl/m4/libtool.m4 (_LT_COMPILER_PIC) [linux]
lt_prog_compiler_wl: Set to '-Qoption ld ' if we
detect Sun Fortran version 8.4 or newer.
Report by Terry Dontje.

Signed-off-by: Ralf Wildenhues ralf.wildenh...@gmx.de

---

Summary of changes:
 ChangeLog |8 
 libltdl/m4/libtool.m4 |7 ++-
 2 files changed, 14 insertions(+), 1 deletions(-)

diff --git a/ChangeLog b/ChangeLog
index bcbc448..186ccc3 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,11 @@
+2011-01-09  Ralf Wildenhues  ralf.wildenh...@gmx.de
+
+   Fix $wl setting for Solaris Studio 12.2 f90 on GNU/Linux.
+   * libltdl/m4/libtool.m4 (_LT_COMPILER_PIC) [linux]
+   lt_prog_compiler_wl: Set to '-Qoption ld ' if we
+   detect Sun Fortran version 8.4 or newer.
+   Report by Terry Dontje.
+
 2011-01-07  Peter Rosin  p...@lysator.liu.se
 
Convert file name to toolchain format when blessing archives.
diff --git a/libltdl/m4/libtool.m4 b/libltdl/m4/libtool.m4
index c144755..fd79dcf 100644
--- a/libltdl/m4/libtool.m4
+++ b/libltdl/m4/libtool.m4
@@ -4363,12 +4363,17 @@ m4_if([$1], [CXX], [
;;
   *)
case `$CC -V 21 | sed 5q` in
-   *Sun\ F* | *Sun*Fortran*)
+   *Sun\ Ceres\ Fortran* | *Sun*Fortran*\ [[1-7]].* | *Sun*Fortran*\ 
8.[[0-3]]*)
  # Sun Fortran 8.3 passes all unrecognized flags to the linker
  _LT_TAGVAR(lt_prog_compiler_pic, $1)='-KPIC'
  _LT_TAGVAR(lt_prog_compiler_static, $1)='-Bstatic'
  _LT_TAGVAR(lt_prog_compiler_wl, $1)=''
  ;;
+   *Sun\ F* | *Sun*Fortran*)
+ _LT_TAGVAR(lt_prog_compiler_pic, $1)='-KPIC'
+ _LT_TAGVAR(lt_prog_compiler_static, $1)='-Bstatic'
+ _LT_TAGVAR(lt_prog_compiler_wl, $1)='-Qoption ld '
+ ;;
*Sun\ C*)
  # Sun C 5.9
  _LT_TAGVAR(lt_prog_compiler_pic, $1)='-KPIC'


hooks/post-receive
-- 
GNU Libtool



[SCM] GNU Libtool branch, master, updated. v2.4-41-g9167aec

2011-01-09 Thread Ralf Wildenhues
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project GNU Libtool.

The branch, master has been updated
   via  9167aecabd12c5afe7a65d45dc73f8c92ab42f05 (commit)
  from  a55208d56bf723f68b245c6ea03ce3f36a2e23ba (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -
commit 9167aecabd12c5afe7a65d45dc73f8c92ab42f05
Author: John David Anglin dave.ang...@nrc-cnrc.gc.ca
Date:   Sun Jan 9 19:51:28 2011 +0100

Fix relink mode to use absolute path if hardcode_minus_L.

* libltdl/config/ltmain.m4sh (func_mode_link): Use absolute path
when hardcoding with -L.

Signed-off-by: Ralf Wildenhues ralf.wildenh...@gmx.de

---

Summary of changes:
 ChangeLog  |6 ++
 libltdl/config/ltmain.m4sh |2 +-
 2 files changed, 7 insertions(+), 1 deletions(-)

diff --git a/ChangeLog b/ChangeLog
index 186ccc3..1ad3741 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,9 @@
+2011-01-09  John David Anglin  dave.ang...@nrc-cnrc.gc.ca  (tiny change)
+
+   Fix relink mode to use absolute path if hardcode_minus_L.
+   * libltdl/config/ltmain.m4sh (func_mode_link): Use absolute path
+   when hardcoding with -L.
+
 2011-01-09  Ralf Wildenhues  ralf.wildenh...@gmx.de
 
Fix $wl setting for Solaris Studio 12.2 f90 on GNU/Linux.
diff --git a/libltdl/config/ltmain.m4sh b/libltdl/config/ltmain.m4sh
index d9e1cd2..7baa6aa 100644
--- a/libltdl/config/ltmain.m4sh
+++ b/libltdl/config/ltmain.m4sh
@@ -6050,7 +6050,7 @@ func_mode_link ()
 test $hardcode_direct_absolute = no; then
add=$dir/$linklib
  elif test $hardcode_minus_L = yes; then
-   add_dir=-L$dir
+   add_dir=-L$absdir
# Try looking first in the location we're being installed to.
if test -n $inst_prefix_dir; then
  case $libdir in


hooks/post-receive
-- 
GNU Libtool



Re: Oracle Solaris Studio 12.2 compiler incompatibility with libtool

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



Re: [patch libgfortran] path to libquadmath

2011-01-09 Thread 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  dave.ang...@nrc-cnrc.gc.ca
 
   * ltmain.sh (relink): Use absolute path when hardcoding with -L.
 

2011-01-09  John David Anglin  dave.ang...@nrc-cnrc.gc.ca  (tiny change)

Fix relink mode to use absolute path if hardcode_minus_L.
* libltdl/config/ltmain.m4sh (func_mode_link): Use absolute path
when hardcoding with -L.

diff --git a/libltdl/config/ltmain.m4sh b/libltdl/config/ltmain.m4sh
index d9e1cd2..7baa6aa 100644
--- a/libltdl/config/ltmain.m4sh
+++ b/libltdl/config/ltmain.m4sh
@@ -6050,7 +6050,7 @@ func_mode_link ()
 test $hardcode_direct_absolute = no; then
add=$dir/$linklib
  elif test $hardcode_minus_L = yes; then
-   add_dir=-L$dir
+   add_dir=-L$absdir
# Try looking first in the location we're being installed to.
if test -n $inst_prefix_dir; then
  case $libdir in



Re: func_convert_file_cygwin_to_w32 woes

2011-01-08 Thread 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 p...@lysator.liu.se
 Date: Fri, 7 Jan 2011 21:22:10 +0100
 Subject: [PATCH] Convert to toolchain format when invoking the archiver.



Re: func_convert_file_cygwin_to_w32 woes

2011-01-07 Thread 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

2011-01-06 Thread 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



Re: Libtool library used but `LIBTOOL' is undefined??

2011-01-04 Thread Ralf Wildenhues
Hello,

* kknd1233 wrote on Wed, Jan 05, 2011 at 12:14:20AM CET:
 And then when I run the command 'autoreconf --install', it said an error
 message like
 
 lib/Makefile.am:1: Libtool library used but `LIBTOOL' is undefined
 lib/Makefile.am:1:   The usual way to define `LIBTOOL' is to add
 `AC_PROG_LIBTOOL'
 lib/Makefile.am:1:   to `configure.ac' and run `aclocal' and `autoconf'
 again.
 lib/Makefile.am:1:   If `AC_PROG_LIBTOOL' is in `configure.ac', make sure
 lib/Makefile.am:1:   its definition is in aclocal's search path.
 

(LT_INIT is a synonym of AC_PROG_LIBTOOL.)

I presume your Automake and your Libtool are not installed below the
same prefix, thus aclocal doesn't find the Libtool macros to install.
One solution is to install both below the same prefix; or write a
dirlist file in $automake_prefix/share/aclocal with a line containing
$libtool_prefix/share/aclocal.

Or the error has a different reason, in which case please post output of
  autoreconf --verbose --install

Hope that helps.

Cheers,
Ralf

___
http://lists.gnu.org/mailman/listinfo/libtool


Happy New Year!

2011-01-01 Thread 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 g...@gnu.ai.mit.edu, 1996
 
 # Copyright (C) 1996, 1997, 1998, 1999, 2000, 2001, 2003, 2004, 2005, 2006,
-# 2007, 2008, 2009, 2010 Free Software Foundation, Inc.
+# 2007, 2008, 2009, 2010, 2011 Free Software Foundation, Inc.
 # This is free software; see the source for copying conditions.  There is NO
 # warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
 
diff --git a/libltdl/m4/libtool.m4 b/libltdl/m4/libtool.m4
index 8e88917..4239395 100644
--- a/libltdl/m4/libtool.m4
+++ b/libltdl/m4/libtool.m4
@@ -1,8 +1,8 @@
 # libtool.m4 - Configure libtool for the host system. -*-Autoconf-*-
 #
 #   Copyright (C) 1996, 1997, 1998, 1999, 2000, 2001, 2003, 2004, 2005,
-# 2006, 2007, 2008, 2009, 2010 Free Software Foundation,
-# Inc.
+# 2006, 2007, 2008, 2009, 2010, 2011 Free Software
+# Foundation, Inc.
 #   Written by Gordon Matzigkeit, 1996
 #
 # This file is free software; the Free Software Foundation gives
@@ -11,8 +11,8 @@
 
 m4_define([_LT_COPYING], [dnl
 #   Copyright (C) 1996, 1997, 1998, 1999, 2000, 2001, 2003, 2004, 2005,
-# 2006, 2007, 2008, 2009, 2010 Free Software Foundation,
-# Inc.
+# 2006, 2007, 2008, 2009, 2010, 2011 Free Software
+# Foundation, Inc.
 #   Written by Gordon Matzigkeit, 1996
 #
 #   This file is part of GNU Libtool.
@@ -639,7 +639,7 @@ m4_ifset([AC_PACKAGE_NAME], [AC_PACKAGE_NAME 
])config.lt[]dnl
 m4_ifset([AC_PACKAGE_VERSION], [ AC_PACKAGE_VERSION])
 configured by $[0], generated by m4_PACKAGE_STRING.
 
-Copyright (C) 2010 Free Software Foundation, Inc.

Re: func_convert_file_cygwin_to_w32 woes

2011-01-01 Thread Ralf Wildenhues
Hi Dan,

* Dan McMahill wrote on Sat, Jan 01, 2011 at 04:53:25AM CET:
 I am trying to build a program under cygwin but using the mingw tool
 chain in a fake cross build way.  In my configure environment, I have:
 
  export lt_cv_to_tool_file_cmd=func_convert_file_cygwin_to_w32
 
 as suggested by the libtool manual.  I'm using libtool 2.4.
 
 Everything goes smoothly until install time when libtool calls ranlib
 (the mingw one) on an absolute path and of course the cygwin absolute
 path doesn't make sense to the mingw ranlib.  I thought that's what the
 func_convert... bit was for.

Please copy and paste 'libtool --mode={link,relink,install}' commands
for the libraries and programs involved.  We may provide better help
then.

Cheers,
Ralf

___
http://lists.gnu.org/mailman/listinfo/libtool


Re: How does one specify linking to 64 bit libraries when there is a choice?

2010-12-21 Thread Ralf Wildenhues
* Bruce Korb wrote on Mon, Dec 20, 2010 at 09:37:58PM CET:
 On 12/20/10 11:20, Ralf Wildenhues wrote:
  One crucial part is that libtool gets confused whenever it has
  directories with the wrong ABI in the search path (unlike ld or ld.so,
  both are in some cases smart enough to skip wrong ABI), which means that
  either no instance of the build system machineries may introduce such
  paths, or libtool needs to get smarter to ignore wrong ABI dirs.
 
  The other crucial part is that libtool doesn't get the
  sys_lib_search_path_spec and sys_lib_dlsearch_path_spec settings
  right on several distros, introducing such wrong directories itself (not
  to speak of cross setups).  There have been several proposed patches to
  address this, e.g.
  http://thread.gmane.org/gmane.comp.gnu.libtool.patches/10625
  http://thread.gmane.org/gmane.comp.gnu.libtool.patches/9931
  but I have yet to see one that solves it.
  
  At least with current Libtool you can override wrong settings with the
  lt_cv_sys_lib_search_path_spec and lt_cv_sys_lib_dlsearch_path_spec
  cache variables.

 Addressing things in reverse order:
 
 1. lt_cv_sys_lib... It is true that authors of packages need to be
more knowledgeable than the hapless builder, still they should
not have to fiddle with undocumented internals; and cached variable
values seem like grody internals to me.

I fully agree that such knowledge /should/ not be required.  It's a bug
that libtool doesn't get the right setting by default.

 2. Way back at the beginning, with a default installation of
RHEL for amd-64/x86-64, these commands fail:
 
$ cd $guile_build_dir
$ $guile_src/configure  make  sudo make install
$ cd $autogen_build_dir
$ $autogen_src/configure  make  sudo make install
 
and it fails because `guile-config link` produces output
that libtool interprets and then passes, as a full path name,
a library listed as ``-lXXX'' in the guile-config
output.  The full path, of course, is to a 32 bit shared obj
in  a 64 bit link command.  Oops.
 
So this means that if ld could have identified a 32 bit shared obj
and gone on to look in another directory, all would have been well.
Instead, ld saw a full path and tried to do what it was told,
but said, no, I won't do that.
 
 3. CF:
  One crucial part is that libtool gets confused whenever it has
  directories with the wrong ABI in the search path (unlike ld or ld.so,
  both are in some cases smart enough to skip wrong ABI),
   So DO NOT REPLACE ``-lgmp'' with ``/usr/local/lib/libgmp.so''!!!
   libtool did this and triggered the whole thread.

Again: the replacement of -lgmp with /usr/local/lib/libgmp.so might be
the thing that makes the failure visible, but it is not the underlying
cause, and trying to avoid the replacement is like trying to make
someone go away by closing your eyes.  The error happened earlier: at
the time /usr/local/lib was introduced into the libtool search path.

The replacement of -lfoo with /abs/path/to/libfoo.so on some systems,
notably GNU/Linux, is very helpful in being able to reliably link
against uninstalled libraries even in the presence of -L/some/inst/path
early on the link command line.  Crying against this will not fix the
issue (as there are other places where libtool will get things wrong for
you even if you inhibit this, once it looks in the wrong directories).

   See: http://lists.gnu.org/archive/html/libtool/2010-12/msg00041.html
 
 Just a note: if a distro puts 64 bit SOs in /usr/lib64, then it is
 reasonable to put add-on 64 bit SOs into /usr/local/lib64.  In fact,
 I would consider it peculiar to put 'em into /usr/local/lib.

Sure, that's what you would expect.  What can libtool expect though?
I don't think /usr/local can be treated as necessarily having the same
policy as /usr has, one coming from the distro and the other containing
all kinds of non-adapted (even non-GNU standards using) junk.

 The difference should just be $prefix (i.e. /usr vs. /usr/local).
 If my sloppiness regarding distinguishing /usr/lib from /usr/local/lib
 caused any confusion, my apologies.  The final lib directory name
 should be consistent.

I fail to see how it would be possible to ingrain this rule into all of
our users, overnight.

Cheers,
Ralf

___
http://lists.gnu.org/mailman/listinfo/libtool


Re: How does one specify linking to 64 bit libraries when there is a choice?

2010-12-20 Thread Ralf Wildenhues
* Bruce Korb wrote on Mon, Dec 20, 2010 at 03:09:48PM CET:
   How much understanding of the machinery should be expected
   of the hapless project builder?

I've skimmed most of the conversation in this thread now.

The crucial part, I think, is *not* the --libdir setting.  Distros
usually get that consistent between their packages, and users should not
be using any of /usr/lib{,32,64} but rather something below /usr/local.

One crucial part is that libtool gets confused whenever it has
directories with the wrong ABI in the search path (unlike ld or ld.so,
both are in some cases smart enough to skip wrong ABI), which means that
either no instance of the build system machineries may introduce such
paths, or libtool needs to get smarter to ignore wrong ABI dirs.

The other crucial part is that libtool doesn't get the
sys_lib_search_path_spec and sys_lib_dlsearch_path_spec settings
right on several distros, introducing such wrong directories itself (not
to speak of cross setups).  There have been several proposed patches to
address this, e.g.
http://thread.gmane.org/gmane.comp.gnu.libtool.patches/10625
http://thread.gmane.org/gmane.comp.gnu.libtool.patches/9931
but I have yet to see one that solves it.

Thanks,
Ralf

___
http://lists.gnu.org/mailman/listinfo/libtool


Re: How does one specify linking to 64 bit libraries when there is a choice?

2010-12-20 Thread Ralf Wildenhues
* Ralf Wildenhues wrote on Mon, Dec 20, 2010 at 08:20:25PM CET:
 The other crucial part is that libtool doesn't get the
 sys_lib_search_path_spec and sys_lib_dlsearch_path_spec settings
 right on several distros, introducing such wrong directories itself (not
 to speak of cross setups).  There have been several proposed patches to
 address this, e.g.
 http://thread.gmane.org/gmane.comp.gnu.libtool.patches/10625
 http://thread.gmane.org/gmane.comp.gnu.libtool.patches/9931
 but I have yet to see one that solves it.

ESENDTOOSOON, sorry.

At least with current Libtool you can override wrong settings with the
lt_cv_sys_lib_search_path_spec and lt_cv_sys_lib_dlsearch_path_spec
cache variables.

___
http://lists.gnu.org/mailman/listinfo/libtool


[SCM] GNU Libtool branch, master, updated. v2.4-37-gb78075b

2010-12-19 Thread Ralf Wildenhues
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project GNU Libtool.

The branch, master has been updated
   via  b78075b8ae59ff68f6f9ece21be7c5c13fceabee (commit)
   via  7aabd35c4c78df9c94528c02eae29397bab65987 (commit)
   via  e80566abb3ee6757ff6da59d65a874b3a5f706a1 (commit)
   via  39ba8c55de025805c69d46e76f1a352658e01382 (commit)
  from  92eb89aace9fd41e43eee33f5c392adf1bcf8963 (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -
commit b78075b8ae59ff68f6f9ece21be7c5c13fceabee
Author: Ian Lance Taylor i...@google.com
Date:   Tue Oct 12 14:38:49 2010 -0700

Add Go support.

* libltdl/m4/libtool.m4 (LT_LANG): Add Go.
(AC_PROG_GO): Provide.
(_LT_SYS_HIDDEN_LIBDEPS): Add Go case.
(_LT_LANG_GO_CONFIG): Define.
(LT_PROG_GO): Define.
(AC_PROG_GO): Define if not defined.
* libltdl/config/ltmain.m4sh: Match *.go.
* doc/libtool.texi (LT_INIT): Mention Go.
(Tags): Mention Go.
* configure.ac: Enable Go.
* NEWS: Update.

Signed-off-by: Ralf Wildenhues ralf.wildenh...@gmx.de

commit 7aabd35c4c78df9c94528c02eae29397bab65987
Author: Brice De Bruyne bric...@gmail.com
Date:   Mon Dec 20 04:16:12 2010 +0100

Also turn off -fuse-linker-plugin for postdep_objects computation.

* libltdl/m4/libtool.m4 (_LT_SYS_HIDDEN_LIBDEPS): Add
-fno-use-linker-plugin to temporary compile flags if necessary,
to fix C++ postdep_objects setting with -flto
-fuse-linker-plugin.
* NEWS, THANKS: Update.

Signed-off-by: Ralf Wildenhues ralf.wildenh...@gmx.de

commit e80566abb3ee6757ff6da59d65a874b3a5f706a1
Author: KO Myung-Hun k...@chollian.net
Date:   Mon Dec 20 04:10:19 2010 +0100

Set command line length limit for OS/2.

* libltdl/m4/libtool.m4 (LT_CMD_MAX_LEN) [os2]
lt_cv_sys_max_cmd_len: Set to 8192 to avoid long test.

Signed-off-by: Ralf Wildenhues ralf.wildenh...@gmx.de

commit 39ba8c55de025805c69d46e76f1a352658e01382
Author: Ralf Wildenhues ralf.wildenh...@gmx.de
Date:   Fri Dec 17 20:30:53 2010 +0100

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

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

Signed-off-by: Ralf Wildenhues ralf.wildenh...@gmx.de

---

Summary of changes:
 ChangeLog  |   37 +
 NEWS   |4 ++
 THANKS |1 +
 configure.ac   |1 +
 doc/libtool.texi   |3 +-
 libltdl/config/ltmain.m4sh |2 +-
 libltdl/m4/libtool.m4  |  124 
 tests/suffix.test  |2 +-
 8 files changed, 171 insertions(+), 3 deletions(-)

diff --git a/ChangeLog b/ChangeLog
index cbb0262..4880098 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,40 @@
+2010-12-20  Ian Lance Taylor  i...@google.com
+
+   * libltdl/m4/libtool.m4 (LT_LANG): Add Go.
+   (AC_PROG_GO): Provide.
+   (_LT_SYS_HIDDEN_LIBDEPS): Add Go case.
+   (_LT_LANG_GO_CONFIG): Define.
+   (LT_PROG_GO): Define.
+   (AC_PROG_GO): Define if not defined.
+   * libltdl/config/ltmain.m4sh: Match *.go.
+   * doc/libtool.texi (LT_INIT): Mention Go.
+   (Tags): Mention Go.
+   * configure.ac: Enable Go.
+   * NEWS: Update.
+
+2010-12-20  Brice De Bruyne  bric...@gmail.com  (tiny change)
+
+   Also turn off -fuse-linker-plugin for postdep_objects computation.
+   * libltdl/m4/libtool.m4 (_LT_SYS_HIDDEN_LIBDEPS): Add
+   -fno-use-linker-plugin to temporary compile flags if necessary,
+   to fix C++ postdep_objects setting with -flto
+   -fuse-linker-plugin.
+   * NEWS, THANKS: Update.
+
+2010-12-20  KO Myung-Hun  k...@chollian.net  (tiny change)
+
+   Set command line length limit for OS/2.
+   * libltdl/m4/libtool.m4 (LT_CMD_MAX_LEN) [os2]
+   lt_cv_sys_max_cmd_len: Set to 8192 to avoid long test.
+
+2010-12-20  Ralf Wildenhues  ralf.wildenh...@gmx.de
+
+   Fix PIC flags with mpif77 using ifort on GNU/Linux.
+   * libltdl/m4/libtool.m4 (_LT_COMPILER_PIC) [linux]:
+   Match Intel compiler also using $CC -V output, to avoid false
+   negatives with compiler drivers like mpif77.
+   Report by Christian Rössel.
+
 2010-12-16  Ralf Wildenhues  ralf.wildenh...@gmx.de
 
Fix PIC flags with MPI wrappers using Portland on GNU/Linux.
diff --git a/NEWS b/NEWS
index 0aeca57..96c9723 100644
--- a/NEWS
+++ b/NEWS
@@ -8,6 +8,8 @@ New in 2.4.2 2010-12-??: git version 2.4.1a, Libtool team

Re: ping: [PATCH libtool] hardcoded path to dependent shared libraries on 32-bit hpux (libquadmath)

2010-12-19 Thread 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  dave.ang...@nrc-cnrc.gc.ca
  
  * ltmain.sh (relink): Use absolute path when hardcoding with -L.
  
  Index: ltmain.sh
  ===
  --- ltmain.sh   (revision 167668)
  +++ ltmain.sh   (working copy)
  @@ -5928,7 +5928,7 @@
   test $hardcode_direct_absolute = no; then
  add=$dir/$linklib
elif test $hardcode_minus_L = yes; then
  -   add_dir=-L$dir
  +   add_dir=-L$absdir
  # Try looking first in the location we're being installed to.
  if test -n $inst_prefix_dir; then
case $libdir in



Re: PIC flags not found for mpif77(ifort)

2010-12-19 Thread 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: wrong postdep_objects for CXX when using -flto -fuse-linker-plugin

2010-12-19 Thread 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  bric...@...  (tiny change)

Also turn off -fuse-linker-plugin for postdep_objects computation.
* libltdl/m4/libtool.m4 (_LT_SYS_HIDDEN_LIBDEPS): Add
-fno-use-linker-plugin to temporary compile flags if necessary,
to fix C++ postdep_objects setting with -flto
-fuse-linker-plugin.
* NEWS, THANKS: Update.

diff --git a/NEWS b/NEWS
index 0aeca57..8d6965d 100644
--- a/NEWS
+++ b/NEWS
@@ -15,6 +15,8 @@ New in 2.4.2 2010-12-??: git version 2.4.1a, Libtool team:
   - The bug that leaked developer tool paths into the release tarballs
 from ./bootstrap is fixed.
   - Improved support for the Cuda Compiler Driver (nvcc) on Darwin.
+  - For GCC LTO support, the -fuse-linker-plugin switch is now also removed
+when computing compiler postdeps.
 
 * Important incompatible changes:
 
diff --git a/libltdl/m4/libtool.m4 b/libltdl/m4/libtool.m4
index 5e716b2..21b12fd 100644
--- a/libltdl/m4/libtool.m4
+++ b/libltdl/m4/libtool.m4
@@ -6922,6 +6922,7 @@ _lt_libdeps_save_CFLAGS=$CFLAGS
 case $CC $CFLAGS  in #(
 *\ -flto*\ *) CFLAGS=$CFLAGS -fno-lto ;;
 *\ -fwhopr*\ *) CFLAGS=$CFLAGS -fno-whopr ;;
+*\ -fuse-linker-plugin*\ *) CFLAGS=$CFLAGS -fno-use-linker-plugin ;;
 esac
 
 dnl Parse the compiler output and extract the necessary



Re: Oracle Solaris Studio 12.2 compiler incompatibility with libtool

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

 --- a/libltdl/m4/libtool.m4
 +++ b/libltdl/m4/libtool.m4
 @@ -4324,12 +4324,17 @@ m4_if([$1], [CXX], [
 ;;
 *)
 case `$CC -V 21 | sed 5q` in
 -   *Sun\ F* | *Sun*Fortran*)
 +   *Sun\ Ceres\ Fortran* | *Sun*Fortran*\ [[1-7]].* | *Sun*Fortran*\ 
 8.[[0-3]]*)
   # Sun Fortran 8.3 passes all unrecognized flags to the linker
   _LT_TAGVAR(lt_prog_compiler_pic, $1)='-KPIC'
   _LT_TAGVAR(lt_prog_compiler_static, $1)='-Bstatic'
   _LT_TAGVAR(lt_prog_compiler_wl, $1)=''
   ;;
 +   *Sun\ F* | *Sun*Fortran*)
 + _LT_TAGVAR(lt_prog_compiler_pic, $1)='-KPIC'
 + _LT_TAGVAR(lt_prog_compiler_static, $1)='-Bstatic'
 + _LT_TAGVAR(lt_prog_compiler_wl, $1)='-Qoption ld '
 + ;;
 *Sun\ C*)
   # Sun C 5.9
   _LT_TAGVAR(lt_prog_compiler_pic, $1)='-KPIC'



Re: PATCH RFA: Add Go support

2010-12-19 Thread 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  i...@google.com

* libltdl/m4/libtool.m4 (LT_LANG): Add Go.
(AC_PROG_GO): Provide.
(_LT_SYS_HIDDEN_LIBDEPS): Add Go case.
(_LT_LANG_GO_CONFIG): Define.
(LT_PROG_GO): Define.
(AC_PROG_GO): Define if not defined.
* libltdl/config/ltmain.m4sh: Match *.go.
* doc/libtool.texi (LT_INIT): Mention Go.
(Tags): Mention Go.
* configure.ac: Enable Go.
* NEWS: Update.

diff --git a/NEWS b/NEWS
index 8d6965d..96c9723 100644
--- a/NEWS
+++ b/NEWS
@@ -8,6 +8,8 @@ New in 2.4.2 2010-12-??: git version 2.4.1a, Libtool team:
 package names.  This can be used to build some static libraries with PIC
 objects while building others with non-PIC objects.
 
+  - Initial support for Go, using the gccgo compiler.
+
 * Bug fixes:
 
   - The generic approximation of the command line length limit (when getconf is
diff --git a/configure.ac b/configure.ac
index 63ee8bf..0bad772 100644
--- a/configure.ac
+++ b/configure.ac
@@ -196,6 +196,7 @@ _LTDL_SETUP
 LT_LANG(C++)
 LT_LANG(Fortran 77)
 LT_LANG(Fortran)
+LT_LANG(Go)
 LT_LANG(Java)
 LT_LANG(Windows Resource)
 
diff --git a/doc/libtool.texi b/doc/libtool.texi
index 04c5507..4823ab8 100644
--- a/doc/libtool.texi
+++ b/doc/libtool.texi
@@ -2250,7 +2250,7 @@ specifying @option{--with-pic} to @command{configure}.
 @defmac LT_LANG (@var{language})
 Enable @command{libtool} support for the language given if it
 has not yet already been enabled.  Languages accepted are ``C++'',
-``Fortran 77'', ``Java'' and ``Windows Resource''.
+``Fortran 77'', ``Java'', ``Go'', and ``Windows Resource''.
 
 If Autoconf language support macros such as @code{AC_PROG_CXX} are
 used in your @file{configure.ac}, Libtool language support will automatically
@@ -2849,6 +2849,7 @@ correspondence between language names and tags names.
 @item Java @tab GCJ
 @item Fortran 77   @tab F77
 @item Fortran  @tab FC
+...@item Go   @tab GO
 @item Windows Resource @tab RC
 @end multitable
 
diff --git a/libltdl/config/ltmain.m4sh b/libltdl/config/ltmain.m4sh
index aff8a1c..8c37f88 100644
--- a/libltdl/config/ltmain.m4sh
+++ b/libltdl/config/ltmain.m4sh
@@ -1270,7 +1270,7 @@ func_mode_compile ()
 *.[cCFSifmso] | \
 *.ada | *.adb | *.ads | *.asm | \
 *.c++ | *.cc | *.ii | *.class | *.cpp | *.cxx | \
-*.[fF][09]? | *.for | *.java | *.obj | *.sx | *.cu | *.cup)
+*.[fF][09]? | *.for | *.java | *.go | *.obj | *.sx | *.cu | *.cup)
   func_xform $libobj
   libobj=$func_xform_result
   ;;
diff --git a/libltdl/m4/libtool.m4 b/libltdl/m4/libtool.m4
index 21b12fd..8e88917 100644
--- a/libltdl/m4/libtool.m4
+++ b/libltdl/m4/libtool.m4
@@ -803,6 +803,7 @@ AC_DEFUN([LT_LANG],
 m4_case([$1],
   [C], [_LT_LANG(C)],
   [C++],   [_LT_LANG(CXX)],
+  [Go],[_LT_LANG(GO)],
   [Java],  [_LT_LANG(GCJ)],
   [Fortran 77],[_LT_LANG(F77)],
   [Fortran],   [_LT_LANG(FC)],
@@ -824,6 +825,31 @@ m4_defun([_LT_LANG],
 ])# _LT_LANG
 
 
+m4_ifndef([AC_PROG_GO], [
+
+# NOTE: This macro has been submitted for inclusion into   #
+#  GNU Autoconf as AC_PROG_GO.  When it is available in#
+#  a released version of Autoconf we should remove this#
+#  macro and use it instead.   #
+
+m4_defun([AC_PROG_GO],
+[AC_LANG_PUSH(Go)dnl
+AC_ARG_VAR([GOC], [Go compiler command])dnl
+AC_ARG_VAR([GOFLAGS], [Go compiler flags])dnl
+_AC_ARG_VAR_LDFLAGS()dnl
+AC_CHECK_TOOL(GOC, gccgo)
+if test -z $GOC; then
+  if test -n $ac_tool_prefix; then
+AC_CHECK_PROG(GOC, [${ac_tool_prefix}gccgo], [${ac_tool_prefix}gccgo])
+  fi
+fi
+if test -z $GOC; then
+  AC_CHECK_PROG(GOC, gccgo, gccgo, false)
+fi
+])#m4_defun
+])#m4_ifndef
+
+
 # _LT_LANG_DEFAULT_CONFIG
 # ---
 m4_defun([_LT_LANG_DEFAULT_CONFIG],
@@ -854,6 +880,10 @@ AC_PROVIDE_IFELSE([AC_PROG_GCJ],
m4_ifdef([LT_PROG_GCJ],
[m4_define([LT_PROG_GCJ], defn([LT_PROG_GCJ])[LT_LANG(GCJ)])])])])])
 
+AC_PROVIDE_IFELSE([AC_PROG_GO],
+  [LT_LANG(GO)],
+  [m4_define([AC_PROG_GO], defn([AC_PROG_GO])[LT_LANG(GO)])])
+
 AC_PROVIDE_IFELSE([LT_PROG_RC],
   [LT_LANG(RC)],
   [m4_define([LT_PROG_RC], defn([LT_PROG_RC])[LT_LANG(RC)])])
@@ -6916,6 +6946,11 @@ public class foo {
   }
 };
 _LT_EOF
+], [$1], [GO], [cat  conftest.$ac_ext _LT_EOF
+package foo
+func foo() {
+}
+_LT_EOF
 ])
 
 _lt_libdeps_save_CFLAGS=$CFLAGS
@@ -7437,6 +7472,77 @@ CFLAGS=$lt_save_CFLAGS
 ])# _LT_LANG_GCJ_CONFIG
 
 
+# _LT_LANG_GO_CONFIG([TAG])
+# --
+# Ensure that the configuration 

Re: OS/2: command-line length limit

2010-12-19 Thread 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  k...@...  (tiny change)

Set command line length limit for OS/2.
* libltdl/m4/libtool.m4 (LT_CMD_MAX_LEN) [os2]
lt_cv_sys_max_cmd_len: Set to 8192 to avoid long test.

diff --git a/libltdl/m4/libtool.m4 b/libltdl/m4/libtool.m4
index a1df87d..5e716b2 100644
--- a/libltdl/m4/libtool.m4
+++ b/libltdl/m4/libtool.m4
@@ -1604,6 +1604,11 @@ AC_CACHE_VAL([lt_cv_sys_max_cmd_len], [dnl
 lt_cv_sys_max_cmd_len=196608
 ;;
 
+  os2*)
+# The test takes a long time on OS/2.
+lt_cv_sys_max_cmd_len=8192
+;;
+
   osf*)
 # Dr. Hans Ekkehard Plesser reports seeing a kernel panic running configure
 # due to this test when exec_disable_arg_limit is 1 on Tru64. It is not



Re: OS/2: command-line length limit

2010-12-18 Thread 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



[SCM] GNU Libtool branch, master, updated. v2.4-33-g92eb89a

2010-12-16 Thread Ralf Wildenhues
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project GNU Libtool.

The branch, master has been updated
   via  92eb89aace9fd41e43eee33f5c392adf1bcf8963 (commit)
  from  738f282ab18923b0dce5fd1abb3e6aa0d2ae499f (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -
commit 92eb89aace9fd41e43eee33f5c392adf1bcf8963
Author: Ralf Wildenhues ralf.wildenh...@gmx.de
Date:   Thu Dec 16 21:41:27 2010 +0100

Fix PIC flags with MPI wrappers using Portland on GNU/Linux.

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

Signed-off-by: Ralf Wildenhues ralf.wildenh...@gmx.de

---

Summary of changes:
 ChangeLog |6 ++
 libltdl/m4/libtool.m4 |5 +
 2 files changed, 11 insertions(+), 0 deletions(-)

diff --git a/ChangeLog b/ChangeLog
index 1dac768..cbb0262 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,5 +1,11 @@
 2010-12-16  Ralf Wildenhues  ralf.wildenh...@gmx.de
 
+   Fix PIC flags with MPI wrappers using Portland on GNU/Linux.
+   * libltdl/m4/libtool.m4 (_LT_COMPILER_PIC) [linux]:
+   Match Portland compilers also using $CC -V output, to avoid
+   false negatives with MPI compiler drivers.
+   Report by Christian Rössel.
+
* libltdl/m4/libtool.m4 (_LT_SETUP): Fix quoting for
PATH_SEPARATOR.
 
diff --git a/libltdl/m4/libtool.m4 b/libltdl/m4/libtool.m4
index 59114b4..62f9040 100644
--- a/libltdl/m4/libtool.m4
+++ b/libltdl/m4/libtool.m4
@@ -4340,6 +4340,11 @@ m4_if([$1], [CXX], [
  _LT_TAGVAR(lt_prog_compiler_static, $1)='-Bstatic'
  _LT_TAGVAR(lt_prog_compiler_wl, $1)='-Wl,'
  ;;
+   *Portland\ Group*)
+ _LT_TAGVAR(lt_prog_compiler_wl, $1)='-Wl,'
+ _LT_TAGVAR(lt_prog_compiler_pic, $1)='-fpic'
+ _LT_TAGVAR(lt_prog_compiler_static, $1)='-Bstatic'
+ ;;
esac
;;
   esac


hooks/post-receive
-- 
GNU Libtool



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

2010-12-16 Thread 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: PIC flags not found for mpif77(ifort)

2010-12-16 Thread 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



[SCM] GNU Libtool branch, master, updated. v2.4-31-g8c00e12

2010-12-15 Thread Ralf Wildenhues
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project GNU Libtool.

The branch, master has been updated
   via  8c00e12df8c8a1cc82e411779b2009e88bd203c2 (commit)
  from  82beb2a169ac1943df67be90675c3135ece03735 (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -
commit 8c00e12df8c8a1cc82e411779b2009e88bd203c2
Author: KO Myung-Hun k...@chollian.net
Date:   Wed Dec 15 22:29:17 2010 +0100

Fix PATH_SEPARATOR handling for OS/2.

* Makefile.am (update_mans): Quote $(PATH_SEPARATOR).
* libltdl/m4/libtool.m4 (_LT_SETUP): Add _LT_DECL for
PATH_SEPARATOR.
* libltdl/config/general.m4sh: Use PATH_SEPARATOR when computing
$progpath.
* THANKS: Update.

---

Summary of changes:
 ChangeLog   |   11 +++
 Makefile.am |2 +-
 THANKS  |1 +
 libltdl/config/general.m4sh |2 +-
 libltdl/m4/libtool.m4   |2 ++
 5 files changed, 16 insertions(+), 2 deletions(-)

diff --git a/ChangeLog b/ChangeLog
index 8bc122e..0d49595 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,14 @@
+2010-12-15  KO Myung-Hun  k...@chollian.net  (tiny change)
+   Ralf Wildenhues  ralf.wildenh...@gmx.de
+
+   Fix PATH_SEPARATOR handling for OS/2.
+   * Makefile.am (update_mans): Quote $(PATH_SEPARATOR).
+   * libltdl/m4/libtool.m4 (_LT_SETUP): Add _LT_DECL for
+   PATH_SEPARATOR.
+   * libltdl/config/general.m4sh: Use PATH_SEPARATOR when computing
+   $progpath.
+   * THANKS: Update.
+
 2010-12-10  Ralf Wildenhues  ralf.wildenh...@gmx.de
 
Fix nvcc PIC setting on darwin.
diff --git a/Makefile.am b/Makefile.am
index 66f38b1..4be353c 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -330,7 +330,7 @@ $(srcdir)/doc/notes.txt: $(srcdir)/doc/notes.texi
 dist_man1_MANS = $(srcdir)/doc/libtool.1 $(srcdir)/doc/libtoolize.1
 MAINTAINERCLEANFILES   += $(dist_man1_MANS)
 update_mans = \
-  PATH=.$(PATH_SEPARATOR)$$PATH; export PATH; \
+  PATH=.$(PATH_SEPARATOR)$$PATH; export PATH; \
   $(HELP2MAN) --output=$@
 $(srcdir)/doc/libtool.1: $(srcdir)/$(auxdir)/ltmain.sh
$(update_mans) --help-option=--help-all libtool
diff --git a/THANKS b/THANKS
index 6dd8dd8..5260878 100644
--- a/THANKS
+++ b/THANKS
@@ -122,6 +122,7 @@
   Kenneth Albanowski   kja...@kjahds.com
   Kevin Ryde   use...@zip.com.au
   Khem Raj  raj.k...@gmail.com
+  KO Myung-Hun k...@chollian.net
   Kurt D. Zeilenga k...@openldap.org
   Lennart Poettering   lenn...@poettering.net
   Lionel Landwerlin llandwer...@gmail.com
diff --git a/libltdl/config/general.m4sh b/libltdl/config/general.m4sh
index 44a7ce9..40d5413 100644
--- a/libltdl/config/general.m4sh
+++ b/libltdl/config/general.m4sh
@@ -296,7 +296,7 @@ case $progpath in
  ;;
   *)
  save_IFS=$IFS
- IFS=:
+ IFS=${PATH_SEPARATOR-:}
  for progdir in $PATH; do
IFS=$save_IFS
test -x $progdir/$progname  break
diff --git a/libltdl/m4/libtool.m4 b/libltdl/m4/libtool.m4
index 1f61140..ab3e16f 100644
--- a/libltdl/m4/libtool.m4
+++ b/libltdl/m4/libtool.m4
@@ -146,6 +146,8 @@ AC_REQUIRE([AC_CANONICAL_BUILD])dnl
 AC_REQUIRE([_LT_PREPARE_SED_QUOTE_VARS])dnl
 AC_REQUIRE([_LT_PROG_ECHO_BACKSLASH])dnl
 
+_LT_DECL([], [PATH_SEPARATOR], [0], [The PATH separator for the build 
system])dnl
+dnl
 _LT_DECL([], [host_alias], [0], [The host system])dnl
 _LT_DECL([], [host], [0])dnl
 _LT_DECL([], [host_os], [0])dnl


hooks/post-receive
-- 
GNU Libtool



Re: PIC flags not found for mpif77(ifort)

2010-12-15 Thread 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: Enhanced OS/2 port

2010-12-15 Thread 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 k...@chollian.net  (tiny change)
Ralf Wildenhues  ralf.wildenh...@gmx.de

Fix PATH_SEPARATOR handling for OS/2.
* Makefile.am (update_mans): Quote $(PATH_SEPARATOR).
* libltdl/m4/libtool.m4 (_LT_SETUP): Add _LT_DECL for
PATH_SEPARATOR.
* libltdl/config/general.m4sh: Use PATH_SEPARATOR when computing
$progpath.
* THANKS: Update.

diff --git a/Makefile.am b/Makefile.am
index 66f38b1..4be353c 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -330,7 +330,7 @@ $(srcdir)/doc/notes.txt: $(srcdir)/doc/notes.texi
 dist_man1_MANS = $(srcdir)/doc/libtool.1 $(srcdir)/doc/libtoolize.1
 MAINTAINERCLEANFILES   += $(dist_man1_MANS)
 update_mans = \
-  PATH=.$(PATH_SEPARATOR)$$PATH; export PATH; \
+  PATH=.$(PATH_SEPARATOR)$$PATH; export PATH; \
   $(HELP2MAN) --output=$@
 $(srcdir)/doc/libtool.1: $(srcdir)/$(auxdir)/ltmain.sh
$(update_mans) --help-option=--help-all libtool
diff --git a/libltdl/config/general.m4sh b/libltdl/config/general.m4sh
index 44a7ce9..40d5413 100644
--- a/libltdl/config/general.m4sh
+++ b/libltdl/config/general.m4sh
@@ -296,7 +296,7 @@ case $progpath in
  ;;
   *)
  save_IFS=$IFS
- IFS=:
+ IFS=${PATH_SEPARATOR-:}
  for progdir in $PATH; do
IFS=$save_IFS
test -x $progdir/$progname  break
diff --git a/libltdl/m4/libtool.m4 b/libltdl/m4/libtool.m4
index 1f61140..ab3e16f 100644
--- a/libltdl/m4/libtool.m4
+++ b/libltdl/m4/libtool.m4
@@ -146,6 +146,8 @@ AC_REQUIRE([AC_CANONICAL_BUILD])dnl
 AC_REQUIRE([_LT_PREPARE_SED_QUOTE_VARS])dnl
 AC_REQUIRE([_LT_PROG_ECHO_BACKSLASH])dnl
 
+_LT_DECL([], [PATH_SEPARATOR], [0], [The PATH separator for the build 
system])dnl
+dnl
 _LT_DECL([], [host_alias], [0], [The host system])dnl
 _LT_DECL([], [host], [0])dnl
 _LT_DECL([], [host_os], [0])dnl




 @@ -564,6 +567,10 @@

(in func_show_eval)

  my_cmd=$1
  my_fail_exp=${2-:}
 
 +# pdksh 5.2.14-bin-2 for OS/2 does not remove trailing CR
 +# when a line length is 1022. Maybe 1022 is a magic number ?
 +my_cmd=`$ECHO $my_cmd | $SED s/\r$//`

Ouch.  Where did you hit this?  Can't you fix pdksh instead?
This change unconditionally costs two forks and one exec on almost every
command that libtool issues.  Also, \r is not a portable sed regex.

Does something like this work instead?

   # pdksh 5.2.14-bin-2 for OS/2 does not remove trailing CR
   # when a line length is 1022.
   case $my_cmd in *$'\r')
 my_cmd=`$ECHO $my_cmd | $SED s/\r$//` ;;
   esac

What about this?
   cr=$'\r'
   case $my_cmd in *$cr)
 my_cmd=`$ECHO $my_cmd | $SED s/\r$//` ;;
   esac

Then we still need to factor setting of $cr, but at least it's not quite
so expensive on other systems.

  ${opt_silent-false

Re: Enhanced OS/2 port

2010-12-15 Thread 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: PIC flags not found for mpif77(ifort)

2010-12-15 Thread 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

___
http://lists.gnu.org/mailman/listinfo/libtool


Re: Enhanced OS/2 port

2010-12-15 Thread 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 k...@chollian.net  (tiny change)
Ralf Wildenhues  ralf.wildenh...@gmx.de

Fix PATH_SEPARATOR handling for OS/2.
* Makefile.am (update_mans): Quote $(PATH_SEPARATOR).
* libltdl/m4/libtool.m4 (_LT_SETUP): Add _LT_DECL for
PATH_SEPARATOR.
* libltdl/config/general.m4sh: Use PATH_SEPARATOR when computing
$progpath.
* THANKS: Update.

diff --git a/Makefile.am b/Makefile.am
index 66f38b1..4be353c 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -330,7 +330,7 @@ $(srcdir)/doc/notes.txt: $(srcdir)/doc/notes.texi
 dist_man1_MANS = $(srcdir)/doc/libtool.1 $(srcdir)/doc/libtoolize.1
 MAINTAINERCLEANFILES   += $(dist_man1_MANS)
 update_mans = \
-  PATH=.$(PATH_SEPARATOR)$$PATH; export PATH; \
+  PATH=.$(PATH_SEPARATOR)$$PATH; export PATH; \
   $(HELP2MAN) --output=$@
 $(srcdir)/doc/libtool.1: $(srcdir)/$(auxdir)/ltmain.sh
$(update_mans) --help-option=--help-all libtool
diff --git a/libltdl/config/general.m4sh b/libltdl/config/general.m4sh
index 44a7ce9..40d5413 100644
--- a/libltdl/config/general.m4sh
+++ b/libltdl/config/general.m4sh
@@ -296,7 +296,7 @@ case $progpath in
  ;;
   *)
  save_IFS=$IFS
- IFS=:
+ IFS=${PATH_SEPARATOR-:}
  for progdir in $PATH; do
IFS=$save_IFS
test -x $progdir/$progname  break
diff --git a/libltdl/m4/libtool.m4 b/libltdl/m4/libtool.m4
index 1f61140..ab3e16f 100644
--- a/libltdl/m4/libtool.m4
+++ b/libltdl/m4/libtool.m4
@@ -146,6 +146,8 @@ AC_REQUIRE([AC_CANONICAL_BUILD])dnl
 AC_REQUIRE([_LT_PREPARE_SED_QUOTE_VARS])dnl
 AC_REQUIRE([_LT_PROG_ECHO_BACKSLASH])dnl
 
+_LT_DECL([], [PATH_SEPARATOR], [0], [The PATH separator for the build 
system])dnl
+dnl
 _LT_DECL([], [host_alias], [0], [The host system])dnl
 _LT_DECL([], [host], [0])dnl
 _LT_DECL([], [host_os], [0])dnl




 @@ -564,6 +567,10 @@

(in func_show_eval)

  my_cmd=$1
  my_fail_exp=${2-:}
 
 +# pdksh 5.2.14-bin-2 for OS/2 does not remove trailing CR
 +# when a line length is 1022. Maybe 1022 is a magic number ?
 +my_cmd=`$ECHO $my_cmd | $SED s/\r$//`

Ouch.  Where did you hit this?  Can't you fix pdksh instead?
This change unconditionally costs two forks and one exec on almost every
command that libtool issues.  Also, \r is not a portable sed regex.

Does something like this work instead?

   # pdksh 5.2.14-bin-2 for OS/2 does not remove trailing CR
   # when a line length is 1022.
   case $my_cmd in *$'\r')
 my_cmd=`$ECHO $my_cmd | $SED s/\r$//` ;;
   esac

What about this?
   cr=$'\r'
   case $my_cmd in *$cr)
 my_cmd=`$ECHO $my_cmd | $SED s/\r$//` ;;
   esac

Then we still need to factor setting of $cr, but at least it's not quite
so expensive on other systems.

  ${opt_silent-false

Re: PIC flags not found for mpif77(ifort)

2010-12-10 Thread 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

___
http://lists.gnu.org/mailman/listinfo/libtool


Re: Unwanted shared runtime libraries getting added

2010-12-10 Thread Ralf Wildenhues
* Ethan Mallove wrote on Fri, Dec 10, 2010 at 07:41:20PM CET:
 On Thu, Oct/21/2010 06:13:03AM, Ralf Wildenhues wrote:
  Pass -Wc,-static-intel instead.
 
 This works like a charm for shared libraries, but for standalone
 executables I get an error like this:
 
   ...
   icc: command line warning #10156: ignoring option '-W'; no argument required
   /bin/sh ../../../libtool  --tag=CC   --mode=link icc  -Wc,-static-intel -g 
 -finline-functions -fno-strict-aliasing -restrict -pthread 
 -fvisibility=hidden  -export-dynamic   -o orte-iof orte-iof.o 
 ../../../orte/libopen-rte.la -lnsl  -lutil
   libtool: link: icc -Wl,-static-intel -g -finline-functions 
 -fno-strict-aliasing -restrict -pthread -fvisibility=hidden -o .libs/orte-iof 
 orte-iof.o -Wl,--export-dynamic  ../../../orte/.libs/libopen-rte.so -ldl 
 -lnsl -lutil -pthread -Wl,-rpath -Wl,$ORIGIN -Wl,-rpath -Wl,$ORIGIN/.. 
 -Wl,-rpath -Wl,$ORIGIN/../lib
   ipo: warning #11015: Warning unknown option -static-intel
   ld: unrecognized -a option `tic-intel'
 
 Do you know of a way to get this working in both cases: shared libs
 and standalone executable?

Yes.  Use Libtool 2.2.8 or newer.  Quoting from the NEWS file:

  - Fix ancient bug where -Wc, was turned into $wl (typically -Wl,)
when using the compiler driver to link programs. Now -Wc, is stripped
just as it is when linking libraries through the compiler driver.

Cheers,
Ralf

___
http://lists.gnu.org/mailman/listinfo/libtool


[SCM] GNU Libtool branch, master, updated. v2.4-30-g82beb2a

2010-12-09 Thread Ralf Wildenhues
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project GNU Libtool.

The branch, master has been updated
   via  82beb2a169ac1943df67be90675c3135ece03735 (commit)
   via  1c9aa6dac54372220d367715bf891a6f06c668fd (commit)
   via  cc027148f2acded5c1a2bd5c951ef70fb3223a50 (commit)
  from  4fee8796c92a2ab554eb6596330ac06613c22807 (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -
commit 82beb2a169ac1943df67be90675c3135ece03735
Author: Ralf Wildenhues ralf.wildenh...@gmx.de
Date:   Mon Dec 6 04:31:14 2010 +0100

Fix nvcc PIC setting on darwin.

* libltdl/m4/libtool.m4 (_LT_COMPILER_PIC)
lt_prog_compiler_pic: Prepend -Xcompiler to nonempty variable
setting rather than hard-coding -Xcompiler -fPIC, for darwin.
* NEWS, THANKS: Update.
Report by Paweł Daniluk.

Signed-off-by: Ralf Wildenhues ralf.wildenh...@gmx.de

commit 1c9aa6dac54372220d367715bf891a6f06c668fd
Author: Ralf Wildenhues ralf.wildenh...@gmx.de
Date:   Sat Nov 20 10:34:16 2010 +0100

Honor $AUTOCONF, $AUTOMAKE in --help output.

* libltdl/config/getopt.m4sh (func_help): Use $AUTOCONF and
$AUTOMAKE if set, for --version outout.

Signed-off-by: Ralf Wildenhues ralf.wildenh...@gmx.de

commit cc027148f2acded5c1a2bd5c951ef70fb3223a50
Author: Ralf Wildenhues ralf.wildenh...@gmx.de
Date:   Fri Nov 19 18:42:04 2010 +0100

docs: Libtool configuration diagram.

* doc/libtool.texi (Integrating libtool): Add diagrams
explaining the dependencies between Libtool files.
Suggestion by Ethan Mallove.

Signed-off-by: Ralf Wildenhues ralf.wildenh...@gmx.de

---

Summary of changes:
 ChangeLog  |   18 +++
 NEWS   |1 +
 THANKS |1 +
 doc/libtool.texi   |   50 
 libltdl/config/getopt.m4sh |4 +-
 libltdl/m4/libtool.m4  |4 ++-
 6 files changed, 75 insertions(+), 3 deletions(-)

diff --git a/ChangeLog b/ChangeLog
index e418f3c..8bc122e 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,21 @@
+2010-12-10  Ralf Wildenhues  ralf.wildenh...@gmx.de
+
+   Fix nvcc PIC setting on darwin.
+   * libltdl/m4/libtool.m4 (_LT_COMPILER_PIC)
+   lt_prog_compiler_pic: Prepend -Xcompiler to nonempty variable
+   setting rather than hard-coding -Xcompiler -fPIC, for darwin.
+   * NEWS, THANKS: Update.
+   Report by Paweł Daniluk.
+
+   Honor $AUTOCONF, $AUTOMAKE in --help output.
+   * libltdl/config/getopt.m4sh (func_help): Use $AUTOCONF and
+   $AUTOMAKE if set, for --version outout.
+
+   docs: Libtool configuration diagram.
+   * doc/libtool.texi (Integrating libtool): Add diagrams
+   explaining the dependencies between Libtool files.
+   Suggestion by Ethan Mallove.
+
 2010-11-15  Ralf Wildenhues  ralf.wildenh...@gmx.de
 
Eliminate hardcode_libdir_flag_spec_ld tag variable.
diff --git a/NEWS b/NEWS
index 83cee5e..0aeca57 100644
--- a/NEWS
+++ b/NEWS
@@ -14,6 +14,7 @@ New in 2.4.2 2010-12-??: git version 2.4.1a, Libtool team:
 not available) works again.  Regression introduced in v2.2.6-39-g9c3d4d8.
   - The bug that leaked developer tool paths into the release tarballs
 from ./bootstrap is fixed.
+  - Improved support for the Cuda Compiler Driver (nvcc) on Darwin.
 
 * Important incompatible changes:
 
diff --git a/THANKS b/THANKS
index e85e21a..6dd8dd8 100644
--- a/THANKS
+++ b/THANKS
@@ -147,6 +147,7 @@
   Paul Biggar  paul.big...@gmail.com
   Paul Eggert  egg...@twinsun.com
   Paul Laight  plai...@quantxautomation.co.uk
+  Paweł Daniluk   pa...@bioexploratorium.pl
   Peter Eisentraut pete...@gmx.net
   Peter Fritzsche  peter.fritzs...@gmx.de
   Peter Jeremy peterjer...@optushome.com.au
diff --git a/doc/libtool.texi b/doc/libtool.texi
index 12d006b..04c5507 100644
--- a/doc/libtool.texi
+++ b/doc/libtool.texi
@@ -1791,6 +1791,56 @@ The remaining @var{mode-args} are either flags for the 
deletion program
 This chapter describes how to integrate libtool with your packages so
 that your users can install hassle-free shared libraries.
 
+There are several ways in which Libtool may be integrated in your
+package, described in the following sections.  Typically, the Libtool
+macro files as well as @file{ltmain.sh} are copied into your package
+using @command{libtoolize} and @command{aclocal} after setting up the
+...@file{configure.ac} and toplevel @file{Makefile.am}, then
+...@command{autoconf} adds the needed tests

Re: Libtool and CUDA

2010-12-09 Thread 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: docs: Libtool configuration diagram.

2010-12-09 Thread 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 --help: honor $AUTOCONF, $AUTOMAKE

2010-12-09 Thread 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: Libtool and CUDA

2010-12-09 Thread 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

___
http://lists.gnu.org/mailman/listinfo/libtool


Re: Libtool and CUDA

2010-12-06 Thread 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: Libtools for Win7-64

2010-12-06 Thread Ralf Wildenhues
* Arbol One wrote on Mon, Dec 06, 2010 at 02:57:16PM CET:
 Having stated the above and on another front, I would like to know if you
 can direct me to a place where I can download libtools-64bit.

Well, you can just download Libtool 2.4 from
http://ftp.gnu.org/gnu/libtool, extract and build it on your systems.
Whichever systems that are.  If you hit one that we don't support (yet),
come back and complain.  We will then work with you to add support for
that system as well.

We support everything!  ;-)

Cheers,
Ralf

___
http://lists.gnu.org/mailman/listinfo/libtool


Re: Libtool and CUDA

2010-12-06 Thread 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

___
http://lists.gnu.org/mailman/listinfo/libtool


Re: Libtool and CUDA

2010-12-06 Thread Ralf Wildenhues
* Paweł Daniluk wrote on Mon, Dec 06, 2010 at 11:52:00AM CET:
 Thanks for your prompt reply. Unfortunately the patch doesn't seem
 to change anything. Perhaps I'm doing something completely wrong. I
 expect that libtool after invoking in compile mode with nvcc instead
 of gcc should add -Xcompiler where needed, but I get:

 I have always treated libtool as a black box which just works, and
 know very little about its internals. Nevertheless libtool doesn't
 seem to depend on any external files, and contains no nvcc string.
 Maybe I miss something during the compilation phase.

Right.  You need to configure Libtool with CC=nvcc for it to work right
for nvcc.

One alternative is to integrate Libtool in your own (autoconf-using)
package; see 'info libtool Integrating libtool' for more information.

Cheers,
Ralf

___
http://lists.gnu.org/mailman/listinfo/libtool


Re: Oracle Solaris Studio 12.2 compiler incompatibility with libtool

2010-12-05 Thread 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]
   lt_prog_compiler_wl: Set to '-Qoption ld ' if we
   detect Sun Fortran version 8.4 or newer.
   Report by Terry Dontje.
 
 diff --git a/libltdl/m4/libtool.m4 b/libltdl/m4/libtool.m4
 index 419ffe1..4a371c9 100644
 --- a/libltdl/m4/libtool.m4
 +++ b/libltdl/m4/libtool.m4
 @@ -4324,12 +4324,17 @@ m4_if([$1], [CXX], [
   ;;
*)
   case `$CC -V 21 | sed 5q` in
 - *Sun\ F* | *Sun*Fortran*)
 + *Sun\ Ceres\ Fortran* | *Sun*Fortran*\ [[1-7]].* | *Sun*Fortran*\ 
 8.[[0-3]]*)
 # Sun Fortran 8.3 passes all unrecognized flags to the linker
 _LT_TAGVAR(lt_prog_compiler_pic, $1)='-KPIC'
 _LT_TAGVAR(lt_prog_compiler_static, $1)='-Bstatic'
 _LT_TAGVAR(lt_prog_compiler_wl, $1)=''
 ;;
 + *Sun\ F* | *Sun*Fortran*)
 +   _LT_TAGVAR(lt_prog_compiler_pic, $1)='-KPIC'
 +   _LT_TAGVAR(lt_prog_compiler_static, $1)='-Bstatic'
 +   _LT_TAGVAR(lt_prog_compiler_wl, $1)='-Qoption ld '
 +   ;;
   *Sun\ C*)
 # Sun C 5.9
 _LT_TAGVAR(lt_prog_compiler_pic, $1)='-KPIC'



Re: Libtool and CUDA

2010-12-05 Thread 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)
lt_prog_compiler_pic: Prepend -Xcompiler to nonempty variable
setting rather than hard-coding -Xcompiler -fPIC, for darwin.
* NEWS, THANKS: Update.
Report by Paweł Daniluk.

diff --git a/NEWS b/NEWS
index 1679c58..d8fc3ea 100644
--- a/NEWS
+++ b/NEWS
@@ -18,6 +18,7 @@ New in 2.4.2 2010-12-??: git version 2.4.1a, Libtool team:
 not available) works again.  Regression introduced in v2.2.6-39-g9c3d4d8.
   - The bug that leaked developer tool paths into the release tarballs
 from ./bootstrap is fixed.
+  - Improved support for the Cuda Compiler Driver (nvcc) on Darwin.
 
 * Important incompatible changes:
 
diff --git a/libltdl/m4/libtool.m4 b/libltdl/m4/libtool.m4
index 99d66bb..5f18dcb 100644
--- a/libltdl/m4/libtool.m4
+++ b/libltdl/m4/libtool.m4
@@ -4240,7 +4240,9 @@ m4_if([$1], [CXX], [
 case $cc_basename in
 nvcc*) # Cuda Compiler Driver 2.2
   _LT_TAGVAR(lt_prog_compiler_wl, $1)='-Xlinker '
-  _LT_TAGVAR(lt_prog_compiler_pic, $1)='-Xcompiler -fPIC'
+  if test -n $_LT_TAGVAR(lt_prog_compiler_pic, $1); then
+_LT_TAGVAR(lt_prog_compiler_pic, $1)=-Xcompiler 
$_LT_TAGVAR(lt_prog_compiler_pic, $1)
+  fi
   ;;
 esac
   else



Re: Libtool and CUDA

2010-12-05 Thread 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: ld: fatal: file .libs/libglib-2.0.exp: unknown file type

2010-12-05 Thread Ralf Wildenhues
* Laviticus Stone wrote on Thu, Dec 02, 2010 at 08:53:40AM CET:
 On 12/ 2/10 02:37 AM, Ralf Wildenhues wrote:
 * Laviticus Stone wrote on Thu, Dec 02, 2010 at 01:45:04AM CET:
 Hi, i'm trying to compile glib-2.0 on Solaris 11 from netbsd pkgsrc.
 Libtool creates the following command and results:

 ld: fatal: file .libs/libglib-2.0.exp: unknown file type
 ld: fatal: file processing errors. No output written to
 .libs/libglib-2.0.so.0.2600.1
 collect2: ld returned 1 exit status
 
 Somehow libtool seems to think you're using GNU ld but apparently you're
 not.  Please send output of
./libtool --version
./libtool --config

 Ah yes, netbsd's pkgsrc is configured for
 LD=ld
 
 I imagine it was finding gnu lsd, which was in the search path, and
 assumign gnu ld, yet the gcc command it was issuing was using the
 solaris ld in /usr/ccs/bin.
 
 
 ps up to date pkgsrc is ltmain.sh (GNU libtool) 2.2.6b

So I gather you can fix/work around your issues by installing a local
Libtool, rebuilding the pkgsrc one with an absolute LD=/path/to/ld as
configure argument, or by adjusting your PATH to find the ld that was
found at the time the pkgsrc Libtool was built.  Right?

Thanks,
Ralf

___
http://lists.gnu.org/mailman/listinfo/libtool


Re: Libtools for Win7-64

2010-12-05 Thread Ralf Wildenhues
Hello Arbol,

* Arbol One wrote on Sun, Dec 05, 2010 at 11:47:51PM CET:
 
 Does anyone know if there is a libtool's port to Win7-64.

First off, welcome to this list.  Please do not top-post nor full-quote
here, also please do not reply to existing threads with new topics;
rather, start a new thread for a new topic, and keep on a thread for an
existing one.  Thank you.

Libtool has been ported to work on MinGW-w64, if that's what you mean.
As far as I know, MinGW-w64 works on Win7.  So yes, Libtool should work
on Win7-64 already.  But maybe you mean to run it in Cygwin; that also
should work on 64bit Windows.

Cheers,
Ralf

___
http://lists.gnu.org/mailman/listinfo/libtool


Re: Libtool and CUDA

2010-12-05 Thread 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)
lt_prog_compiler_pic: Prepend -Xcompiler to nonempty variable
setting rather than hard-coding -Xcompiler -fPIC, for darwin.
* NEWS, THANKS: Update.
Report by Paweł Daniluk.

diff --git a/NEWS b/NEWS
index 1679c58..d8fc3ea 100644
--- a/NEWS
+++ b/NEWS
@@ -18,6 +18,7 @@ New in 2.4.2 2010-12-??: git version 2.4.1a, Libtool team:
 not available) works again.  Regression introduced in v2.2.6-39-g9c3d4d8.
   - The bug that leaked developer tool paths into the release tarballs
 from ./bootstrap is fixed.
+  - Improved support for the Cuda Compiler Driver (nvcc) on Darwin.
 
 * Important incompatible changes:
 
diff --git a/libltdl/m4/libtool.m4 b/libltdl/m4/libtool.m4
index 99d66bb..5f18dcb 100644
--- a/libltdl/m4/libtool.m4
+++ b/libltdl/m4/libtool.m4
@@ -4240,7 +4240,9 @@ m4_if([$1], [CXX], [
 case $cc_basename in
 nvcc*) # Cuda Compiler Driver 2.2
   _LT_TAGVAR(lt_prog_compiler_wl, $1)='-Xlinker '
-  _LT_TAGVAR(lt_prog_compiler_pic, $1)='-Xcompiler -fPIC'
+  if test -n $_LT_TAGVAR(lt_prog_compiler_pic, $1); then
+_LT_TAGVAR(lt_prog_compiler_pic, $1)=-Xcompiler 
$_LT_TAGVAR(lt_prog_compiler_pic, $1)
+  fi
   ;;
 esac
   else

___
http://lists.gnu.org/mailman/listinfo/libtool


Re: Libtool and CUDA

2010-12-05 Thread 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

___
http://lists.gnu.org/mailman/listinfo/libtool


Re: Version mismatch error

2010-12-03 Thread Ralf Wildenhues
Hello Dan,

* Dan Nicholson wrote on Fri, Dec 03, 2010 at 02:43:04PM CET:
 On Wed, Oct 20, 2010 at 10:49 AM, Ralf Wildenhues wrote:
  Depending on your package setup, that means either passing --install to
  libtoolize (when AC_CONFIG_MACRO_DIR has been set in configure.ac), or
  running aclocal with flags set so that it finds the right Libtool macros
  (either by some -I include-path, or setting the path in the dirlist file
  of the aclocal installation), or possibly hand-copying macro files or
  file contents to your aclocal.m4 file.  Details are documented in the
  manual.

 It would nice if libtoolize when run without --install (e.g. when run
 by autoreconf without --install) would detect that ltmain.sh and
 libtool.m4 are out of sync and error. One of the most common autotools
 errors I see is that people run bare autoreconf and things break
 strangely (to them) some time later. What do you think?

If we can do a warning or error reliably, then I'm all for it.
I don't think it can be done in libtoolize though, because aclocal may
be called afterwards and fix things up.  autoreconf might call
libtoolize with some special --check argument or so, to tell it that
aclocal --install won't be called afterwards.  Putting the warning into
automake seems possible but an ugly hack.  We could put a check into
autoreconf, but then non-autoreconf users wouldn't get the extra safety.

It's not easy.  :-/

Cheers,
Ralf

___
http://lists.gnu.org/mailman/listinfo/libtool


Re: Enhanced OS/2 port

2010-12-01 Thread Ralf Wildenhues
Hello,

* KO Myung-Hun wrote on Wed, Dec 01, 2010 at 09:24:56AM CET:
  I've enhanced and fixed libtool 2.4 for OS/2.
  
  Review, please.

 Ping ?

Thanks for your patch, and sorry for the delay.  I'm very busy ATM but I
will try to review it by next week.  It needs some more work.  Also,
patches should generally be sent to the libtool-patches list.

Thanks,
Ralf

___
http://lists.gnu.org/mailman/listinfo/libtool


Re: ld: fatal: file .libs/libglib-2.0.exp: unknown file type

2010-12-01 Thread Ralf Wildenhues
Hello Laviticus,

* Laviticus Stone wrote on Thu, Dec 02, 2010 at 01:45:04AM CET:
 Hi, i'm trying to compile glib-2.0 on Solaris 11 from netbsd pkgsrc.
 Libtool creates the following command and results:
 
 gcc -shared  .libs/garray.o .libs/gasyncqueue.o .libs/gatomic.o
[...]
 .libs/giounix.o .libs/gspawn.o  -Wl,--whole-archive
 libcharset/.libs/libcharset.a -Wl,--no-whole-archive  -Wl,-rpath
 -Wl,/usr/pkgsrc/devel/glib2/work/.buildlink/lib -Wl,-rpath
 -Wl,/usr/pkgsrc/devel/glib2/work/.buildlink/lib
 -L/usr/pkgsrc/devel/glib2/work/.buildlink/lib
 /usr/pkgsrc/devel/glib2/work/.buildlink/lib/libpcre.so
 /usr/pkgsrc/devel/glib2/work/.buildlink/lib/libintl.so
 /usr/pkgsrc/devel/glib2/work/.buildlink/lib/libiconv.so -lc -lnsl
 -lsocket -lc  -Wl,-R/usr/pkg/lib   -Wl,-soname -Wl,libglib-2.0.so.0
 -Wl,-retain-symbols-file -Wl,.libs/libglib-2.0.exp -o
 .libs/libglib-2.0.so.0.2600.1
 ld: fatal: file .libs/libglib-2.0.exp: unknown file type
 ld: fatal: file processing errors. No output written to
 .libs/libglib-2.0.so.0.2600.1
 collect2: ld returned 1 exit status

Somehow libtool seems to think you're using GNU ld but apparently you're
not.  Please send output of
  ./libtool --version
  ./libtool --config

Thanks,
Ralf

___
http://lists.gnu.org/mailman/listinfo/libtool


docs: Libtool configuration diagram.

2010-11-20 Thread 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: Oracle Solaris Studio 12.2 compiler incompatibility with libtool

2010-11-18 Thread 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  ralf.wildenh...@gmx.de

Fix $wl setting for Solaris Studio 12.2 f90 on GNU/Linux.
* libltdl/m4/libtool.m4 (_LT_COMPILER_PIC) [linux]
lt_prog_compiler_wl: Set to '-Qoption ld ' if we
detect Sun Fortran version 8.4 or newer.
Report by Terry Dontje.

diff --git a/libltdl/m4/libtool.m4 b/libltdl/m4/libtool.m4
index 419ffe1..4a371c9 100644
--- a/libltdl/m4/libtool.m4
+++ b/libltdl/m4/libtool.m4
@@ -4324,12 +4324,17 @@ m4_if([$1], [CXX], [
;;
   *)
case `$CC -V 21 | sed 5q` in
-   *Sun\ F* | *Sun*Fortran*)
+   *Sun\ Ceres\ Fortran* | *Sun*Fortran*\ [[1-7]].* | *Sun*Fortran*\ 
8.[[0-3]]*)
  # Sun Fortran 8.3 passes all unrecognized flags to the linker
  _LT_TAGVAR(lt_prog_compiler_pic, $1)='-KPIC'
  _LT_TAGVAR(lt_prog_compiler_static, $1)='-Bstatic'
  _LT_TAGVAR(lt_prog_compiler_wl, $1)=''
  ;;
+   *Sun\ F* | *Sun*Fortran*)
+ _LT_TAGVAR(lt_prog_compiler_pic, $1)='-KPIC'
+ _LT_TAGVAR(lt_prog_compiler_static, $1)='-Bstatic'
+ _LT_TAGVAR(lt_prog_compiler_wl, $1)='-Qoption ld '
+ ;;
*Sun\ C*)
  # Sun C 5.9
  _LT_TAGVAR(lt_prog_compiler_pic, $1)='-KPIC'



[SCM] GNU Libtool branch, master, updated. v2.4-27-g4fee879

2010-11-15 Thread Ralf Wildenhues
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project GNU Libtool.

The branch, master has been updated
   via  4fee8796c92a2ab554eb6596330ac06613c22807 (commit)
  from  8eb036bb129a5673dd6ada62075588424edf319a (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -
commit 4fee8796c92a2ab554eb6596330ac06613c22807
Author: Ralf Wildenhues ralf.wildenh...@gmx.de
Date:   Mon Nov 15 23:13:33 2010 +0100

Eliminate hardcode_libdir_flag_spec_ld tag variable.

* libltdl/config/ltmain.m4sh (func_mode_link): Set $wl to empty
if $LD is used for creating shared libraries.  Do not use
hardcode_libdir_flag_spec_ld any more.
* libltdl/m4/libtool.m4 (_LT_LINKER_SHLIBS, _LT_LANG_CXX_CONFIG)
(_LT_LANG_F77_CONFIG, _LT_LANG_FC_CONFIG, _LT_SYS_DYNAMIC_LINKER)
hardcode_libdir_flag_spec_ld: Remove all instances of the tag
variable.
(_LT_LINKER_SHLIBS) [linux, xlf] hardcode_libdir_flag_spec:
Set variable, including ${wl}.  Fixes hardcoding in programs
created by XL Fortran on GNU/Linux.
* NEWS, THANKS: Update.
Report by Paul H. Hargrove.

Signed-off-by: Ralf Wildenhues ralf.wildenh...@gmx.de

---

Summary of changes:
 ChangeLog  |   14 ++
 NEWS   |9 +
 libltdl/config/ltmain.m4sh |   11 ++-
 libltdl/m4/libtool.m4  |   11 +--
 4 files changed, 30 insertions(+), 15 deletions(-)

diff --git a/ChangeLog b/ChangeLog
index 89b2d52..e418f3c 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,5 +1,19 @@
 2010-11-15  Ralf Wildenhues  ralf.wildenh...@gmx.de
 
+   Eliminate hardcode_libdir_flag_spec_ld tag variable.
+   * libltdl/config/ltmain.m4sh (func_mode_link): Set $wl to empty
+   if $LD is used for creating shared libraries.  Do not use
+   hardcode_libdir_flag_spec_ld any more.
+   * libltdl/m4/libtool.m4 (_LT_LINKER_SHLIBS, _LT_LANG_CXX_CONFIG)
+   (_LT_LANG_F77_CONFIG, _LT_LANG_FC_CONFIG, _LT_SYS_DYNAMIC_LINKER)
+   hardcode_libdir_flag_spec_ld: Remove all instances of the tag
+   variable.
+   (_LT_LINKER_SHLIBS) [linux, xlf] hardcode_libdir_flag_spec:
+   Set variable, including ${wl}.  Fixes hardcoding in programs
+   created by XL Fortran on GNU/Linux.
+   * NEWS, THANKS: Update.
+   Report by Paul H. Hargrove.
+
Rebuild menus in the manual.
* doc/automake.texi: Rebuild menus (using ^C ^U ^A in emacs).
Thanks to Ian Lance Taylor for the suggestion.
diff --git a/NEWS b/NEWS
index 6930274..83cee5e 100644
--- a/NEWS
+++ b/NEWS
@@ -15,6 +15,15 @@ New in 2.4.2 2010-12-??: git version 2.4.1a, Libtool team:
   - The bug that leaked developer tool paths into the release tarballs
 from ./bootstrap is fixed.
 
+* Important incompatible changes:
+
+  - The undocumented hardcode_libdir_flag_spec_ld tag variable has been
+removed in favor of using hardcode_libdir_flag_spec with $wl set to empty.
+
+* Changes in supported systems or compilers:
+
+  - Fixes for gfortran on Darwin, XL Fortran on GNU/Linux.
+
 New in 2.4 2010-09-22: git version 2.2.11a, Libtool team:
 
 * New features:
diff --git a/libltdl/config/ltmain.m4sh b/libltdl/config/ltmain.m4sh
index af46cb8..aff8a1c 100644
--- a/libltdl/config/ltmain.m4sh
+++ b/libltdl/config/ltmain.m4sh
@@ -7237,6 +7237,11 @@ EOF
 
   # Test again, we may have decided not to build it any more
   if test $build_libtool_libs = yes; then
+   # Remove ${wl} instances when linking with ld.
+   # FIXME: should test the right _cmds variable.
+   case $archive_cmds in
+ *\$LD\ *) wl= ;;
+esac
if test $hardcode_into_libs = yes; then
  # Hardcode the library paths
  hardcode_libdirs=
@@ -7275,11 +7280,7 @@ EOF
  if test -n $hardcode_libdir_separator 
 test -n $hardcode_libdirs; then
libdir=$hardcode_libdirs
-   if test -n $hardcode_libdir_flag_spec_ld; then
- eval dep_rpath=\$hardcode_libdir_flag_spec_ld\
-   else
- eval dep_rpath=\$hardcode_libdir_flag_spec\
-   fi
+   eval dep_rpath=\$hardcode_libdir_flag_spec\
  fi
  if test -n $runpath_var  test -n $perm_rpath; then
# We should set the runpath_var.
diff --git a/libltdl/m4/libtool.m4 b/libltdl/m4/libtool.m4
index d8b3a4d..419ffe1 100644
--- a/libltdl/m4/libtool.m4
+++ b/libltdl/m4/libtool.m4
@@ -4522,7 +4522,6 @@ m4_if([$1], [CXX], [
   _LT_TAGVAR(hardcode_direct, $1)=no
   _LT_TAGVAR(hardcode_direct_absolute, $1)=no
   _LT_TAGVAR(hardcode_libdir_flag_spec, $1)=
-  _LT_TAGVAR(hardcode_libdir_flag_spec_ld, $1

Re: LD_LIBRARY_PATH_64 on Solaris

2010-11-14 Thread 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)
 aux_shlibpath_var: New _LT_DECL.
 [hpux/hppa64]: Set shlibpath_var to SHLIB_PATH, aux_shlibpath_var
 to LD_LIBRARY_PATH.
 [irix]: Set shlibpath to LD_LIBRARY_PATH, aux_shlibpath_var to
 LD_LIBRARY${shlibsuff}_PATH.
 [solaris i386/x86_64]: Set aux_shlibpath_var to
 LD_LIBRARY_PATH_{32,64} as appropriate.
 * libltdl/m4/ltdl.m4 (LT_SYS_MODULE_PATH): New define
 LT_MODULE_AUX_PATH_VAR, new cache variable
 lt_cv_module_aux_path_var, set from aux_shlibpath_var.
 * tests/shlibpath.at (aux_shlibpath_var): New test.
 * NEWS: Update.
 * doc/libtool.texi (libtool script contents): Document
 aux_shlibpath_var.  Adjust documentation for
 hardcode_direct_absolute and hardcode_shlibpath_var.
 Report by Paul H. Hargrove.

Any comments on this?  There were several design decisions to be made in
this patch, a quick sanity check by somebody would be nice.

Thanks,
Ralf



Re: Eliminate hardcode_libdir_flag_spec_ld tag variable.

2010-11-14 Thread 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)
 hardcode_libdir_flag_spec_ld: Remove all instances of the tag
 variable.
 (_LT_LINKER_SHLIBS) [linux, xlf] hardcode_libdir_flag_spec:
 Set variable, including ${wl}.  Fixes hardcoding in programs
 created by XL Fortran on GNU/Linux.
 * NEWS, THANKS: Update.
 Report by Paul H. Hargrove.

Any comments on this?  I'll otherwise push soonish.

Thanks,
Ralf



Rebuild menus in the manual.

2010-11-14 Thread 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
 
 

[SCM] GNU Libtool branch, master, updated. v2.4-24-g5ca9b3e

2010-11-10 Thread Ralf Wildenhues
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project GNU Libtool.

The branch, master has been updated
   via  5ca9b3ec6b8be1cdd9713845b3e7cf389cc17ae4 (commit)
  from  7a6ca6e6942ddad9f0dc95e8c6d32e062c9cedbc (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -
commit 5ca9b3ec6b8be1cdd9713845b3e7cf389cc17ae4
Author: Ralf Wildenhues ralf.wildenh...@gmx.de
Date:   Wed Nov 10 19:28:11 2010 +0100

Fix cwrapper test failure with --disable-static.

* tests/cwrapper.at (cwrapper and installed shared libraries):
Compile program source without libtool, so we can be sure a
non-PIC object will be created.

Signed-off-by: Ralf Wildenhues ralf.wildenh...@gmx.de

---

Summary of changes:
 ChangeLog |7 +++
 tests/cwrapper.at |3 +--
 2 files changed, 8 insertions(+), 2 deletions(-)

diff --git a/ChangeLog b/ChangeLog
index 5d1ec7c..9c169e0 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,10 @@
+2010-11-10  Ralf Wildenhues  ralf.wildenh...@gmx.de
+
+   Fix cwrapper test failure with --disable-static.
+   * tests/cwrapper.at (cwrapper and installed shared libraries):
+   Compile program source without libtool, so we can be sure a
+   non-PIC object will be created.
+
 2010-11-01  Peter Rosin  p...@lysator.liu.se
 
docs: Windows DLLs and headers.
diff --git a/tests/cwrapper.at b/tests/cwrapper.at
index 6e8cf3c..0e5ecb7 100644
--- a/tests/cwrapper.at
+++ b/tests/cwrapper.at
@@ -249,8 +249,7 @@ int main (void)
 }
 ]])
 
-AT_CHECK([$LIBTOOL --mode=compile --tag=CC $CC $CPPFLAGS $CFLAGS -c m.c],
- [], [ignore], [ignore])
+AT_CHECK([$CC $CPPFLAGS $CFLAGS -c m.c], [], [ignore], [ignore])
 
 AT_CHECK([$LIBTOOL --mode=link $CC $CFLAGS $LDFLAGS -o m1$EXEEXT m.$OBJEXT 
foo/liba.la],
  [], [ignore], [ignore])


hooks/post-receive
-- 
GNU Libtool



[SCM] GNU Libtool branch, master, updated. v2.4-25-g2a736ed

2010-11-10 Thread Ralf Wildenhues
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project GNU Libtool.

The branch, master has been updated
   via  2a736edf3ee2432e204157f7d535afc09bb53e36 (commit)
  from  5ca9b3ec6b8be1cdd9713845b3e7cf389cc17ae4 (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -
commit 2a736edf3ee2432e204157f7d535afc09bb53e36
Author: Ollie Wild a...@google.com
Date:   Wed Nov 10 21:06:50 2010 +0100

Modify --with-pic to support per-package configurations.

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

Signed-off-by: Ralf Wildenhues ralf.wildenh...@gmx.de

---

Summary of changes:
 ChangeLog  |   12 +
 Makefile.am|1 +
 NEWS   |6 
 doc/libtool.texi   |   17 ++--
 libltdl/m4/ltoptions.m4|   19 -
 tests/{pic_flag.at = with-pic.at} |   49 +---
 6 files changed, 73 insertions(+), 31 deletions(-)
 copy tests/{pic_flag.at = with-pic.at} (50%)

diff --git a/ChangeLog b/ChangeLog
index 9c169e0..97b9448 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,15 @@
+2010-11-07  Ollie Wild  a...@google.com
+
+   Modify --with-pic to support per-package configurations.
+   * libltdl/m4/libtool.m4:  Modify --with-pic to accept a list of
+   package names.  Modelled off --enable-shared.
+   * tests/with-pic.at: New test.
+   * Makefile.am (TESTSUITE_AT): Add tests/with-pic.at.
+   * doc/libtool.texi (LT_INIT): Enhance documentation of
+   --with-pic configure flag.
+   * NEWS (New features): Mention that --with-pic now accepts a
+   comma-separated list of package names.
+
 2010-11-10  Ralf Wildenhues  ralf.wildenh...@gmx.de
 
Fix cwrapper test failure with --disable-static.
diff --git a/Makefile.am b/Makefile.am
index db2c0a9..66f38b1 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -502,6 +502,7 @@ TESTSUITE_AT= tests/testsuite.at \
  tests/ctor.at \
  tests/exceptions.at \
  tests/early-libtool.at \
+ tests/with-pic.at \
  tests/no-executables.at \
  tests/deplibs-ident.at \
  tests/configure-iface.at \
diff --git a/NEWS b/NEWS
index d8d692e..6930274 100644
--- a/NEWS
+++ b/NEWS
@@ -2,6 +2,12 @@ NEWS - list of user-visible changes between releases of GNU 
Libtool
 
 New in 2.4.2 2010-12-??: git version 2.4.1a, Libtool team:
 
+* New features:
+
+  - The --with-pic configure option now supports a list of comma-separated
+package names.  This can be used to build some static libraries with PIC
+objects while building others with non-PIC objects.
+
 * Bug fixes:
 
   - The generic approximation of the command line length limit (when getconf is
diff --git a/doc/libtool.texi b/doc/libtool.texi
index 2f48a09..5c2570d 100644
--- a/doc/libtool.texi
+++ b/doc/libtool.texi
@@ -2042,9 +2042,10 @@ LT_PREREQ([...@value{version}])
 @defmac LT_INIT (@var{options})
 @defmacx AC_PROG_LIBTOOL
 @defmacx AM_PROG_LIBTOOL
-Add support for the @option{--enable-shared} and @option{--disable-shared}
-...@code{configure} fla...@footnote{@code{LT_INIT} requires that
-you define the @file{Makefile} variable @code{top_builddir} in your
+Add support for the @option{--enable-shared}, @option{--disable-shared},
+...@option{--enable-static}, @option{--disable-static}, @option{--with-pic}, 
and
+...@option{--without-pic} @code{configure} fla...@footnote{@code{LT_INIT} 
requires
+that you define the @file{Makefile} variable @code{top_builddir} in your
 @file{Makefile.in}.  Automake does this automatically, but Autoconf
 users should set it to the relative path to the top of your build
 directory (@file{../..}, for example).}  @code{AC_PROG_LIBTOOL} and
@@ -2086,6 +2087,16 @@ behaves similarly, but it uses @option{--enable-static} 
and
 The package name @samp{default} matches any packages that have not set
 their name in the @code{PACKAGE} environment variable.
 
+The @option{--with-pic} and @option{--without-pic} configure flags can be used
+to specify whether or not @command{libtool} uses PIC objects.  By default,
+...@command{libtool} uses PIC objects for shared libraries and non-PIC objects 
for
+static

Fix cwrapper test failure with --disable-static.

2010-11-10 Thread Ralf Wildenhues
http://hydra.nixos.org/build/737077/log/raw
shows among others (some of which are NixOS and not Libtool issues)
the following failure:

libtool: compile:  gcc -g -O2 -c m.c  -fPIC -DPIC -o .libs/m.o
./cwrapper.at:255: $LIBTOOL --mode=link $CC $CFLAGS $LDFLAGS -o m1$EXEEXT 
m.$OBJEXT foo/liba.la
stderr:
gcc: m.o: No such file or directory
stdout:
libtool: link: gcc -g -O2 -o .libs/m1 m.o  foo/.libs/liba.so -Wl,-rpath 
-Wl,/tmp/nix-build-j7dzmn77cw5yzw9l6d48fdqv4q18mjy0-libtool-2.4.1a.drv-0/libtool-2.4.1a/tests/testsuite.dir/057/inst/lib
./cwrapper.at:255: exit code was 1, expected 0
57. cwrapper.at:201: 57. cwrapper and installed shared libraries 
(cwrapper.at:201): FAILED (cwrapper.at:255)


which should be fixed by the patch below, which I'm pushing as obvious.

Thanks,
Ralf

Fix cwrapper test failure with --disable-static.

* tests/cwrapper.at (cwrapper and installed shared libraries):
Compile program source without libtool, so we can be sure a
non-PIC object will be created.

diff --git a/tests/cwrapper.at b/tests/cwrapper.at
index 6e8cf3c..0e5ecb7 100644
--- a/tests/cwrapper.at
+++ b/tests/cwrapper.at
@@ -249,8 +249,7 @@ int main (void)
 }
 ]])
 
-AT_CHECK([$LIBTOOL --mode=compile --tag=CC $CC $CPPFLAGS $CFLAGS -c m.c],
- [], [ignore], [ignore])
+AT_CHECK([$CC $CPPFLAGS $CFLAGS -c m.c], [], [ignore], [ignore])
 
 AT_CHECK([$LIBTOOL --mode=link $CC $CFLAGS $LDFLAGS -o m1$EXEEXT m.$OBJEXT 
foo/liba.la],
  [], [ignore], [ignore])



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

2010-11-10 Thread 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



  1   2   3   4   5   6   7   8   9   10   >