Re: [patch #6416] AmigaOS4 support in libtool

2008-03-12 Thread Ralf Wildenhues
Hello Henning,

I have applied your patch now, including a NEWS entry, as below, and put
you in THANKS.  Please check that I did not make any errors, thanks.

Gathering from the testsuite failure, the shared library support has
some work ahead yet.

Cheers,
Ralf

2008-03-12  Henning Nielsen Lund  [EMAIL PROTECTED]

* libltdl/m4/libtool.m4 (_LT_SYS_DYNAMIC_LINKER)
(_LT_COMPILER_PIC, _LT_LINKER_SHLIBS) [amigaos]: Port to
AmigaOS4 shared libraries on powerpc.
* libltdl/m4/ltdl.m4 (LT_SYS_DLOPEN_DEPLIBS) [amigaos]:
Likewise.
* THANKS, NEWS: Update.

Index: NEWS
===
RCS file: /cvsroot/libtool/libtool/NEWS,v
retrieving revision 1.222
diff -u -r1.222 NEWS
--- NEWS4 Mar 2008 22:31:33 -   1.222
+++ NEWS12 Mar 2008 19:47:00 -
@@ -2,6 +2,10 @@
 
 New in 2.3b: 2008-??-??: CVS version 2.3a, Libtool team:
 
+* Changes in supported systems or compilers:
+
+  - Initial shared library support for AmigaOS4 on powerpc.
+
 * Bug fixes:
 
   - Fix 2.2 regression in libltdl that causes memory corruption upon
Index: libltdl/m4/libtool.m4
===
RCS file: /cvsroot/libtool/libtool/libltdl/m4/libtool.m4,v
retrieving revision 1.142
diff -u -r1.142 libtool.m4
--- libltdl/m4/libtool.m4   8 Mar 2008 12:14:15 -   1.142
+++ libltdl/m4/libtool.m4   12 Mar 2008 19:47:04 -
@@ -2150,13 +2150,18 @@
   ;;
 
 amigaos*)
-  if test $host_cpu = m68k; then
+  case $host_cpu in
+  powerpc)
+# Since July 2007 AmigaOS4 officially supports .so libraries.
+# When compiling the executable, add -use-dynld -Lsobjs: to the 
compileline.
+library_names_spec='${libname}${release}${shared_ext}$versuffix 
${libname}${release}${shared_ext}$major $libname${shared_ext}'
+;;
+  m68k)
 library_names_spec='$libname.ixlibrary $libname.a'
 # Create ${libname}_ixlibrary.a entries in /sys/libs.
 finish_eval='for lib in `ls $libdir/*.ixlibrary 2/dev/null`; do 
libname=`$ECHO X$lib | $Xsed -e '\''s%^.*/\([[^/]]*\)\.ixlibrary$%\1%'\''`; 
test $RM /sys/libs/${libname}_ixlibrary.a; $show cd /sys/libs  $LN_S $lib 
${libname}_ixlibrary.a; cd /sys/libs  $LN_S $lib ${libname}_ixlibrary.a || 
exit 1; done'
-  else
-dynamic_linker=no
-  fi
+;;
+  esac
   ;;
 
 beos*)
@@ -3524,14 +3529,22 @@
_LT_TAGVAR(lt_prog_compiler_static, $1)='-Bstatic'
   fi
   ;;
+
 amigaos*)
-  if test $host_cpu = m68k; then
-# FIXME: we need at least 68020 code to build shared libraries, but
-# adding the `-m68020' flag to GCC prevents building anything better,
-# like `-m68040'.
-_LT_TAGVAR(lt_prog_compiler_pic, $1)='-m68020 -resident32 
-malways-restore-a4'
-  fi
+  case $host_cpu in
+  powerpc)
+# see comment about AmigaOS4 .so support
+_LT_TAGVAR(lt_prog_compiler_pic, $1)='-fPIC'
+;;
+  m68k)
+# FIXME: we need at least 68020 code to build shared libraries, but
+# adding the `-m68020' flag to GCC prevents building anything 
better,
+# like `-m68040'.
+_LT_TAGVAR(lt_prog_compiler_pic, $1)='-m68020 -resident32 
-malways-restore-a4'
+;;
+  esac
   ;;
+
 beos* | irix5* | irix6* | nonstopux* | osf3* | osf4* | osf5*)
   # PIC is the default for these OSes.
   ;;
@@ -3816,12 +3829,18 @@
   ;;
 
 amigaos*)
-  if test $host_cpu = m68k; then
-# FIXME: we need at least 68020 code to build shared libraries, but
-# adding the `-m68020' flag to GCC prevents building anything better,
-# like `-m68040'.
-_LT_TAGVAR(lt_prog_compiler_pic, $1)='-m68020 -resident32 
-malways-restore-a4'
-  fi
+  case $host_cpu in
+  powerpc)
+# see comment about AmigaOS4 .so support
+_LT_TAGVAR(lt_prog_compiler_pic, $1)='-fPIC'
+;;
+  m68k)
+# FIXME: we need at least 68020 code to build shared libraries, but
+# adding the `-m68020' flag to GCC prevents building anything 
better,
+# like `-m68040'.
+_LT_TAGVAR(lt_prog_compiler_pic, $1)='-m68020 -resident32 
-malways-restore-a4'
+;;
+  esac
   ;;
 
 beos* | irix5* | irix6* | nonstopux* | osf3* | osf4* | osf5*)
@@ -4228,19 +4247,18 @@
   ;;
 
 amigaos*)
-  if test $host_cpu = m68k; then
-_LT_TAGVAR(archive_cmds, $1)='$RM 
$output_objdir/a2ixlibrary.data~$ECHO #define NAME $libname  
$output_objdir/a2ixlibrary.data~$ECHO #define LIBRARY_ID 1  
$output_objdir/a2ixlibrary.data~$ECHO #define VERSION $major  
$output_objdir/a2ixlibrary.data~$ECHO #define REVISION $revision  
$output_objdir/a2ixlibrary.data~$AR $AR_FLAGS $lib $libobjs~$RANLIB $lib~(cd 
$output_objdir  a2ixlibrary -32)'
-_LT_TAGVAR(hardcode_libdir_flag_spec, $1)='-L$libdir'
-_LT_TAGVAR(hardcode_minus_L, $1)=yes

Re: [patch] 1.5.26 do echo=echo if necessary

2008-03-09 Thread Ralf Wildenhues
Hi Thien-Thi,

* Thien-Thi Nguyen wrote on Sun, Mar 09, 2008 at 10:29:13AM CET:
 () Peter O'Gorman [EMAIL PROTECTED]
 () Sat, 08 Mar 2008 17:33:47 -0600
 
It seems likely that you have a configure that was created with
a different version of libtool than ltmain.sh was created with.
 
 Are you talking about the configure script in
 libtool-1.5.26.tar.gz?  I don't see how that enters into the
 post-install problem of trying to install Automake 1.10.1.
 
For matching versions of libtool.m4 and ltmain.sh from
libtool-1.5.26, the generated libtool script should already
have:
 
# An echo program that does not interpret backslashes.
echo=echo
 
 OK.  Perhaps this is a problem w/ Automake, then.

You probably have to let aclocal know where Libtool 2.2's macro files
are.  I do that with
  echo $libtool_prefix/share/aclocal \
$automake_prefix/share/aclocal/dirlist

Cheers,
Ralf


___
Bug-libtool mailing list
Bug-libtool@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-libtool


Re: [libtool 2.2] testsuite: 34 failed

2008-03-08 Thread Ralf Wildenhues
On Sat, Mar 08, 2008 at 09:58:38AM +0100, Roberto Bagnara wrote:
 Ralf Wildenhues wrote:
 
 What I instead meant was: the installed libltdl.la file is missing,
 but the libltdl.so.7 file is still present, as is the ltdl.h header
 in the include directory.
 
 Does that still match your setup?

 The problem is that I have installed 2.2 and then the versions patched
 as you indicated on the same path.  So, even if something that belonged
 to 2.1.b was still there when I say 2.2's `make check' failing, now it
 has been overwritten.

OK.

 Also, are things working for you with 2.3a now?

 Things work with 2.2 + your patches.  However, I am of course willing to
test with 2.3a.  Where is it?  I have looked in

There is no release 2.3a.  2.3a is the term for the CVS version, i.e.,
currently CVS HEAD.  There will however be a 2.2.2 in a few weeks.

Just to make sure I have understood you right: if with whatever you
currently have, you run
  make check-local TESTSUITEFLAGS=-v -d -x -k AC_WITH_LTDL

then this passes for you now?

Thanks,
Ralf



___
Bug-libtool mailing list
Bug-libtool@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-libtool


Re: [libtool 2.2] testsuite: 55 failed with as-needed

2008-03-08 Thread Ralf Wildenhues
Hi Alexis,

* Alexis Ballier wrote on Sat, Mar 08, 2008 at 02:50:09PM CET:
 
 Perhaps it's the desired behavior, but I get a failure on test 55 when
 using -Wl,--as-needed in LDFLAGS (and its ok if I remove it).
 From my poor understanding of template.at, the test is run for the case
 when libb does not depend on liba and when linking the main program
 against both libb and liba, liba gets dropped but libb needs it, thus
 the linking failure. Anyway, I thought it was worth reporting it.

Thank you for the report.  That's interesting, for several reasons.

First, how did you stumble over this failure?  Did you explicitly
configure with LDFLAGS=-Wl,--as-needed?  If yes, is that the only
failure you get with that setting, and if no, does gentoo set that
by default now in some way (which)?

Second, this corresponds to a failure Markus Duft had with his w32
patch series.  More data points are always helpful

Cheers,
Ralf


___
Bug-libtool mailing list
Bug-libtool@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-libtool


Re: cross compilation to w32

2008-03-08 Thread Ralf Wildenhues
Hi Gary,

* Gary V. Vaughan wrote on Sat, Mar 08, 2008 at 05:39:38PM CET:
 On 8 Mar 2008, at 07:03, Ralf Wildenhues wrote:
 we have a couple of problems wrt. cross compilation to w32 in 2.2.
 When I cross-compile from GNU/Linux to MinGW using Debian's mingw32
 packages (i586-mingw32msvc-gcc etc.), then link mode already
 requires executing a host program; for example:
[...]
 This means that building will fail on systems without a simulator.
[...]
 Does anybody see easy ways out?

 Shouldn't the cwrapper be compiled with the host compiler?  It looks as
 though it isn't at the moment...

It is.  With our new scheme in 2.2 however, the wrapper is also
*executed* already at link time, rather than only at run time.
That is the gist of the first problem for users without a simulator.

Cheers,
Ralf


___
Bug-libtool mailing list
Bug-libtool@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-libtool


Re: [libtool 2.2] testsuite: 18 19 64 failed [Solaris 7 SPARC]

2008-03-07 Thread Ralf Wildenhues
Hello Peter,

* Peter O'Gorman wrote on Fri, Mar 07, 2008 at 02:04:41AM CET:
 Peter O'Gorman wrote:
  Nelson H. F. Beebe wrote:
  
  libtool: link: f90 -shared  -Qoption ld --whole-archive ./.libs/liba1.a 
  ./.libs/liba2.a -Qoption ld --no-whole-archive -Qoption ld -soname 
  -Qoption ld liba12.so.0 -o .libs/liba12.so.0.0.0
  /convenience.at:211: exit code was 1, expected 0
  18. convenience.at:169: 18. FC convenience archives (convenience.at:169): 
  FAILED (convenience.at:211)
  
  Libtool detected FC as f90, but otherwise used the gcc tools. I'll look
  into this.
 
 Because we generally use the same archive_cmds for F77, FC as for CXX,

No we don't.  archive_cmds _is_ tagged.  In a casual test, it worked
just fine for me to mix gcc and g++ with Solaris 10 f77 and f90.

I must admit that I don't yet know why this doesn't work for Nelson's
system, though.

 things can get a little messed up. This fixes the most common case,
 gcc, g++, g77/gfortran  some other fortran compiler, by pretending the
 other fortran compiler does not exist.

As I said before, I know several setups where this kind of thing does
work (as long as your patch is not applied). 

Cheers,
Ralf


___
Bug-libtool mailing list
Bug-libtool@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-libtool


Re: [libtool 2.2] testsuite: 34 failed

2008-03-07 Thread Ralf Wildenhues
On Sat, Mar 08, 2008 at 08:27:38AM +0100, Roberto Bagnara wrote:
 Ralf Wildenhues wrote:
 
 I can reproduce this error under the following circumstances:
 
 A libltdl 2.1 or newer has previously been installed in a place
 where the preprocessor and the link editor can find headers resp.
 library (suitable CPPFLAGS=-I... and LDFLAGS=-L... count, too),
 but the libltdl.la file is missing in the installation, and also
 the runtime linker does not search the installed location of
 libltdl.so.7 by default (and -R.../-Wl,-rpath,... have not been added).
 
 Does that match your setup?  If yes, who removed the installed
 libltdl.la file, and why?

 yes, I believe this matches my setup.  I had installed Libtool 2.1.b;
 nothing worked for me so, since I had no time to investigate further,
 I uninstalled it (not the proper way, I guess) and went back to
 Libtool 1.5.24.

But if you used make uninstall, then there should be no traces left.
What I instead meant was: the installed libltdl.la file is missing, but
the libltdl.so.7 file is still present, as is the ltdl.h header in the
include directory.

Does that still match your setup?

Also, are things working for you with 2.3a now?

Thanks,
Ralf






___
Bug-libtool mailing list
Bug-libtool@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-libtool


Re: [libtool 2.2] testsuite: 19 64 failed [Solaris AMD64]

2008-03-06 Thread Ralf Wildenhues
Hello Peter,

* Peter O'Gorman wrote on Thu, Mar 06, 2008 at 06:36:22AM CET:
 
 I admit that I don't understand the failures like this one yet.
 
 Nelson H. F. Beebe wrote:
  /convenience.at:265: $LIBTOOL --tag=GCJ --mode=link $GCJ $GCJFLAGS 
  $LDFLAGS -o liba12.la liba1.la liba2.la -rpath /notexist
  stderr:
  stdout:
  libtool: link: gcj -shared -Wl,-z -Wl,text -Wl,-h -Wl,liba12.so.0 -o 
  .libs/liba12.so.0.0.0  -Wl,-z -Wl,allextract ./.libs/liba1.a 
  ./.libs/liba2.a -Wl,-z -Wl,defaultextract
 
 $GCJ is properly expanded to 'gcj' here.
 
  /convenience.at:267: $LIBTOOL --tag=GCJ --mode=link $GCJ $GCJFLAGS 
  $LDFLAGS -o liba123.la A3.lo liba1.la liba2.la -rpath /notexist
  stderr:
  /local/build/bare/libtool-2.2/tests/testsuite.dir/64/libtool: line 7084: 
  -r: command not found
  stdout:
  libtool: link:  -r -o .libs/liba123.la-1.o .libs/A3.o 
 
 But here it is the empty string!

This should be $LD -r here, no?  AFAICS this failure happens inside the
low max_cmd_len test.  This looks like a regression caused by the patch
that removed _LT_SYS_DYNAMIC_LINKER from _LT_LANG_GCJ_CONFIG.  (If that
turns out to be true, I am glad we did not make this change for the
other tags).  This did not show up on GNU/Linux because there
--whole-archive is used.

Case in point:
$ ./libtool --tag=GCJ --config|grep ^LD
LD=/usr/bin/ld
LD=

Cheers,
Ralf


___
Bug-libtool mailing list
Bug-libtool@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-libtool


Re: [libtool 2.2] testsuite: 19 35 36 44 45 46 48 49 50 51 52 53 60 61 62 64 failed [GNU/Linux PowerPC]

2008-03-06 Thread Ralf Wildenhues
Hello Nelson, Peter,

* Peter O'Gorman wrote on Thu, Mar 06, 2008 at 06:18:42AM CET:
 Nelson H. F. Beebe wrote:
 
  libtool: compile:  gcj -g -O2 -c A3.java 
  gcj: libgcj.spec: No such file or directory

 Your gcj and automake are broken. Do you have a sane toolchain on any of
 your systems?

First off, let us thank Nelson for doing all this testing work for us.
Thank you!

Then, let's avoid us getting blame for broken gcj installations.
OK to apply this patch to avoid the gcj test when a compile would fail?
Or do you feel tests for working compilers should be done in configure
already?

Cheers,
Ralf

2008-03-06  Ralf Wildenhues  [EMAIL PROTECTED]

* tests/convenience.at (Java convenience archives): Skip test if
gcj cannot compile a .java file.
Report by Nelson H. F. Beebe.

Index: tests/convenience.at
===
RCS file: /cvsroot/libtool/libtool/tests/convenience.at,v
retrieving revision 1.8
diff -u -r1.8 convenience.at
--- tests/convenience.at25 Mar 2007 12:12:43 -  1.8
+++ tests/convenience.at6 Mar 2008 19:05:17 -
@@ -1,6 +1,6 @@
 # convenience.at -- testing C convenience archives-*- Autotest -*-
 
-#   Copyright (C) 2005, 2007 Free Software Foundation, Inc.
+#   Copyright (C) 2005, 2007, 2008 Free Software Foundation, Inc.
 #   Written by Ralf Wildenhues, 2005
 #
 #   This file is part of GNU Libtool.
@@ -258,6 +258,14 @@
   public A$i () { a = 0; }
 };
 EOF
+
+  # There are just too many broken gcj installations out there, either missing
+  # libgcj.spec or unable to find it.  Skip this test for them.
+  if test $i -eq 1; then
+AT_CHECK[($GCJ $GCJFLAGS -c foo1.java || exit 77], [], [ignore], [ignore])
+rm -f foo1.o foo1.obj
+  fi
+
   $LIBTOOL --tag=GCJ --mode=compile $GCJ $GCJFLAGS -c foo$i.java
   $LIBTOOL --tag=GCJ --mode=compile $GCJ $GCJFLAGS -c A$i.java
   $LIBTOOL --tag=GCJ --mode=link $GCJ $GCJFLAGS $LDFLAGS -o liba$i.la A$i.lo


___
Bug-libtool mailing list
Bug-libtool@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-libtool


Re: [libtool 2.2] testsuite: 19 35 36 44 45 46 48 49 50 51 52 53 60 61 62 64 failed [GNU/Linux PowerPC]

2008-03-06 Thread Ralf Wildenhues
Hello Nelson,

* Nelson H. F. Beebe wrote on Thu, Mar 06, 2008 at 02:18:18AM CET:
 # -*- compilation -*-
 35. am-subdir.at:33: testing ...
 libtoolize: putting auxiliary files in `.'.
 libtoolize: copying file `./ltmain.sh'
 libtoolize: putting macros in `m4'.
 libtoolize: copying file `m4/libtool.m4'
 libtoolize: copying file `m4/ltoptions.m4'
 libtoolize: copying file `m4/ltsugar.m4'
 libtoolize: copying file `m4/ltversion.m4'
 libtoolize: copying file `m4/lt~obsolete.m4'
 ./am-subdir.at:78: $ACLOCAL -I m4
 stderr:
 /usr/local/share/aclocal/yacc.m4:6: warning: underquoted definition of 
 AM_PROG_YACC
 /usr/local/share/aclocal/yacc.m4:6:   run info '(automake)Extending aclocal'
 /usr/local/share/aclocal/yacc.m4:6:   or see 
 http://sources.redhat.com/automake/automake.html#Extending-aclocal
 stdout:
 ./am-subdir.at:78: $AUTOMAKE --add-missing
 stderr:
 configure.ac:5: installing `./compile'
 configure.ac:3: installing `./config.sub'
 configure.ac:2: installing `./missing'
 configure.ac:2: installing `./install-sh'
 configure.ac:3: installing `./config.guess'
 Makefile.am: installing `./depcomp'
 automake: 
 automake: ## Internal Error ##
 automake: 
 automake: Unknown ?token? `LZMA' (neg = 0)
 automake: Please contact [EMAIL PROTECTED].
  at /usr/local/share/automake-1.10/Automake/Channels.pm line 570
   Automake::Channels::msg('automake', '', 'Unknown ?token? `LZMA\' (neg = 
 0)') called at /usr/local/share/automake-1.10/Automake/ChannelDefs.pm line 191
   Automake::ChannelDefs::prog_error('Unknown ?token? `LZMA\' (neg = 0)') 
 called at /usr/local/bin/automake line 6406
   Automake::transform('?LZMA?', 'HASH(0x104aa0d0)') called at 
 /usr/local/bin/automake line 6469
   
 Automake::make_paragraphs('/usr/local/share/automake-1.10/am/distdir.am', 
 'GETTEXT', 0, 'DISTCHECK-HOOK', '', 'FILENAME_FILTER', '', 'DIST-TARGETS', 
 '', ...) called at /usr/local/bin/automake line 6539
   Automake::file_contents_internal(1, 
 '/usr/local/share/automake-1.10/am/distdir.am', 
 'Automake::Location=HASH(0x105b3d30)', 'DISTCHECK-HOOK', '', 'GETTEXT', 0, 
 'FILENAME_FILTER', '', ...) called at /usr/local/bin/automake line 6719
   Automake::file_contents('distdir', 
 'Automake::Location=HASH(0x105b3d30)', 'DIST-TARGETS', '', 'GETTEXT', 0, 
 'DISTCHECK-HOOK', '', 'FILENAME_FILTER', ...) called at 
 /usr/local/bin/automake line 3688
   Automake::handle_dist() called at /usr/local/bin/automake line 7493
   Automake::generate_makefile('Makefile.am', 'Makefile.in') called at 
 /usr/local/bin/automake line 7834
 stdout:
 ./am-subdir.at:78: exit code was 255, expected 0
 ./am-subdir.at:78: grep 'require .*but have' stderr  (exit 77)
 35. am-subdir.at:33: 35. C subdir-objects (am-subdir.at:33): FAILED 
 (am-subdir.at:78)

Could it be possible that, on your system,
  /usr/local/share/automake-1.10/Automake/Channels.pm

is from Automake 1.10.1, but
  /usr/local/bin/automake

is from Automake 1.10?  If so, how did you manage to get it that way?
It would explain this failure.

Thanks,
Ralf


___
Bug-libtool mailing list
Bug-libtool@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-libtool


Re: libtool runs compiler command in wrong locale

2008-03-06 Thread Ralf Wildenhues
* Ralf Wildenhues wrote on Mon, Jan 21, 2008 at 08:18:26AM CET:
 * Bruno Haible wrote on Mon, Jan 21, 2008 at 12:46:12AM CET:
 [...]
if ${opt_dry_run-false}; then :; else
  +   eval $lt_switch_to_user_locale
  eval $my_cmd
  my_status=$?
  +   eval $lt_switch_to_safe_locale
  if test $my_status -eq 0; then :; else
 [...]
 
  + lt_switch_to_user_locale=\$lt_var=\$save_$lt_var; 
  \$lt_switch_to_user_locale\
  + lt_switch_to_safe_locale=\$lt_var=C; \$lt_switch_to_safe_locale\
 
 This approach has the advantage of not using an extra fork (as your
 branch-1-5 patch does), but it lacks re-exporting of the changed
 variables, which is needed by some older shells.

Playing on the rather safe side, I consider applying this patch for now.
OK?

I considered doing the same for link mode and some of the other stuff we
pipe through func_show_eval, but that should only be done after an audit
of the various *archive_cmds variables and settings in libtool.m4 to
ensure there are no grep patterns or so that would be influenced.

Thanks,
Ralf

2008-03-06  Bruno Haible  [EMAIL PROTECTED]
and Ralf Wildenhues  [EMAIL PROTECTED]

Fix compiler output to be in the user locale.
* libltdl/config/general.m4sh (func_show_eval_locale): New
function, for running commands in the user locale.
* libltdl/config/ltmain.m4sh (func_mode_compile): Use it for
compiling.
* tests/localization.at (localized compiler messages): New test.
* Makefile.am: Adjust.
Report by Bruno Haible.

Index: Makefile.am
===
RCS file: /cvsroot/libtool/libtool/Makefile.am,v
retrieving revision 1.230
diff -u -r1.230 Makefile.am
--- Makefile.am 4 Mar 2008 21:25:48 -   1.230
+++ Makefile.am 6 Mar 2008 19:36:08 -
@@ -448,6 +448,7 @@
  tests/indirect_deps.at \
  tests/archive-in-archive.at \
  tests/execute-mode.at \
+ tests/localization.at \
  tests/destdir.at \
  tests/old-m4-iface.at \
  tests/am-subdir.at \
Index: libltdl/config/general.m4sh
===
RCS file: /cvsroot/libtool/libtool/libltdl/config/general.m4sh,v
retrieving revision 1.9
diff -u -r1.9 general.m4sh
--- libltdl/config/general.m4sh 10 May 2007 17:26:45 -  1.9
+++ libltdl/config/general.m4sh 6 Mar 2008 19:36:08 -
@@ -1,6 +1,6 @@
 m4_if([general.m4sh -- general shell script boiler plate -*- Autoconf -*-
 
-   Copyright (C) 2004, 2005, 2007 Free Software Foundation, Inc.
+   Copyright (C) 2004, 2005, 2007, 2008 Free Software Foundation, Inc.
Written by Gary V. Vaughan, 2004
 
This file is part of GNU Cvs-utils.
@@ -344,5 +344,31 @@
   fi
 fi
 }
+
+
+# func_show_eval_locale cmd [fail_exp]
+# Unless opt_silent is true, then output CMD.  Then, if opt_dryrun is
+# not true, evaluate CMD.  If the evaluation of CMD fails, and FAIL_EXP
+# is given, then evaluate it.  Use the saved locale for evaluation.
+func_show_eval_locale ()
+{
+my_cmd=$1
+my_fail_exp=${2-:}
+
+${opt_silent-false} || {
+  func_quote_for_expand $my_cmd
+  eval func_echo $func_quote_for_expand_result
+}
+
+if ${opt_dry_run-false}; then :; else
+  eval $lt_user_locale
+   $my_cmd
+  my_status=$?
+  eval $lt_safe_locale
+  if test $my_status -eq 0; then :; else
+   eval (exit $my_status); $my_fail_exp
+  fi
+fi
+}
 ]])
 
Index: libltdl/config/ltmain.m4sh
===
RCS file: /cvsroot/libtool/libtool/libltdl/config/ltmain.m4sh,v
retrieving revision 1.99
diff -u -r1.99 ltmain.m4sh
--- libltdl/config/ltmain.m4sh  5 Mar 2008 20:14:43 -   1.99
+++ libltdl/config/ltmain.m4sh  6 Mar 2008 19:36:10 -
@@ -96,12 +96,16 @@
 # Only set LANG and LC_ALL to C if already set.
 # These must not be set unconditionally because not all systems understand
 # e.g. LANG=C (notably SCO).
+lt_user_locale=
+lt_safe_locale=
 for lt_var in LANG LANGUAGE LC_ALL LC_CTYPE LC_COLLATE LC_MESSAGES
 do
   eval if test \\${$lt_var+set}\ = set; then
   save_$lt_var=\$$lt_var
   $lt_var=C
  export $lt_var
+ lt_user_locale=\$lt_var=\$save_$lt_var; \$lt_user_locale\
+ lt_safe_locale=\$lt_var=C; \$lt_safe_locale\
fi
 done
 
@@ -1515,7 +1519,7 @@
 
   $opt_dry_run || $RM $lobj $output_obj
 
-  func_show_eval $command\
+  func_show_eval_locale $command \
   'test -n $output_obj  $RM $removelist; exit $EXIT_FAILURE'
 
   if test $need_locks = warn 
@@ -1565,7 +1569,7 @@
   # Suppress compiler output if we already did a PIC compilation.
   command=$command$suppress_output
   $opt_dry_run || $RM $obj $output_obj
-  func_show_eval $command \
+  func_show_eval_locale $command

Re: [libtool 2.2] testsuite: 19 35 36 44 45 46 48 49 50 51 52 53 60 61 62 64 failed [GNU/Linux PowerPC]

2008-03-06 Thread Ralf Wildenhues
* Bob Friesenhahn wrote on Thu, Mar 06, 2008 at 08:43:15PM CET:
 On Thu, 6 Mar 2008, Peter O'Gorman wrote:
 I think the test for a working GCJ should be in libtool, and unset GCJ,
 avoid adding the tag etc.if it is found to be nonfunctional. We would
 have to issue a warning during configure or something. Does not look to
 be quite as easy as this patch though, if you want to apply this one as
 a stop-gap measure, that is fine.

I'm considering doing that (the stop-gap measure).

 If libtool is integrated into a package and the package declares that it 
 needs a Java compiler, then failure to pass basic tests should cause 
 configure to quit with an error (similar to the way configure fails if 
 the C compiler does not work).

But that should not be Libtool's decision, but the package's.

 If libtool is built stand-alone (as in 
 our distribution) then there should be a warning but the user should 
 still be able to build and install libtool.

Yes, and I can conceive just as well a libtool-using package which may
optionally use a Java compiler, and thus its configure script should not
bail out at Libtool's whim either.

Cheers,
Ralf


___
Bug-libtool mailing list
Bug-libtool@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-libtool


compiler found but not functional (was: [libtool 2.2] testsuite: 19 35 36 44 45 46 48 49 50 51 52 53) 60 61 62 64 failed [GNU/Linux PowerPC]

2008-03-06 Thread Ralf Wildenhues
* Peter O'Gorman wrote on Thu, Mar 06, 2008 at 08:57:56PM CET:
 Ralf Wildenhues wrote:
  
  I'm considering doing that (the stop-gap measure).
 
 Your call.

I've applied that now.

  Yes, and I can conceive just as well a libtool-using package which may
  optionally use a Java compiler, and thus its configure script should not
  bail out at Libtool's whim either.
 
 I agree, the way LT_LANG has worked so far is to test if a compiler for
 the language exists and is executable (or something similar), but not
 cause an error if it does not.
 
 What would be ideal is to check that the compiler exists, is executable,
 works (an possibly, when not cross-compiling, test that trivial code
 that is compiled with the compiler runs) but not cause an error if the
 compiler is broken or does not exist, simply warn the user that a broken
 compiler was detected and set the same vars in the same way as would be
 set if no compiler was detected.

Actually I would have liked it if
  AC_PROG_{CC,CXX,F77,FC} and AM_PROG_GCJ

did the functionality testing, _and_ had an optional IF-FAILS argument,
defaulted to AC_MSG_ERROR.  That allows flexibility but has the right
default.  I think that would be enough, too: LT_LANG then would not have
to check for functional compiler.

Unfortunately, such an interface will break compatibility.

Cheers,
Ralf


___
Bug-libtool mailing list
Bug-libtool@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-libtool


Re: [libtool 2.2] testsuite: 19 35 36 44 45 46 48 49 50 51 52 53 60 61 62 64 failed [GNU/Linux PowerPC]

2008-03-06 Thread Ralf Wildenhues
* Gary V. Vaughan wrote on Thu, Mar 06, 2008 at 10:41:47PM CET:
 On 6 Mar 2008, at 15:03, Bob Friesenhahn wrote:
 There needs to be a way to output any warnings at the tail end of  
 configure so that at least someone is more likely to see them.   
 Without adequate notification to the user, the user is likely to try  
 'make' and then find that libtool does not work.

 Oo! Oo!  Add that to the libtool-2.4 roadmap! :-)

FWIW, I don't think that's a good request.  Let the package developer
put at the end what she wants to.  If we start automatizing duplicating
messages in Libtool or Autoconf, then in a couple of years the number of
such messages will be so large that somebody will scream: let's put the
*really* important messages once more *after that*!

That's not a workable solution.  The normal configure output and
config.log were invented to do what Bob wants.  Libtool cannot in
general know what is important for the package, IMVHO.  So if the
functioning of a compiler is important, then configure should simply
fail if the compiler does not work.

Cheers,
Ralf


___
Bug-libtool mailing list
Bug-libtool@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-libtool


Re: [libtool 2.2] testsuite: 19 64 failed [GNU/Linux IA-32]

2008-03-06 Thread Ralf Wildenhues
* Peter O'Gorman wrote on Fri, Mar 07, 2008 at 08:40:08AM CET:
 Peter O'Gorman wrote:
  
  Ralf has already checked in a workaround for gcj being unable to create
  objects/executables. I guess I will add to that so it tests that an
  executable created by the compiler will actually run.
 
 Ok?

Yes, provided that you've tested it ...

 +AT_CHECK([./foo1$(EXEEXT) || exit 77],[],[ignore],[ignore])
 +rm -f foo1.o foo1.obj foo1$(EXEEXT)

... after eliminating those syntax errors, $EXEEXT instead of $(EXEEXT).

Cheers,
Ralf


___
Bug-libtool mailing list
Bug-libtool@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-libtool


Re: mode=execute argument munging bug

2008-03-05 Thread Ralf Wildenhues
* Roberto Bagnara wrote on Wed, Mar 05, 2008 at 07:37:58AM CET:

 It is better now, but there is still the problem that, apparently,
 libtool redirects stdin for the program it is running.

Gosh.  How embarrassing.  I've applied this patch.

Thanks for testing!
Ralf

2008-03-05  Ralf Wildenhues  [EMAIL PROTECTED]

* libltdl/config/ltmain.m4sh (func_lalib_unsafe_p): redirect
and restore from stdin, not stdout.
* tests/execute-mode.at (execute mode): Adjust test to catch
this.
Report by Roberto Bagnara.

Index: libltdl/config/ltmain.m4sh
===
RCS file: /cvsroot/libtool/libtool/libltdl/config/ltmain.m4sh,v
retrieving revision 1.98
diff -u -r1.98 ltmain.m4sh
--- libltdl/config/ltmain.m4sh  4 Mar 2008 21:25:48 -   1.98
+++ libltdl/config/ltmain.m4sh  5 Mar 2008 20:12:28 -
@@ -648,7 +648,7 @@
 func_lalib_unsafe_p ()
 {
 lalib_p=no
-if test -r $1  exec 51 $1; then
+if test -r $1  exec 50 $1; then
for lalib_p_l in 1 2 3 4
do
read lalib_p_line
@@ -656,7 +656,7 @@
\#\ Generated\ by\ *$PACKAGE* ) lalib_p=yes; break;;
esac
done
-   exec 15 5-
+   exec 05 5-
 fi
 test $lalib_p = yes
 }
Index: tests/execute-mode.at
===
RCS file: /cvsroot/libtool/libtool/tests/execute-mode.at,v
retrieving revision 1.1
diff -u -r1.1 execute-mode.at
--- tests/execute-mode.at   4 Mar 2008 21:25:48 -   1.1
+++ tests/execute-mode.at   5 Mar 2008 20:12:28 -
@@ -51,6 +51,30 @@
 AT_DATA([lt-real],
 [[#! /bin/sh
 echo $@
+cat
+]])
+
+AT_DATA([libfakelib.la],
+[[# libfakelib.la - a libtool library file
+# Generated by ltmain.sh (GNU libtool 1.2605 2008/03/04 22:31:32) 2.3a
+#
+# Please DO NOT delete this file!
+# It is necessary for linking the library.
+
+dlname=''
+library_names=''
+old_library='libfakelib.a'
+inherited_linker_flags=''
+dependency_libs=''
+weak_library_names=''
+current=
+age=
+revision=
+installed=no
+shouldnotlink=yes
+dlopen=''
+dlpreopen=''
+libdir=''
 ]])
 
 mkdir sub
@@ -61,20 +85,26 @@
 AT_CHECK([$LIBTOOL --mode=execute sub/foo])
 AT_CHECK([$LIBTOOL --mode=execute ./foo foo], [], [foo
 ])
-AT_CHECK([$LIBTOOL --mode=execute ./lt-wrapper foo], [], [foo
+AT_CHECK([$LIBTOOL --mode=execute ./lt-wrapper foo /dev/null], [], [foo
 ])
 AT_CHECK([cd sub  $LIBTOOL --mode=execute ./foo ../foo], [], [../foo
 ])
 # suppose that ./foo is gdb, and lt-wrapper is the wrapper script.
-AT_CHECK([$LIBTOOL --mode=execute ./foo lt-wrapper bar baz], [],
+AT_CHECK([$LIBTOOL --mode=execute ./foo lt-wrapper bar baz /dev/null], [],
 [./lt-real bar baz
 ])
 
+# check that stdin works even with -dlopen.
+AT_CHECK([echo bar | $LIBTOOL --mode=execute -dlopen libfakelib.la 
./lt-wrapper foo],
+[], [foo
+bar
+])
+
 # Check that a missing real program causes an error.
 # The error message and code are likely to be 126,
 # No such file or directory but system-dependent.
 mv -f lt-real lt-backup
-AT_CHECK([$LIBTOOL --mode=execute ./lt-wrapper foo || exit 1],
+AT_CHECK([$LIBTOOL --mode=execute ./lt-wrapper foo /dev/null || exit 1],
 [1], [ignore], [ignore])
 mv -f lt-backup lt-real
 
@@ -82,7 +112,7 @@
 AT_CHECK([$LIBTOOL --mode=execute ./foo arg  with special chars: \$!*\`'()],
 [], [arg  with special chars: $!*`'()
 ])
-AT_CHECK([$LIBTOOL --mode=execute ./lt-wrapper arg  with special chars: 
\$!*\`'()],
+AT_CHECK([$LIBTOOL --mode=execute ./lt-wrapper arg  with special chars: 
\$!*\`'() /dev/null],
 [], [arg  with special chars: $!*`'()
 ])
 AT_CHECK([$LIBTOOL --mode=execute ./foo lt-wrapper arg  with special chars: 
\$!*\`'()],


___
Bug-libtool mailing list
Bug-libtool@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-libtool


Re: [libtool 2.2] testsuite: 19 35 36 44 45 46 48 49 50 51 52 53 60 61 62 64 failed [GNU/Linux PowerPC]

2008-03-05 Thread Ralf Wildenhues
* Bob Friesenhahn wrote on Thu, Mar 06, 2008 at 06:28:10AM CET:
 On Wed, 5 Mar 2008, Peter O'Gorman wrote:

 Your gcj and automake are broken. Do you have a sane toolchain on any of
 your systems?

 That sounds a little harsh.  I think that the LZMA complaint from  
 automake may be because libtool requests a lzma package and it requires 
 the very latest automake to do so. 

Where does Libtool 2.2 require lzma?  That would be a serious bug,
requiring such a recent Automake.

Thanks,
Ralf


___
Bug-libtool mailing list
Bug-libtool@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-libtool


Re: [libtool 2.2] testsuite: 34 failed

2008-03-05 Thread Ralf Wildenhues
Hello Roberto,

your posts are good sources of bug reports ...

* Roberto Bagnara wrote on Sun, Mar 02, 2008 at 08:48:07AM CET:
 ## --- ##
 ## libtool 2.2 test suite. ##
 ## --- ##
[...]
 ##  ##
 ## Summary of the failures. ##
 ##  ##
 Failed tests:
 libtool 2.2 test suite test groups:
 
  NUM: FILE-NAME:LINE TEST-GROUP-NAME
   KEYWORDS
 
   34: old-m4-iface.at:107 AC_WITH_LTDL
   libtoolize automake autoconf
[...]
 34. old-m4-iface.at:107: testing ...
 libtoolize: putting auxiliary files in `.'.
[...]
 checking whether libtool supports -dlopen/-dlpreopen... yes
 checking for ltdl.h... yes
 checking whether lt_dlinterface_register is declared... yes
 checking for lt_dlinterface_register in -lltdl... yes
 checking where to find libltdl headers... 
 checking where to find libltdl library... -lltdl
[...]

 ./old-m4-iface.at:153: $MAKE  
[...]
 /bin/sh ./libtool --mode=link gcc -no-undefined -g -O2  -o ltdldemo main.o 
 -dlopen module.la -lltdl
 libtool: link: rm -f .libs/ltdldemo.nm .libs/ltdldemo.nmS .libs/ltdldemo.nmT
 libtool: link: (cd .libs  gcc -g -O2 -c -fno-builtin ltdldemoS.c)
 libtool: link: rm -f .libs/ltdldemoS.c .libs/ltdldemo.nm 
 .libs/ltdldemo.nmS .libs/ltdldemo.nmT
 libtool: link: gcc -g -O2 -o ltdldemo main.o .libs/ltdldemoS.o  -lltdl
 libtool: link: rm -f .libs/ltdldemoS.o
 make[4]: Leaving directory 
 `/usr/local/distrib/libtool-2.2/tests/testsuite.dir/34'
 ./old-m4-iface.at:156: ./ltdldemo; lt_status=$?; if test $lt_status -eq 0; 
 then :;
  elif test X$host != X$build  \
   { test -x ./ltdldemo || test -x ./ltdldemo$EXEEXT; }
  then (exit 77); else (exit $lt_status); fi
 --- /dev/null 2008-02-27 15:51:00.483962769 +0100
 +++ /usr/local/distrib/libtool-2.2/tests/testsuite.dir/at-stderr  
 2008-03-02 08:28:27.0 +0100
 @@ -0,0 +1 @@
 +./ltdldemo: error while loading shared libraries: libltdl.so.7: cannot open 
 shared object file: No such file or directory
 stdout:
 ./old-m4-iface.at:156: exit code was 127, expected 0
 34. old-m4-iface.at:107: 34. AC_WITH_LTDL (old-m4-iface.at:107): FAILED 
 (old-m4-iface.at:156)

I can reproduce this error under the following circumstances:

A libltdl 2.1 or newer has previously been installed in a place where
the preprocessor and the link editor can find headers resp. library
(suitable CPPFLAGS=-I... and LDFLAGS=-L... count, too), but the
libltdl.la file is missing in the installation, and also the runtime
linker does not search the installed location of libltdl.so.7 by
default (and -R.../-Wl,-rpath,... have not been added).

Does that match your setup?  If yes, who removed the installed
libltdl.la file, and why?

Thanks,
Ralf


___
Bug-libtool mailing list
Bug-libtool@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-libtool


Re: libltdl memory corruption

2008-03-04 Thread Ralf Wildenhues
Hi Peter,

* Peter O'Gorman wrote on Tue, Mar 04, 2008 at 07:14:51AM CET:
 Ralf Wildenhues wrote:
  
  So I'd appreciate a review of this, and also test results on systems
  with loaders other than preopen and dlopen.  (I haven't even tested
  successful compilation on those other systems.)
 
 I did not manage to try the shl_load loader, only tested dyld. This
 patch causes no regressions on Mac OS X 10.2. If that is also true for
 the loaders you get around to trying, this is ok.

For the preopen, dlopen, shl_load loaders, I confirmed that the
testsuite addition exposes the bug, and the loader changes fixes the
testsuite failure.  For loadlibrary, I only cross-compiled from
GNU/Linux to ensure absense of typos.

I visually inspected the BeOS and dld changes again for typos, and then
applied the patch, after adding a NEWS entry.

 Thank you. Once again you sent a patch for a bug before I even got
 around to reading the list.

My pleasure.  :-)  Kudos to Andreas for reporting the bug.

Cheers,
Ralf


___
Bug-libtool mailing list
Bug-libtool@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-libtool


libtool generated by GNU $PACKAGE (was: [libtool 2.2] testsuite: 34 failed)

2008-03-04 Thread Ralf Wildenhues
* Roberto Bagnara wrote on Mon, Mar 03, 2008 at 09:14:48PM CET:
 P.S. In ./libtool there is the line

# Generated automatically by config.status (GNU ppl) 0.10pre16

  `ppl' is indeed the short name of the project.  I don't know
  why it is preceded by GNU.

Fixed with the patch below.  I don't care much that, in the Libtool
package itself, the will result in a libtool script with the line
# Generated automatically by config.status (libtool 1.2600 2008/03/02 02:19:16) 
2.3a

instead of GNU libtool.

This has been reported several times, please speak up if I forgot to
mention a reporter.  The hard part with this patch was ensuring that
none of the libtool code uses this bit in a sed pattern (in some parts
script headers are checked, but not this one, apparently).

Cheers, and thanks to both of you for the report (I put you in THANKS),
Ralf

2008-03-04  Ralf Wildenhues  [EMAIL PROTECTED]

* libltdl/m4/libtool.m4 (_LT_CONFIG): Drop misleading `GNU'
prefix before the host package name in the Generated by line
for the libtool script.
* THANKS: Update.
Reports by Peter Rosin and Roberto Bagnara.

Index: libltdl/m4/libtool.m4
===
RCS file: /cvsroot/libtool/libtool/libltdl/m4/libtool.m4,v
retrieving revision 1.137
diff -u -r1.137 libtool.m4
--- libltdl/m4/libtool.m4   20 Feb 2008 20:11:39 -  1.137
+++ libltdl/m4/libtool.m4   4 Mar 2008 21:11:56 -
@@ -685,7 +685,7 @@
 #! $SHELL
 
 # `$ECHO $ofile | sed 's%^.*/%%'` - Provide generalized library-building 
support services.
-# Generated automatically by $as_me (GNU $PACKAGE$TIMESTAMP) $VERSION
+# Generated automatically by $as_me ($PACKAGE$TIMESTAMP) $VERSION
 # Libtool was configured on host `(hostname || uname -n) 2/dev/null | sed 1q`:
 # NOTE: Changes made to this file will be lost: look at ltmain.sh.
 #


___
Bug-libtool mailing list
Bug-libtool@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-libtool


mode=execute argument munging bug (was: [libtool 2.2] testsuite: 34 failed)

2008-03-04 Thread Ralf Wildenhues
Hello Roberto,

* Roberto Bagnara wrote on Mon, Mar 03, 2008 at 09:14:48PM CET:

 $ cat mycommand
 #!/bin/sh
 echo mycommand invoked with argument '$1'
 $ mycommand ciao
 mycommand invoked with argument 'ciao'
 $ ./libtool --mode=execute mycommand ciao
 mycommand invoked with argument '/home/roberto/tppl/'
 $

 Note that /home/roberto/tppl/ is the directory where the libtool
 script is located.  I can also do

 $ cd interfaces/
 $ ../libtool --mode=execute ../mycommand ciao
 mycommand invoked with argument '/home/roberto/tppl/'

 Is this behavior normal?

No.  Thank you for the bug report.  I've applied the fix below.

FWIW, the ordering of the tests in execute-mode.at is such that the
first set still passes for 1.5.26.

 ./libtool is what has been created at configure time and a bzipped
 version of it is attached to this file.

It wasn't attached to the message, but that's not a problem.  :-)

Cheers,
Ralf

* libltdl/config/ltmain.m4sh (func_mode_execute): Replace only
arguments we have identified as shell or C wrappers.
(func_emit_wrapper): Output error message on stderr.
* tests/execute-mode.at: New file, with --mode=execute tests.
* Makefile.am: Adjust.
* NEWS: Update.
Fixes 2.2 regression.  Report by Roberto Bagnara.

Index: Makefile.am
===
RCS file: /cvsroot/libtool/libtool/Makefile.am,v
retrieving revision 1.229
diff -u -r1.229 Makefile.am
--- Makefile.am 18 Jan 2008 10:49:40 -  1.229
+++ Makefile.am 4 Mar 2008 21:16:26 -
@@ -447,6 +447,7 @@
  tests/search-path.at \
  tests/indirect_deps.at \
  tests/archive-in-archive.at \
+ tests/execute-mode.at \
  tests/destdir.at \
  tests/old-m4-iface.at \
  tests/am-subdir.at \
Index: NEWS
===
RCS file: /cvsroot/libtool/libtool/NEWS,v
retrieving revision 1.220
diff -u -r1.220 NEWS
--- NEWS4 Mar 2008 21:00:18 -   1.220
+++ NEWS4 Mar 2008 21:16:27 -
@@ -6,6 +6,9 @@
 
   - Fix 2.2 regression in libltdl that causes memory corruption upon
 repeated `lt_dlinit(); lt_dlexit()'.
+  - Fix 2.2 regression in that `libtool --mode=execute CMD ARGS' does not
+transform ARGS that do not look like shell or C wrappers of libtool
+programs.
 
 New in 2.2: 2008-03-01; CVS version 2.1c, Libtool team:
 
Index: libltdl/config/ltmain.m4sh
===
RCS file: /cvsroot/libtool/libtool/libltdl/config/ltmain.m4sh,v
retrieving revision 1.97
diff -u -r1.97 ltmain.m4sh
--- libltdl/config/ltmain.m4sh  28 Jan 2008 15:49:46 -  1.97
+++ libltdl/config/ltmain.m4sh  4 Mar 2008 21:16:29 -
@@ -1694,12 +1694,14 @@
# Do a test to see if this is really a libtool program.
if func_ltwrapper_script_p $file; then
  func_source $file
+ # Transform arg to wrapped name.
+ file=$progdir/$program
elif func_ltwrapper_executable_p $file; then
  func_ltwrapper_scriptname $file
  func_source $func_ltwrapper_scriptname_result
+ # Transform arg to wrapped name.
+ file=$progdir/$program
fi
-   # Transform arg to wrapped name.
-   file=$progdir/$program
;;
   esac
   # Quote arguments (to preserve shell metacharacters).
@@ -2468,7 +2470,7 @@
  ;;
esac
$ECHO \
-  \$ECHO \\$0: cannot exec \$program \$*\
+  \$ECHO \\$0: cannot exec \$program \$*\ 12
   exit 1
 fi
   else
--- /dev/null   2008-03-02 10:33:19.200041011 +0100
+++ tests/execute-mode.at   2008-03-04 22:15:22.0 +0100
@@ -0,0 +1,92 @@
+# execute-mode.at -- libtool --mode=execute -*- Autotest -*-
+#
+#   Copyright (C) 2008 Free Software Foundation, Inc.
+#   Written by Ralf Wildenhues, 2008
+#
+#   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([execute mode])
+AT_KEYWORDS([libtool])
+
+AT_DATA([foo],
+[[#! /bin/sh
+if test $# -gt 0; then
+  echo $@
+else

Re: libltdl memory corruption

2008-03-03 Thread Ralf Wildenhues
Hello Andreas,

* Andreas Schwab wrote on Mon, Mar 03, 2008 at 03:39:47PM CET:
 libltdl uses memory after free when initialized twice.

Thank you very much for the bug report.  Proposed patch below.
I tested it on i686-unknown-linux-gnu but it should be tested
with as many loaders as possible.

So I'd appreciate a review of this, and also test results on systems
with loaders other than preopen and dlopen.  (I haven't even tested
successful compilation on those other systems.)

Thanks,
Ralf

2008-03-03  Ralf Wildenhues  [EMAIL PROTECTED]

* libltdl/loaders/dld_link.c (vl_exit): New function, zero out ...
(vtable): ... this new file static variable split out from ...
(get_vtable): ... here.  Initialize vtable, register vl_exit as 
dlloader_exit function.
* libltdl/loaders/dlopen.c: Likewise.
* libltdl/loaders/dyld.c: Likewise.
* libltdl/loaders/load_add_on.c: Likewise.
* libltdl/loaders/loadlibrary.c: Likewise.
* libltdl/loaders/shl_load.c: Likewise.
* libltdl/loaders/preopen.c: Likewise; vl_exit existed here
already 
* tests/lt_dlexit.at (lt_dlexit unloading libs): Update test.
Report by Andreas Schwab.

Index: libltdl/loaders/dld_link.c
===
RCS file: /cvsroot/libtool/libtool/libltdl/loaders/dld_link.c,v
retrieving revision 1.9
diff -u -r1.9 dld_link.c
--- libltdl/loaders/dld_link.c  8 May 2007 14:38:50 -   1.9
+++ libltdl/loaders/dld_link.c  3 Mar 2008 21:41:03 -
@@ -1,7 +1,7 @@
 /* loader-dld_link.c -- dynamic linking with dld
 
Copyright (C) 1998, 1999, 2000, 2004, 2006,
- 2007 Free Software Foundation, Inc.
+ 2007, 2008 Free Software Foundation, Inc.
Written by Thomas Tanner, 1998
 
NOTE: The canonical source of this file is maintained with the
@@ -45,20 +45,21 @@
 
 /* Boilerplate code to set up the vtable for hooking this loader into
libltdl's loader list:  */
+static int  vl_exit  (lt_user_data loader_data);
 static lt_module vm_open  (lt_user_data loader_data, const char *filename,
lt_dladvise advise);
 static int  vm_close (lt_user_data loader_data, lt_module module);
 static void *   vm_sym   (lt_user_data loader_data, lt_module module,
  const char *symbolname);
 
+static lt_dlvtable *vtable = 0;
+
 /* Return the vtable for this loader, only the name and sym_prefix
attributes (plus the virtual function implementations, obviously)
change between loaders.  */
 lt_dlvtable *
 get_vtable (lt_user_data loader_data)
 {
-  static lt_dlvtable *vtable = 0;
-
   if (!vtable)
 {
   vtable = lt__zalloc (sizeof *vtable);
@@ -70,6 +71,7 @@
   vtable-module_open  = vm_open;
   vtable-module_close = vm_close;
   vtable-find_sym = vm_sym;
+  vtable-dlloader_exit= vl_exit;
   vtable-dlloader_data= loader_data;
   vtable-priority = LT_DLLOADER_APPEND;
 }
@@ -92,6 +94,15 @@
 #  include dld.h
 #endif
 
+/* A function called through the vtable when this loader is no
+   longer needed by the application.  */
+static int
+vl_exit (lt_user_data LT__UNUSED loader_data)
+{
+  vtable = NULL;
+  return 0;
+}
+
 /* A function called through the vtable to open a module with this
loader.  Returns an opaque representation of the newly opened
module for processing with this loader's other vtable functions.  */
Index: libltdl/loaders/dlopen.c
===
RCS file: /cvsroot/libtool/libtool/libltdl/loaders/dlopen.c,v
retrieving revision 1.12
diff -u -r1.12 dlopen.c
--- libltdl/loaders/dlopen.c12 Jan 2008 17:00:51 -  1.12
+++ libltdl/loaders/dlopen.c3 Mar 2008 21:41:03 -
@@ -45,20 +45,21 @@
 
 /* Boilerplate code to set up the vtable for hooking this loader into
libltdl's loader list:  */
+static int  vl_exit  (lt_user_data loader_data);
 static lt_module vm_open  (lt_user_data loader_data, const char *filename,
lt_dladvise advise);
 static int  vm_close (lt_user_data loader_data, lt_module module);
 static void *   vm_sym   (lt_user_data loader_data, lt_module module,
  const char *symbolname);
 
+static lt_dlvtable *vtable = 0;
+
 /* Return the vtable for this loader, only the name and sym_prefix
attributes (plus the virtual function implementations, obviously)
change between loaders.  */
 lt_dlvtable *
 get_vtable (lt_user_data loader_data)
 {
-  static lt_dlvtable *vtable = 0;
-
   if (!vtable)
 {
   vtable = (lt_dlvtable *) lt__zalloc (sizeof *vtable);
@@ -73,6 +74,7 @@
   vtable-module_open  = vm_open;
   vtable-module_close = vm_close;
   vtable-find_sym = vm_sym;
+  vtable-dlloader_exit= vl_exit;
   vtable-dlloader_data= loader_data;
   vtable-priority

Re: Can't build Win32 DLL that links with static libraries

2008-03-02 Thread Ralf Wildenhues
Hi Neil,

* Neil Roberts wrote on Sat, Mar 01, 2008 at 08:24:22PM CET:
 
 As I understand it, when linking a shared library libtool checks
 whether all of the dependencies are found and that they are valid
 libraries. In the old version of libtool it just did this using
 objdump which reports the same string regardless of whether the
 library it finds is static or an import library. However in the new
 version it will use func_win32_libid if the 'file' command is
 available. That function returns a different string depending on
 whether the library is static or import. The regular expression that
 is tested on this string only accepts import libraries which makes it
 imposible to link against static libraries.
 
 Is this intentional?

Yes, I think this was a conscious decision made by the Cygwin/MinGW
maintainers of Libtool.

 Why would you want to stop people linking against static libraries?

AFAIK for cleanliness issues.  You shouldn't do this on other systems,
so it's encouraged to also not do it on w32.

 I've attached a patch which fixes it for my by just allowing it to
 match against static libraries as well.

A similar patch has been rejected before, for these reasons.
(This isn't a rejection, but an AFAIR.  For arguing it, it
would probably help to look up previous discussions on this.)

Hope that helps.

Cheers,
Ralf


___
Bug-libtool mailing list
Bug-libtool@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-libtool


Re: GNU Libtool 2.2 and the future (Saturday, March 1st 2009, 22:22:22)

2008-03-02 Thread Ralf Wildenhues
Hello Jens,

* Jens Schleusener wrote on Sun, Mar 02, 2008 at 10:01:19AM CET:

 congratulations for releasing GNU Libtool 2.2!

 But probably you have enjoyed too many (doubtless hard-earned) bottles of 
 champagne ...

 ... or how is the date

  Saturday, March 1st 2009, 22:22:22

 on top of the page

  http://www.gnu.org/software/libtool/news.html

 to understand ;-)

Thanks for the report and the kudos.  I've fixed the date, and aspirin's
doing the rest ... ;-)

Cheers,
Ralf


___
Bug-libtool mailing list
Bug-libtool@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-libtool


Re: [libtool 2.2] testsuite: 34 failed

2008-03-02 Thread Ralf Wildenhues
Hello Roberto,

* Roberto Bagnara wrote on Sun, Mar 02, 2008 at 08:48:07AM CET:

 I got errors on a Fedora 7 system (x86_64): the log file
 is attached.  I have also tried using Libtool 2.2 on one
 of my projets, but I get the following:

 /bin/sh ../libtool --tag=CXX   --mode=compile g++ -DHAVE_CONFIG_H -I. -I.. 
 -I/home/roberto/ppl/ppl/src  -I.. -I/home/roberto/ppl/ppl/src-g 
 -frounding-math  -W -Wall -MT Box.lo -MD -MP -MF .deps/Box.Tpo -c -o Box.lo 
 /home/roberto/ppl/ppl/src/Box.cc
 ../libtool: line 459: CDPATH: command not found
 ../libtool: line 1262: func_opt_split: command not found
 libtool: Version mismatch error.  This is libtool 2.2, but the
 libtool: definition of this LT_INIT comes from an older release.
 libtool: You should recreate aclocal.m4 with macros from libtool 2.2
 libtool: and run autoconf again.

 I think I did that on entirely new directories and after running
 `autoreconf -f' to recreate (among other things), aclocal.m4.
 What am I missing?

Which Autoconf, M4 versions were used?  What says
  grep LT_INIT aclocal.m4 m4/libtool.m4

(modify the latter to point at the libtool.m4 file that's copied into
your project if any).

Still looking at your the testsuite failure (but it's anyway an issue
separate from the above).

Cheers, and thanks for the report,
Ralf


___
Bug-libtool mailing list
Bug-libtool@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-libtool


Re: patch adding argz_add and argz_count implementation

2008-02-25 Thread Ralf Wildenhues
Hi Karl,

* Karl Berry wrote on Mon, Feb 25, 2008 at 06:59:39PM CET:
 A Texinfo contributor made use of two argz functions that are not in the
 implementation in gnulib, argz_add and argz_count.  As a result, of
 course compilation failed on non-glibc systems.  They seemed trivial to
 implement, so here is a patch for argz.c and argz_.h.  How does it look?

Good, except that I'd prefer if argz_count used strlen instead of
walking the argz vector manually.  Little point in adding a suboptimal
algorithm if one can have speed (or smaller size) for free by using
a library function.

 Actually, the whole argz_.h vs argz.in.h thing is a bit confusing.  It
 seems like gnulib uses argz.in.h, but the libtool sources use argz_.h.
 I guess I should change the name when syncing from libtool to gnulib?
 Or maybe change the name in libtool?

I'll change the name in Libtool after 2.2.  Maybe I'll even change it to
use gnulib-tool ...

 P.S. I see in passing there are more argz functions not present, but
 since I didn't need them, I didn't do anything about them.  The code
 from libc/string/argz* could perhaps be used if the need ever arises.

Certainly.  

Cheers,
Ralf


___
Bug-libtool mailing list
Bug-libtool@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-libtool


Re: portability of -Lrelative_directory_name

2008-02-24 Thread Ralf Wildenhues
Hello Bruno,

* Bruno Haible wrote on Sun, Feb 24, 2008 at 02:51:08PM CET:
 
 A while ago someone said that if in a build directory I have a (not yet
 installed) ../lib/libfoo.la, to link with this library I should *not* use
 
libtool ... -L../lib -lfoo
 
 but rather mention the .la file explicitly:
 
libtool ... -L../lib ../lib/libfoo.la
 or
libtool ... ../lib/libfoo.la

You should use the last one, none of the others.

 Is it true that references to non-yet-installed libool libraries should not be
 made with -l? If so, it would be worth to document this in the libtool
 documentation. I didn't find it there.

Quoting info libtool Linking executables:

   (1) However, you should avoid using `-L' or `-l' flags to link
against an uninstalled libtool library.  Just specify the relative path
to the `.la' file, such as `../intl/libintl.la'.  This is a design
decision to eliminate any ambiguity when linking against uninstalled
shared libraries.

This has been documented for eons.

Cheers,
Ralf


___
Bug-libtool mailing list
Bug-libtool@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-libtool


Re: libtoolize /ltmain.sh bug

2008-02-13 Thread Ralf Wildenhues
* Ralf Wildenhues wrote on Mon, Feb 11, 2008 at 11:01:53PM CET:
 
 In an empty directory this happens:
 
 $ libtoolize --copy --ltdl
 touch: cannot touch `/ltmain.sh': Permission denied
 libtoolize: can not copy `/home/ralf/local/share/libtool/config/ltmain.sh' to 
 `/'
 libtoolize: copying file `libltdl/config/compile'
[...]
 First, the toplevel directory isn't even a package, so it should not get
 an ltmain.sh file at all (it does, however, unlike what the bogus error
 suggests).  Second, there is a '.' missing before /ltmain.sh.

Proposed patch.  OK to apply?

Cheers,
Ralf

2008-02-13  Ralf Wildenhues  [EMAIL PROTECTED]

* libtoolize.m4sh (func_install_pkgconfig_files): Only call
func_install_pkgconfig_parent if $seen_autoconf.
* tests/standalone.at (compiling softlinked libltdl)
(compiling copied libltdl, installable libltdl)
(linking libltdl without autotools): Use checked libtoolize
calls to catch warnings.

Index: libtoolize.m4sh
===
RCS file: /cvsroot/libtool/libtool/libtoolize.m4sh,v
retrieving revision 1.75
diff -u -r1.75 libtoolize.m4sh
--- libtoolize.m4sh 31 Jan 2008 16:17:06 -  1.75
+++ libtoolize.m4sh 13 Feb 2008 22:10:56 -
@@ -1202,7 +1202,9 @@
 elif $opt_ltdl  test x$ltdl_mode = xsubproject
#  test x$auxdir != x$subproject_auxdir is implied
 then
-  func_install_pkgconfig_parent
+  if $seen_autoconf; then
+   func_install_pkgconfig_parent
+  fi
   func_install_pkgconfig_subproject
 
   # 3. Not subproject, but AC_CONFIG_AUX_DIR was used in parent:
Index: tests/standalone.at
===
RCS file: /cvsroot/libtool/libtool/tests/standalone.at,v
retrieving revision 1.7
diff -u -r1.7 standalone.at
--- tests/standalone.at 25 Mar 2007 12:12:43 -  1.7
+++ tests/standalone.at 13 Feb 2008 22:10:56 -
@@ -1,6 +1,6 @@
 # standalone.at -- test standalone libltdl builds -*- Autotest -*-
 #
-#   Copyright (C) 2005 Free Software Foundation, Inc.
+#   Copyright (C) 2005, 2008 Free Software Foundation, Inc.
 #   Written by Gary V. Vaughan, 2006
 #
 #   This file is part of GNU Libtool.
@@ -30,7 +30,7 @@
 
 AT_SETUP([compiling softlinked libltdl])
 
-LT_AT_LIBTOOLIZE([--ltdl=.])
+LT_AT_CHECK_LIBTOOLIZE([--ltdl=.], [], [ignore])
 LT_AT_CONFIGURE
 LT_AT_MAKE([all $tst_dist])
 
@@ -45,7 +45,7 @@
 
 AT_SETUP([compiling copied libltdl])
 
-LT_AT_LIBTOOLIZE([--copy --ltdl=.])
+LT_AT_CHECK_LIBTOOLIZE([--copy --ltdl=.], [], [ignore])
 LT_AT_CONFIGURE
 LT_AT_MAKE([all $tst_dist])
 
@@ -62,7 +62,7 @@
 
 prefix=`pwd`/_inst
 
-LT_AT_LIBTOOLIZE([--copy --ltdl=.])
+LT_AT_CHECK_LIBTOOLIZE([--copy --ltdl=.], [], [ignore])
 LT_AT_CONFIGURE([--enable-ltdl-install --prefix=$prefix])
 LT_AT_MAKE([all install $tst_dist])
 
@@ -79,7 +79,7 @@
 AT_SETUP([linking libltdl without autotools])
 
 _LTDL_PROJECT_FILES([libltdl])
-LT_AT_LIBTOOLIZE([--copy --ltdl])
+LT_AT_CHECK_LIBTOOLIZE([--copy --ltdl], [], [ignore])
 LT_AT_MAKE([], [CC=$CC LIBTOOLFLAGS=$LIBTOOLFLAGS CPPFLAGS=$CPPFLAGS \
 CFLAGS=$CFLAGS LDFLAGS=$LDFLAGS \
CONFIGURE_OPTIONS=$configure_options])


___
Bug-libtool mailing list
Bug-libtool@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-libtool


libtoolize /ltmain.sh bug

2008-02-11 Thread Ralf Wildenhues
Hello,

In an empty directory this happens:

$ libtoolize --copy --ltdl
touch: cannot touch `/ltmain.sh': Permission denied
libtoolize: can not copy `/home/ralf/local/share/libtool/config/ltmain.sh' to 
`/'
libtoolize: copying file `libltdl/config/compile'
libtoolize: copying file `libltdl/config/config.guess'
libtoolize: copying file `libltdl/config/config.sub'
libtoolize: copying file `libltdl/config/depcomp'
libtoolize: copying file `libltdl/config/install-sh'
libtoolize: copying file `libltdl/config/missing'
libtoolize: copying file `libltdl/config/ltmain.sh'
libtoolize: putting macros in `libltdl/m4'.
[...]

First, the toplevel directory isn't even a package, so it should not get
an ltmain.sh file at all (it does, however, unlike what the bogus error
suggests).  Second, there is a '.' missing before /ltmain.sh.

I think this is a regression in the recent flurry of libtoolize.m4sh
changes, IIRC this worked well a while ago.

Cheers,
Ralf


___
Bug-libtool mailing list
Bug-libtool@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-libtool


Re: libtool runs compiler command in wrong locale

2008-01-20 Thread Ralf Wildenhues
* Bruno Haible wrote on Mon, Jan 21, 2008 at 12:46:12AM CET:
[...]
   if ${opt_dry_run-false}; then :; else
 +   eval $lt_switch_to_user_locale
 eval $my_cmd
 my_status=$?
 +   eval $lt_switch_to_safe_locale
 if test $my_status -eq 0; then :; else
[...]

 +   lt_switch_to_user_locale=\$lt_var=\$save_$lt_var; 
 \$lt_switch_to_user_locale\
 +   lt_switch_to_safe_locale=\$lt_var=C; \$lt_switch_to_safe_locale\

This approach has the advantage of not using an extra fork (as your
branch-1-5 patch does), but it lacks re-exporting of the changed
variables, which is needed by some older shells.

Cheers,
Ralf


___
Bug-libtool mailing list
Bug-libtool@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-libtool


Re: libtool shell feature checks run with wrong shell

2008-01-16 Thread Ralf Wildenhues
[ http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=447022 aka.
  http://thread.gmane.org/gmane.comp.gnu.libtool.bugs/5879/focus=342902 ]

Hello, and sorry for the long delay.

* Clint Adams wrote on Sat, Dec 15, 2007 at 02:39:36AM CET:
 On Fri, Dec 14, 2007 at 01:59:34AM +, Colin Watson wrote:
  libtool used it. The _LT_CHECK_SHELL_FEATURES macro checks a number of
  shell features and determines accurately that the currently-running
  shell supports +=. Unfortunately, the currently-running shell is bash at
  this point, not dash. The reason for this is that configure has
  different logic for re-execing itself under a different shell from that
  used by libtool. libtool seems to try to account for this using:
  
: ${SHELL=${CONFIG_SHELL-/bin/sh}}

Actually, the generated libtool script should just have
  #! /bin/bash

as its first line, and not re-exececute itself at all.

OK, let's go step by step here: at the end of the trace posted in this
bug report, CONFIG_SHELL is exported and contains /bin/bash, and
likewise for SHELL.  That means config.status should contain as its
first line
  #! /bin/bash

and a dozen lines further down
  SHELL=${CONFIG_SHELL-/bin/bash}

and so, when ./config.status is executed (and eventually gets around to
creating the libtool script), the code
| cat _LT_EOF  $cfgfile
| #! $SHELL

should just put #! /bin/bash into it.

And in fact that is just what I get on my Debian etch when I try to
reproduce your setup as closely as possibl (tested with Libtool CVS
HEAD).

So I'm wondering where in the chain is the error?

  ... but at this point CONFIG_SHELL is not set, and so libtool ends up
  running under a different shell than the one that configure
  feature-tested.
[...]
 I suppose the easiest workaround is to explicitly set CONFIG_SHELL

Thanks,
Ralf





___
Bug-libtool mailing list
Bug-libtool@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-libtool


Re: libtool shell feature checks run with wrong shell

2008-01-16 Thread Ralf Wildenhues
* Clint Adams wrote on Wed, Jan 16, 2008 at 08:43:22PM CET:
 On Wed, Jan 16, 2008 at 06:44:30PM +, Colin Watson wrote:
  In my failing test case, I have /bin/sh in both these places, not
  /bin/bash.
 
 Same here.

Let's find out what the differences in the setups are.  Which version
of dash?  Which m4 and autoconf versions were used to bootstrap the
package in question?  BTW, which package is this that this happened
with, libtool or some libtool-using one?

I tried with dash 0.5.3-7, Libtool CVS HEAD, M4 1.4.10a (CVS
branch-1_4).  I can try some Debian packages next, but which should I
use?

 I will note that a ./config.status --recheck seems to fix things.

Yes, that's what I would expect.

Thanks,
Ralf


___
Bug-libtool mailing list
Bug-libtool@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-libtool


Re: lib/progname.c

2008-01-02 Thread Ralf Wildenhues
[ Cc:ing bug-libtool ]

Hello Bruno, Paul, all,

* Bruno Haible wrote on Sat, Dec 29, 2007 at 05:36:01PM CET:
 Paul Eggert wrote:
  I do have a bit of trouble reading the code, though.
  It doesn't seem to match the comment: e.g., it strips a leading lt-
  even when there's no /.libs/.
 
 When I look at ltmain.sh it seems that an 'lt-program' or 'lt-program.exe'
 can also be generated outside the .libs directory. But I cannot tell under
 which conditions this happens. Can some libtool guru throw some light on
 this?

Can you point to what makes it look like this, and which Libtool version?
Because I think that an lt-program* outside [._]libs/ would be a bug.
Are you hinting at this line?

  { file=\`ls -1dt \\$progdir/\$program\ \\$progdir/../\$program\ 
2/dev/null | ${SED} 1q\`; \\

I think that's a leftover bug made unnecessary by the changes from
1999-02-22, but I haven't looked closely yet.  ;-)

Thanks, and a Happy New Year,
Ralf


___
Bug-libtool mailing list
Bug-libtool@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-libtool


Re: Mac OS X 10.2.8 HEAD test failures.

2007-12-11 Thread Ralf Wildenhues
Hi Peter,

* Peter O'Gorman wrote on Tue, Dec 11, 2007 at 05:11:47PM CET:
 Ralf Wildenhues wrote:
 
  That's a bug, thanks for catching.  Does it work if _LT_CHECK_BUILDDIR
  is only m4_require'd?
  
  I assume if that's fixed, there will still be more issues.
  
 
 It works a bit better, now tests fail saying Autoconf version 2.58 or
 higher is required for this script which is far more reasonable.
 
 I am not sure what to do in these cases, sure the tools are old, but
 people will download libtool-2.x and run ./configure; make; make check,
 and it will fail simply because they have older automake  autoconf.
 
 Should we print a warning at make check time warning users that their
 versions of automake and autoconf are too old to run the testsuite?

For the tests for which it is ok that older autotools are insufficient,
we should just skip the individual test.  I haven't had a chance to look
at the tests to see which ones should work and which ones shouldn't.
In any case the old-iface ones should.

Cheers,
Ralf



___
Bug-libtool mailing list
Bug-libtool@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-libtool


Re: ltmain.sh install does not support spaces in destdir

2007-12-06 Thread Ralf Wildenhues
Hello Sam,

Thanks for the report and patch.

* Sam Steingold wrote on Mon, Dec 03, 2007 at 06:08:47PM CET:
 VERSION=1.5.22
 TIMESTAMP= (1.1220.2.365 2005/12/18 22:14:06)
 
 ltmain.sh install does not support spaces in destdir, because it does
 not quote destdir. this can be a serious problem for woe32 users.

Whitespace issues are all over ltmain.in.  It's easy to fix some, it's
almost impossible to fix all instances in a way such that the absolute
names to installed programs and libraries can contain whitespace.
At least the cost to benefit ratio for this problem is way out of
proportion, and it would quite certainly make `libtool' much slower
than it is today (and it is already quite slow).  Case in point:
all loops over deplibs would need to quote them, matching a la
  case $deplib in

would need eval'ing and so on.  It would amount to more or less a
rewrite.

All that can reasonably be done is to fix issues that prevent whitespace
in the absolute name of the source tree and the build tree.  Which
hasn't been done, and is not simple either, but at least possible.
(I'm in the process of fixing most of such issues that are in Autoconf
and Automake ATM; I'd rather not do it for Libtool).

 please consider the appended patch which fixed the problem for me:

Just a dozen lines further down are more issues.  If you decide to redo,
please against CVS HEAD, and please add a testcase so that at least this
instance will remain fixed.  It won't help third-party, libtool-using
packages to use your installed library, though, due to the whitespace in
its absolute name.

Cheers,
Ralf

 2007-12-03  Sam Steingold  [EMAIL PROTECTED]
 
   * ltmain.sh: quote $destdir in install to support spaces in it


___
Bug-libtool mailing list
Bug-libtool@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-libtool


Re: Second (non-fPIC) pass messages being suppressed on failure

2007-11-22 Thread Ralf Wildenhues
Hi Peter,

* Peter Rosin wrote on Thu, Nov 22, 2007 at 09:03:41AM CET:
 On Thu, Nov 22, 2007 at 08:19:56AM +0100, Ralf Wildenhues wrote:
  +AT_DATA([nopicfail.c],
  +[[
  +#ifndef PIC
  +choke me
  +#endif
  +int ans = 42;
  +]])
  +
  +AT_DATA([picfail.c],
  +[[
  +#ifndef PIC
  +choke me
  +#endif
  +int ans = 42;
  +]])
 
 Shouldn't one of them (the latter?) be #ifdef PIC?

Yes, of course.  Thanks!

Cheers,
Ralf


___
Bug-libtool mailing list
Bug-libtool@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-libtool


Re: Problems combining static in shared libraries

2007-11-15 Thread Ralf Wildenhues
Hello Sven,

Replying to this issue only for now:

* Sven Verdoolaege wrote on Thu, Nov 15, 2007 at 10:48:40AM CET:

 In any case, I solved this problem by specifying AC_DISABLE_SHARED.
 However, my own library not only depends on a static library
 but also on some other libtool libraries (not configured
 with AC_DISABLE_SHARED) and that also produces incorrect results.

Where the other libtool libraries are also _uninstalled_ (important
detail!), thus live in a subpackage (or sibling package in a package
hierarchy).

 In particular, if you configure with AC_DISABLE_SHARED
 and have an application main that (also) depends on some other
 yet uninstalled libtool library then
 the application will be linked against the .so version of
 the library, but libtool will not create a .libs/main or .libs/lt-main
 and the installed binary will refer to the uninstalled libtool
 library rather than the installed libtool library.

Confirmed.  Yuck.  You should be able to work around it if you drop the
AC_DISABLE_SHARED and instead add
  libbar_la_LDFLAGS = -static

to the toplevel Makefile.am.  At least it looks like that does TRT.

So that means in a package hierarchy like in your example (thanks!),
one cannot currently have partly AC_DISABLE_SHARED and partly not.
Ouch.

Cheers,
Ralf


___
Bug-libtool mailing list
Bug-libtool@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-libtool


Re: New substitution: top_build_prefix

2007-11-10 Thread Ralf Wildenhues
* Ralf Wildenhues wrote on Thu, Nov 08, 2007 at 09:05:24PM CET:
 
   LIBLTDL = ${top_builddir}/ltdl/libltdl.la
[...]
 New config files output variable `top_build_prefix'.

Thanks to Paul and Benoit for reviewing my Autoconf patch.

Here's what I could think of for Libtool.  It's a bit ugly in that it
depends on the Autoconf version, and thus will fix the issue for AIX
make only once Autoconf 2.62 is used.

Hmm, do you think I could make the version comparison be against
`2.61a.265'?  Do you see a more straightforward way to find out whether
Autoconf substitutes top_build_prefix, i.e., can I access `autom4te
--trace' results from within macro files?  I could define a helper macro
in Autoconf, but that wouldn't feel much nicer either.

I'll wait for comments a couple of days before applying.

Thanks,
Ralf

2007-11-10  Ralf Wildenhues  [EMAIL PROTECTED]

Use `${top_build_prefix}' for better compatibility with non-GNU make.
* libltdl/m4/ltdl.m4 (_LT_BUILD_PREFIX): New macro.
If the Autoconf version used is = 2.62, then expand to
`${top_build_prefix}', otherwise to `${top_builddir}/'.
(LTDL_CONVENIENCE, LTDL_INSTALLABLE): Use it for defining
LIBLTDL.  Fixes a build failure with AIX make in a package
using convenience libltdl in nonrecursive mode.
* doc/libtool.texi (Distributing libltdl): Document requirements
to define `top_build_prefix' if Automake is not used.
Report by Bob Friesenhahn.

Index: doc/libtool.texi
===
RCS file: /cvsroot/libtool/libtool/doc/libtool.texi,v
retrieving revision 1.231
diff -u -r1.231 libtool.texi
--- doc/libtool.texi4 Sep 2007 18:01:32 -   1.231
+++ doc/libtool.texi10 Nov 2007 10:59:49 -
@@ -4526,9 +4526,9 @@
 By default, this macro will pass options to the @file{configure}
 script in the subdirectory named by @code{LT_CONFIG_LTDL_DIR} in order
 to cause it to be built as an installable library.  If you're not
-using automake, you will need to define @code{top_builddir} and
[EMAIL PROTECTED] in your makefile so that @code{LIBLTDL} and
[EMAIL PROTECTED] are expanded properly.
+using automake, you will need to define @code{top_build_prefix},
[EMAIL PROTECTED], and @code{top_srcdir} in your makefile so that
[EMAIL PROTECTED] and @code{LTDLINCL} are expanded properly.
 
 If used in conjunction with @code{LT_WITH_LTDL}, this macro must
 appear @strong{before} the call to @code{LT_WITH_LTDL}.  If you are
@@ -4549,9 +4549,9 @@
 By default, this macro will pass options to the @file{configure}
 script in the subdirectory named by @code{LT_CONFIG_LTDL_DIR} in order
 to cause it to be built as a convenience library.  If you're not
-using automake, you will need to define @code{top_builddir} and
[EMAIL PROTECTED] in your makefile so that @code{LIBLTDL} and
[EMAIL PROTECTED] are expanded properly.
+using automake, you will need to define @code{top_build_prefix},
[EMAIL PROTECTED] and @code{top_srcdir} in your makefile so that
[EMAIL PROTECTED] and @code{LTDLINCL} are expanded properly.
 
 @code{AC_LIBLTDL_CONVENIENCE} is a deprecated alias for
 @code{LTDL_CONVENIENCE}.
@@ -4594,7 +4594,8 @@
 If you're using the convenience libltdl, @var{LIBLTDL} will be the
 pathname for the convenience version of libltdl and @var{LTDLINCL} will be
 @option{-I} followed by the directory that contains libltdl, starting
-with @[EMAIL PROTECTED]@}/} and @[EMAIL PROTECTED]@}/} respectively.
+with @[EMAIL PROTECTED]@}} if available, otherwise with
[EMAIL PROTECTED]@[EMAIL PROTECTED]/}, and @[EMAIL PROTECTED]@}/} respectively.
 
 If you request an installed version of libltdl and one is
 [EMAIL PROTECTED]@c
@@ -4608,7 +4609,8 @@
 be empty (this is just a blind assumption that @file{ltdl.h} is
 somewhere in the include path if libltdl is in the library path).  If
 an installable version of libltdl must be built, its pathname,
-starting with @[EMAIL PROTECTED]@}/}, will be stored in
+starting with @[EMAIL PROTECTED]@}} if available, otherwise
[EMAIL PROTECTED]@[EMAIL PROTECTED]/}, will be stored in
 @var{LIBLTDL}, and @var{LTDLINCL} will be set just like in the case of
 convenience library.  So, when you want to link a program with
 libltdl, be it a convenience, installed or installable library, just
Index: libltdl/m4/ltdl.m4
===
RCS file: /cvsroot/libtool/libtool/libltdl/m4/ltdl.m4,v
retrieving revision 1.33
diff -u -r1.33 ltdl.m4
--- libltdl/m4/ltdl.m4  25 Mar 2007 12:12:43 -  1.33
+++ libltdl/m4/ltdl.m4  10 Nov 2007 10:59:54 -
@@ -45,16 +45,30 @@
 m4_define([_LTDL_MODE], [])
 
 
+# _LT_BUILD_PREFIX
+# 
+# If Autoconf is new enough, expand to `${top_build_prefix}', otherwise
+# to `${top_builddir}/'.
+m4_define([_LT_BUILD_PREFIX],
+[m4_ifdef([AC_AUTOCONF_VERSION],
+   [m4_if(m4_version_compare(m4_defn([AC_AUTOCONF_VERSION]), [2.62]),
+ [-1

New substitution: top_build_prefix

2007-11-08 Thread Ralf Wildenhues
Hello Autoconf patchers,

We have hit another bug in HEAD Libtool, for which we could use help
from Autoconf.

This is the setting: a third-party package (GraphicsMagick) that uses
libltdl in nonrecursive mode in a nonrecursive Makefile[1].  In this
Makefile, the library is given as
  noinst_LTLIBRARIES = ltdl/libltdlc.la

however the dependency is given upon
  LIBLTDL = ${top_builddir}/ltdl/libltdl.la

and in this case, top_builddir is `.'.  LIBLTDL is computed as a
substitution of @LIBLTDL@ at configure time.

Now, AIX make (and others) fail to identify `./file' with `file' so the
build fails.  It would be nice if Autoconf also substituted a variable
top_build_prefix that contained of zero or more runs of `../' and
otherwise behaved like top_builddir.  The naming is not coincidental:
config.status already computes this value, it just doesn't make it
available.

This would make writing these kinds of things much easier also in
Automake, which has lots of special-cases of the kind
  if ($directory ne '')
{
  $object = $directory . '/' . $object;
}

Note that top_build_prefix cannot replace top_builddir: the former
requires the user _not_ to add a slash as separator.

[1] Yes, this is yet another instance where nonrecursive makefiles are
more difficult to realize for non-GNU makes.

Cheers,
Ralf

New config files output variable `top_build_prefix'.

* lib/autoconf/status.m4 (_AC_OUTPUT_FILE): Substitute
`top_build_prefix'.
* doc/autoconf.texi (Preset Output Variables): Document it.
* NEWS: Update.
Report by Bob Friesenhahn.

diff --git a/NEWS b/NEWS
index 77cd6f5..854c54a 100644
--- a/NEWS
+++ b/NEWS
@@ -13,6 +13,8 @@ GNU Autoconf NEWS - User visible changes.
  Further, for config headers, the total size of values is not limited by
  the POSIX length limit of text lines any more, only each single line.
 
+** New config variable `top_build_prefix'.
+
 ** Autoconf is now licensed under the General Public License version 3
or later (GPLv3+).  As with earlier versions, the license includes
an exception clause so that you may release a configure script
diff --git a/doc/autoconf.texi b/doc/autoconf.texi
index 9025359..421056e 100644
--- a/doc/autoconf.texi
+++ b/doc/autoconf.texi
@@ -2436,6 +2436,16 @@ The relative name of the top level of the current build 
tree.  In the
 top-level directory, this is the same as @code{builddir}.
 @end defvar
 
[EMAIL PROTECTED] top_build_prefix
[EMAIL PROTECTED] top_build_prefix
+The relative name of the top level of the current build tree with final
+slash if nonemtpy.  This is the same as @code{top_builddir}, except that
+it contains of zero of more runs of @code{../}, so it should not be
+appended with a slash for concatenation.  This helps for @command{make}
+implementations that otherwise do not treat @file{./file} and @file{file}
+as equal in the toplevel build directory.
[EMAIL PROTECTED] defvar
+
 @defvar abs_top_builddir
 @ovindex abs_top_builddir
 Absolute name of @code{top_builddir}.
diff --git a/lib/autoconf/status.m4 b/lib/autoconf/status.m4
index 350d370..4412df0 100644
--- a/lib/autoconf/status.m4
+++ b/lib/autoconf/status.m4
@@ -622,6 +622,7 @@ dnl configure_input is a somewhat special, so we don't call 
AC_SUBST_TRACE.
 s@configure_input@$configure_input;t t
 dnl During the transition period, this is a special case:
 s@top_builddir@$ac_top_builddir_sub;t t[]AC_SUBST_TRACE([top_builddir])
+s@top_build_prefix@$ac_top_build_prefix;t 
t[]AC_SUBST_TRACE([top_build_prefix])
 m4_foreach([_AC_Var], [srcdir, abs_srcdir, top_srcdir, abs_top_srcdir,
builddir, abs_builddir,
abs_top_builddir]AC_PROVIDE_IFELSE([AC_PROG_INSTALL], 
[[, INSTALL]])AC_PROVIDE_IFELSE([AC_PROG_MKDIR_P], [[, MKDIR_P]]),


___
Bug-libtool mailing list
Bug-libtool@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-libtool


Re: New substitution: top_build_prefix

2007-11-08 Thread Ralf Wildenhues
* Ralf Wildenhues wrote on Thu, Nov 08, 2007 at 09:05:24PM CET:
 
 New config files output variable `top_build_prefix'.
 
 * lib/autoconf/status.m4 (_AC_OUTPUT_FILE): Substitute
 `top_build_prefix'.
 * doc/autoconf.texi (Preset Output Variables): Document it.
 * NEWS: Update.
 Report by Bob Friesenhahn.

BTW, this was meant as OK to apply?.

Cheers,
Ralf


___
Bug-libtool mailing list
Bug-libtool@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-libtool


Re: bug-report

2007-11-05 Thread Ralf Wildenhues
Hello Sergey,

* Sergey Pribilskiy wrote on Mon, Nov 05, 2007 at 09:51:33PM CET:
 
[...]
 configure:2033: checking for a BSD-compatible install
 configure:2089: result: /usr/bin/install -c -o root -g wheel
 configure:2100: checking whether build environment is sane
 configure:2137: error: newly created file is older than distributed files!
 Check your system clock

You should do just that and set your system clock.
Then this error should disappear.

Cheers,
Ralf


___
Bug-libtool mailing list
Bug-libtool@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-libtool


Re: Fix chdir-long.m4 caching

2007-10-11 Thread Ralf Wildenhues
[ http://thread.gmane.org/gmane.comp.lib.gnulib.bugs/7149/focus=5820 ]

* Eric Blake wrote on Tue, Oct 02, 2007 at 02:11:25PM CEST:
 According to Ralf Wildenhues on 10/1/2007 12:16 PM:
  
  I guess branch-1-5 Libtool is affected just as well, and I wonder
  whether, if we rename variables in Libtool, we need to provide the old
  names for compatibility as well.
 
 Nah.  They're cache variables; when they had the wrong name, the user
 could feasibly override the check, but the override was not saved between
 runs.  I think we're okay just upgrading to use new names, without
 worrying about priming the new names from the value of the old, nor in
 propagating the result of the new name back to the old, unless we can
 prove that the old name was in use elsewhere.

http://sisyphus.ru/srpm/aot/spec and
http://sisyphus.altlinux.org/srpm/libcairo/spec
indicate as such.  But I think in this case we're fine if we announce
the change in the NEWS file.

I'm committing the following hopefully-obvious changes to respective
Libtool branches.

Cheers,
Ralf

2007-10-11  Ralf Wildenhues  [EMAIL PROTECTED]

* libltdl/m4/libtool.m4 (_LT_COMPILER_PIC)
lt_cv_prog_compiler_pic_works: Renamed from
lt_prog_compiler_pic_works.
lt_cv_prog_compiler_static_works: Renamed from
lt_prog_compiler_static_works.
* NEWS: Update.

Index: NEWS
===
RCS file: /cvsroot/libtool/libtool/NEWS,v
retrieving revision 1.207
diff -u -r1.207 NEWS
--- NEWS1 Sep 2007 10:55:42 -   1.207
+++ NEWS11 Oct 2007 17:21:45 -
@@ -99,6 +99,9 @@
   - More robust parsing of mangled `.la' files inside libltdl, fixing a
 possible overrun and a crash due to memory exhaustion.
   - Fix compile command line for gcj on MinGW.
+  - Some configure variables have been renamed to fix caching:
+lt_prog_compiler_pic_works to lt_cv_prog_compiler_pic_works
+lt_prog_compiler_static_works to lt_cv_prog_compiler_static_works.
   - Loads of smaller bug fixes.
 
 
Index: libltdl/m4/libtool.m4
===
RCS file: /cvsroot/libtool/libtool/libltdl/m4/libtool.m4,v
retrieving revision 1.117
diff -u -r1.117 libtool.m4
--- libltdl/m4/libtool.m4   29 Aug 2007 20:54:53 -  1.117
+++ libltdl/m4/libtool.m4   11 Oct 2007 17:21:45 -
@@ -3967,7 +3967,7 @@
 #
 if test -n $_LT_TAGVAR(lt_prog_compiler_pic, $1); then
   _LT_COMPILER_OPTION([if $compiler PIC flag $_LT_TAGVAR(lt_prog_compiler_pic, 
$1) works],
-[_LT_TAGVAR(lt_prog_compiler_pic_works, $1)],
+[_LT_TAGVAR(lt_cv_prog_compiler_pic_works, $1)],
 [$_LT_TAGVAR(lt_prog_compiler_pic, $1)@[EMAIL PROTECTED]([$1],[],[ 
-DPIC],[m4_if([$1],[CXX],[ -DPIC],[])])], [],
 [case $_LT_TAGVAR(lt_prog_compiler_pic, $1) in
   |  *) ;;
@@ -3984,7 +3984,7 @@
 #
 wl=$_LT_TAGVAR(lt_prog_compiler_wl, $1) eval 
lt_tmp_static_flag=\$_LT_TAGVAR(lt_prog_compiler_static, $1)\
 _LT_LINKER_OPTION([if $compiler static flag $lt_tmp_static_flag works],
-  _LT_TAGVAR(lt_prog_compiler_static_works, $1),
+  _LT_TAGVAR(lt_cv_prog_compiler_static_works, $1),
   $lt_tmp_static_flag,
   [],
   [_LT_TAGVAR(lt_prog_compiler_static, $1)=])


2007-10-11  Ralf Wildenhues  [EMAIL PROTECTED]

* libtool.m4 (AC_LIBTOOL_PROG_COMPILER_PIC)
lt_cv_prog_compiler_pic_works: Renamed from
lt_prog_compiler_pic_works.
lt_cv_prog_compiler_static_works: Renamed from
lt_prog_compiler_static_works.
* NEWS: Update.

Index: NEWS
===
RCS file: /cvsroot/libtool/libtool/NEWS,v
retrieving revision 1.109.2.59
diff -u -r1.109.2.59 NEWS
--- NEWS1 Sep 2007 10:56:08 -   1.109.2.59
+++ NEWS11 Oct 2007 17:23:51 -
@@ -4,6 +4,9 @@
 * More robust parsing of mangled `.la' files inside libltdl, fixing a
   possible overrun and a crash due to memory exhaustion.
 * Fix compile command line for gcj on MinGW.
+* Some configure variables have been renamed to fix caching:
+  lt_prog_compiler_pic_works to lt_cv_prog_compiler_pic_works
+  lt_prog_compiler_static_works to lt_cv_prog_compiler_static_works.
 * Bug Fixes.
 
 New in 1.5.24: 2007-06-17; CVS version 1.5.23c, Libtool team:
Index: libtool.m4
===
RCS file: /cvsroot/libtool/libtool/Attic/libtool.m4,v
retrieving revision 1.314.2.187
diff -u -r1.314.2.187 libtool.m4
--- libtool.m4  16 Aug 2007 18:23:24 -  1.314.2.187
+++ libtool.m4  11 Oct 2007 17:23:53 -
@@ -5461,7 +5461,7 @@
 #
 if test -n $_LT_AC_TAGVAR(lt_prog_compiler_pic, $1); then
   AC_LIBTOOL_COMPILER_OPTION([if $compiler PIC flag 
$_LT_AC_TAGVAR(lt_prog_compiler_pic, $1) works],
-_LT_AC_TAGVAR(lt_prog_compiler_pic_works, $1),
+_LT_AC_TAGVAR(lt_cv_prog_compiler_pic_works, $1),
 [$_LT_AC_TAGVAR(lt_prog_compiler_pic, $1)ifelse([$1],[],[ 
-DPIC],[ifelse

Re: Fix chdir-long.m4 caching

2007-10-01 Thread Ralf Wildenhues
* Eric Blake wrote on Fri, Sep 28, 2007 at 06:33:45AM CEST:
  2006-09-26  Eric Blake  [EMAIL PROTECTED]
 and Ralf Wildenhues  [EMAIL PROTECTED]
  
 * lib/autoconf/general.m4 (AC_CACHE_VAL): Warn if cache-id is not
 cached.
 * tests/base.at (AC_CACHE_CHECK): Adjust test to expect this,
 also test that macro names and correct literals are not checked.
  
  Applied as follows:
[...]

Ahh, now I remember why I postponed that.  With a package using CVS HEAD
Libtool:

| configure.ac:1001: warning: 
AC_CACHE_VAL(_LT_TAGVAR(lt_prog_compiler_pic_works, ), ...): suspicious 
cache-id, must contain _cv_ to be cached
| ../../../autoconf/lib/autoconf/general.m4:1952: AC_CACHE_VAL is expanded 
from...
| ../../../autoconf/lib/autoconf/general.m4:1972: AC_CACHE_CHECK is expanded 
from...
| aclocal.m4:1282: _LT_COMPILER_OPTION is expanded from...
| aclocal.m4:3415: _LT_COMPILER_PIC is expanded from...
| aclocal.m4:5148: _LT_LANG_C_CONFIG is expanded from...
| aclocal.m4:142: _LT_SETUP is expanded from...
| aclocal.m4:75: LT_INIT is expanded from...
| configure.ac:1001: the top level
| configure.ac:1001: warning: AC_CACHE_VAL(lt_prog_compiler_static_works, ...): 
suspicious cache-id, must contain _cv_ to be cached
| aclocal.m4:1334: _LT_LINKER_OPTION is expanded from...
| configure.ac:1001: warning: 
AC_CACHE_VAL(_LT_TAGVAR(lt_prog_compiler_pic_works, CXX), ...): suspicious 
cache-id, must contain _cv_ to be cached
| aclocal.m4:5251: _LT_LANG_CXX_CONFIG is expanded from...
| aclocal.m4:785: _LT_LANG is expanded from...
| aclocal.m4:768: LT_LANG is expanded from...
| aclocal.m4:796: _LT_LANG_DEFAULT_CONFIG is expanded from...
| configure.ac:1001: warning: AC_CACHE_VAL(lt_prog_compiler_static_works_CXX, 
...): suspicious cache-id, must contain _cv_ to be cached
| configure.ac:1001: warning: 
AC_CACHE_VAL(_LT_TAGVAR(lt_prog_compiler_pic_works, F77), ...): suspicious 
cache-id, must contain _cv_ to be cached
| aclocal.m4:6559: _LT_LANG_F77_CONFIG is expanded from...
| configure.ac:1001: warning: AC_CACHE_VAL(lt_prog_compiler_static_works_F77, 
...): suspicious cache-id, must contain _cv_ to be cached
| configure.ac:1001: warning: 
AC_CACHE_VAL(_LT_TAGVAR(lt_prog_compiler_pic_works, FC), ...): suspicious 
cache-id, must contain _cv_ to be cached
| aclocal.m4:6700: _LT_LANG_FC_CONFIG is expanded from...
| configure.ac:1001: warning: AC_CACHE_VAL(lt_prog_compiler_static_works_FC, 
...): suspicious cache-id, must contain _cv_ to be cached

Bugs in both Autoconf and Libtool (the error messages seem a bit
inconsistent)?

I guess branch-1-5 Libtool is affected just as well, and I wonder
whether, if we rename variables in Libtool, we need to provide the old
names for compatibility as well.

FWIW, HEAD autoconf is about 8 sec, i.e., 25% faster on this package
(Open MPI) now.  Nice work, Eric!

Cheers,
Ralf


___
Bug-libtool mailing list
Bug-libtool@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-libtool


Re: ar(1) issue building coreutils on 64-bit AIX

2007-08-20 Thread Ralf Wildenhues
Hello all,

* Peter Rosin wrote on Fri, Aug 17, 2007 at 09:24:39PM CEST:
 
 Just pointing out that for libtool the archiver is never invoked as
 either of:
   $AR $AR_FLAGS cru ...
   $AR $AR_FLAGS x ...
   $AR $AR_FLAGS t ...
 it is always one of these instead:
   $AR $AR_FLAGS ...
   $AR x ...
   $AR t ...
 
 That usage of $AR_FLAGS seems consistent with your description
 of $ARFLAGS in automake.

Ah, so the chance of reconciliation with Automake's ARFLAGS just got a
wee bit better.  Except that Automake uses
  $(AR) $(ARFLAGS) LIBRARY OBJECTS...

and Libtool would like to not have a space after ${ARFLAGS}, if it wants
to support the w32 LIB program.  This, however, would not work with the
$(ARFLAGS) macro in a makefile: it is not portable to assume that 'make'
will honor trailing white space in a macro set in the makefile (besides
the fact that I think it is error-prone):  pmake for example does not,
contray to Posix.  However, it does honor it on the command line, like:
  pmake ARFLAGS=cru 

So then I thought of ugly hacks like
  AC_SUBST([ARFLAGS], [cru ''])

but that will then fail when $ARFLAGS is used in scripts like libtool
(could maybe be hacked around?), or
  AC_SUBST([ARFLAGS], [cru \\
 ])

but even that will not get pmake to behave.  I can get pmake to add a
space with this:
  ARFLAGS = cru
  ARFLAGS +=

but of course that is not portable either, and I haven't yet found a way
to add one for Solaris 2.6 make.

So pick and choose:
- drop $AR_FLAGS in libtool, instead use ${ARFLAGS} and keep in sync
  with Automake's idea of it
- keep $AR_FLAGS and allow for LIB to be used as archiver from within
  Libtool.

FWIW, I don't currently see how to easily get Automake to allow LIB as
archiver for *_LIBRARIES.

Cheers,
Ralf


___
Bug-libtool mailing list
Bug-libtool@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-libtool


Re: out of memory crash when accessing broken .la files

2007-08-15 Thread Ralf Wildenhues
* Dirk Mueller wrote on Wed, Aug 15, 2007 at 10:51:54AM CEST:
 On Wednesday, 15. August 2007, Ralf Wildenhues wrote:
 
  Could you post such a corrupted .la file, preferably gzip'ed so that it
  won't be harmed by mail transport?  How did it get corrupted BTW?
 
 The initial report came from a customer. He faced a filesystem corruption 
 that 
 caused several .la files on his system to be filled with NUL bytes. 

OK.  At least it wasn't some broken tool, or breakage in a Libtool
version we may not be aware of.

 I wasn`t able to investigate with his system, but I was able to reproduce it 
 trivially by fuzzing a valid file. I`m attaching what I used for testing. 

Thanks.  One problem is that .la file are also sourced by the libtool
script, thus the shell running the script may do all sorts of weird
things with broken files, or even just files with long lines, and really
I don't think there is any sensitive way to deal with this from inside
the script, apart from writing a full robust parser.  Note also that the
parser in ltdl.c is not all that robust to slight changes in the
structure.  libltdl assumes they do not come from an untrustworthy
source.  So maybe it's better your customer found out about the
corruption before the libtool script had a chance to go berserk...
I hope he replaces the disk before doing further work.

Anyway, your change causes also a small efficiency gain, as a strlen
is avoided; however, if the line is exactly line_len-1 bytes long,
it calls realloc unnecessarily and also eats part of the next line;
also let's avoid reading uninitialized memory in case we've already
needed to realloc before.  I've applied the patches below to branch-1-5
and HEAD, respectively.

Cheers, and thanks,
Ralf

HEAD:
2007-08-15  Dirk Mueller  [EMAIL PROTECTED]  (tiny change)
Ralf Wildenhues  [EMAIL PROTECTED]

* libltdl/ltdl.c (parse_dotla_file): Avoid a strlen.  When
reading .la files, cope with files that are not
newline-terminated.

Index: libltdl/ltdl.c
===
RCS file: /cvsroot/libtool/libtool/libltdl/ltdl.c,v
retrieving revision 1.255
diff -u -r1.255 ltdl.c
--- libltdl/ltdl.c  5 Aug 2007 11:06:14 -   1.255
+++ libltdl/ltdl.c  15 Aug 2007 21:29:31 -
@@ -1017,14 +1017,16 @@
 
   while (!feof (file))
 {
+  line[line_len-2] = '\0';
   if (!fgets (line, (int) line_len, file))
{
  break;
}
 
   /* Handle the case where we occasionally need to read a line
-that is longer than the initial buffer size.  */
-  while ((line[LT_STRLEN(line) -1] != '\n')  (!feof (file)))
+that is longer than the initial buffer size.
+ Behave even if the file contains NUL bytes due to corruption. */
+  while (line[line_len-2] != '\0'  line[line_len-2] != '\n'  !feof 
(file))
{
  line = REALLOC (char, line, line_len *2);
  if (!line)
@@ -1033,6 +1035,7 @@
  ++errors;
  goto cleanup;
}
+ line[line_len * 2 - 2] = '\0';
  if (!fgets (line[line_len -1], (int) line_len +1, file))
{
  break;


branch-1-5:
2007-08-15  Dirk Mueller  [EMAIL PROTECTED]  (tiny change)
Ralf Wildenhues  [EMAIL PROTECTED]

* libltdl/ltdl.c (try_dlopen): Avoid a strlen.  When reading .la
files, cope with files that are not newline-terminated.

Index: libltdl/ltdl.c
===
RCS file: /cvsroot/libtool/libtool/libltdl/ltdl.c,v
retrieving revision 1.174.2.28
diff -u -r1.174.2.28 ltdl.c
--- libltdl/ltdl.c  29 Jan 2007 21:54:10 -  1.174.2.28
+++ libltdl/ltdl.c  15 Aug 2007 13:44:37 -
@@ -3249,16 +3249,19 @@
   /* read the .la file */
   while (!feof (file))
{
+ line[line_len-2] = '\0';
  if (!fgets (line, (int) line_len, file))
{
  break;
}
 
  /* Handle the case where we occasionally need to read a line
-that is longer than the initial buffer size.  */
- while ((line[LT_STRLEN(line) -1] != '\n')  (!feof (file)))
+that is longer than the initial buffer size.
+Behave even if the file contains NUL bytes due to corruption. */
+ while (line[line_len-2] != '\0'  line[line_len-2] != '\n'  !feof 
(file))
{
  line = LT_DLREALLOC (char, line, line_len *2);
+ line[line_len*2 - 2] = '\0';
  if (!fgets (line[line_len -1], (int) line_len +1, file))
{
  break;


___
Bug-libtool mailing list
Bug-libtool@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-libtool


Re: Portland Group C++ compiler: please support both pgCC and pgcpp alias

2007-08-05 Thread Ralf Wildenhues
Hi Tilman,

* Tilman Koschnick wrote on Fri, Aug 03, 2007 at 05:43:22PM CEST:
 
 the Portland Group C++ compiler has two equivalent names that do the
 same: pgCC and pgcpp. libtool currently only supports the former one; it
 would be good if you could add support for both versions.

Thanks!  Applied to both branches as below.

Cheers,
Ralf

HEAD:
2007-08-05  Tilman Koschnick  [EMAIL PROTECTED]  (tiny change)

* libltdl/m4/libtool.m4 (_LT_COMPILER_PIC, _LT_LANG_CXX_CONFIG)
[ linux ]: Treat pgcpp as Portland Group C++ compiler as well.

Index: libltdl/m4/libtool.m4
===
RCS file: /cvsroot/libtool/libtool/libltdl/m4/libtool.m4,v
retrieving revision 1.113
diff -u -r1.113 libtool.m4
--- libltdl/m4/libtool.m4   22 Jul 2007 08:55:11 -  1.113
+++ libltdl/m4/libtool.m4   5 Aug 2007 11:38:39 -
@@ -3564,7 +3564,7 @@
_LT_TAGVAR(lt_prog_compiler_pic, $1)='-KPIC'
_LT_TAGVAR(lt_prog_compiler_static, $1)='-static'
;;
- pgCC*)
+ pgCC* | pgcpp*)
# Portland Group C++ compiler
_LT_TAGVAR(lt_prog_compiler_wl, $1)='-Wl,'
_LT_TAGVAR(lt_prog_compiler_pic, $1)='-fpic'
@@ -5815,10 +5815,10 @@
_LT_TAGVAR(export_dynamic_flag_spec, $1)='${wl}--export-dynamic'
_LT_TAGVAR(whole_archive_flag_spec, 
$1)='${wl}--whole-archive$convenience ${wl}--no-whole-archive'
;;
-  pgCC*)
+  pgCC* | pgcpp*)
 # Portland Group C++ compiler
case `$CC -V` in
-   *pgCC\ [[1-5]]*)
+   *pgCC\ [[1-5]]* | *pgcpp\ [[1-5]]*)
  _LT_TAGVAR(prelink_cmds, $1)='tpldir=Template.dir~
rm -rf $tpldir~
$CC --prelink_objects --instantiation_dir $tpldir $objs 
$libobjs $compile_deplibs~



branch-1-5:
2007-08-05  Tilman Koschnick  [EMAIL PROTECTED]  (tiny change)

* libtool.m4 (_LT_AC_LANG_CXX_CONFIG)
(AC_LIBTOOL_PROG_COMPILER_PIC): [ linux ]: Treat pgcpp as
Portland Group C++ compiler as well.

Index: libtool.m4
===
RCS file: /cvsroot/libtool/libtool/Attic/libtool.m4,v
retrieving revision 1.314.2.185
diff -u -r1.314.2.185 libtool.m4
--- libtool.m4  3 Jul 2007 05:10:45 -   1.314.2.185
+++ libtool.m4  5 Aug 2007 11:41:18 -
@@ -3376,7 +3376,7 @@
_LT_AC_TAGVAR(export_dynamic_flag_spec, $1)='${wl}--export-dynamic'
_LT_AC_TAGVAR(whole_archive_flag_spec, 
$1)='${wl}--whole-archive$convenience ${wl}--no-whole-archive'
;;
-  pgCC*)
+  pgCC* | pgcpp*)
 # Portland Group C++ compiler
_LT_AC_TAGVAR(archive_cmds, $1)='$CC -shared $pic_flag $predep_objects 
$libobjs $deplibs $postdep_objects $compiler_flags ${wl}-soname ${wl}$soname -o 
$lib'
_LT_AC_TAGVAR(archive_expsym_cmds, $1)='$CC -shared $pic_flag 
$predep_objects $libobjs $deplibs $postdep_objects $compiler_flags ${wl}-soname 
${wl}$soname ${wl}-retain-symbols-file ${wl}$export_symbols -o $lib'
@@ -5100,7 +5100,7 @@
_LT_AC_TAGVAR(lt_prog_compiler_pic, $1)='-KPIC'
_LT_AC_TAGVAR(lt_prog_compiler_static, $1)='-static'
;;
- pgCC*)
+ pgCC* | pgcpp*)
# Portland Group C++ compiler.
_LT_AC_TAGVAR(lt_prog_compiler_wl, $1)='-Wl,'
_LT_AC_TAGVAR(lt_prog_compiler_pic, $1)='-fpic'


___
Bug-libtool mailing list
Bug-libtool@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-libtool


Re: libtool generates incorrect option for Solaris ld

2007-07-02 Thread Ralf Wildenhues
* Vincent Lefevre wrote on Tue, Jul 03, 2007 at 01:22:35AM CEST:
 On 2007-07-02 22:40:37 +0200, Ralf Wildenhues wrote:
  Thanks for your feedback.  Does this patch work for you?
 
 Yes, it solves the problem. Thanks.

Thanks to both of you.  Applied.  

* Peter O'Gorman wrote on Tue, Jul 03, 2007 at 04:59:14AM CEST:
 On Mon, 2007-07-02 at 22:40 +0200, Ralf Wildenhues wrote:
  
  OK to apply to both branches?  Or do you think I should hack in
  $reload_cmds, or do a full link (I fear a situation where we may have to
  add some extra libraries for some obscure setup)?
 
 Yes, please commit. I don't think we have to worry about this too much,
 the ld is old and patches are available for it.

Well I worried that, say, the test would inadvertently fail on Solaris
12 when that exists, just to accommodate this old system.

Cheers,
Ralf


___
Bug-libtool mailing list
Bug-libtool@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-libtool


Re: Make check fails in libtool 2.1a (CVS snapshot) on AIX

2007-07-01 Thread Ralf Wildenhues
Hello Kyle,

* Kyle Stemen wrote on Sat, Jun 30, 2007 at 08:29:50AM CEST:
 I'm building libtool on AIX 5.3 release 4. I have gcc and other
 development tools installed from
 http://www-03.ibm.com/servers/aix/products/aixos/linux/download.html.
 
 Make check is failing on the CVS snapshot, 2.1a. It is also failing in
 the development release, 1.9f. I chose to include the failures from 2.1a
 because there are fewer of them.

Thanks.  We're much more interested in 2.1a data.

 Most of the tests fail with (see attachment):
 ld: 0711-317 ERROR: Undefined symbol: _GLOBAL__FD_libhello_so
 ld: 0711-317 ERROR: Undefined symbol: _GLOBAL__FI_libhello_so

I've seen this kind of failure before on HPUX 10.20 with GCC.
Which compiler version do you use, how is it configured?

 tagdemo-make.test fails with some missing C++ exports. G++ is broken on
 AIX with regards to templates, so that isn't a libtool problem.

It would still be good to see verbose error output here, even if just
for comparison.  Also, could you please run the new testsuite and see
how it fares (make check-local; see README for more information)?

Thanks,
Ralf


___
Bug-libtool mailing list
Bug-libtool@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-libtool


Re: SunStudio compilers

2007-05-15 Thread Ralf Wildenhues
Hello Dmitri,

Please keep the mailing list in Cc: so this information is conserved,
thanks.

* Dmitri Chubarov wrote on Mon, May 14, 2007 at 03:27:57PM CEST:

 That's right. The most recent version of libtool handles
 AC_LIBTOOL_PROG_COMPILER_PIC with Sun 5.9 C/C++ compilers correctly.

 Although, there was one failed test:
 29: C++ subdir-objects   FAILED (am-subdir.at:160)

 I attach the testsuite.log

Thanks.  I quote below the interesting part of the log.
The line containing RUNPATH gives a clue.  Please post (from the build
tree) the output of
  ./libtool --tag=CXX --config
  cat tests/testsuite.dir/29/subdir/subdemo

Are you using Gentoo?  Alternatively, which ld is used by sunCC, and why
does it have different hardcoding characteristics as suncc?  The former
seems to set only DT_RPATH, while the latter also sets DT_RUNPATH.
(I think `sunCC -v' should cause verbose output; otherwise, try `-#').
Let's see
  cd tests/testsuite.dir/29
  /bin/sh ./libtool --tag=CXX --mode=link sunCC -v -g -o subdir/subdemo 
subdir/main.o subdir/libsub.la -ldl

Libtool currently assumes that the different compilers (C, C++, Fortran)
it was configured for have the same behavior wrt. the setting of
shlibpath_overrides_runpath.  It seems that is not the case for you.
I wonder whether we need to make this a per-tag variable.  :-/

Thanks,
Ralf

[...]
 am-subdir.at:158: CONFIG_SHELL=$SHELL $SHELL ./configure $configure_options
 stderr:
 stdout:
 checking for a BSD-compatible install... /usr/bin/install -c
 checking whether build environment is sane... yes
 checking for gawk... gawk
 checking whether make sets $(MAKE)... yes
 checking for gcc... suncc
 checking for C compiler default output file name... a.out
 checking whether the C compiler works... yes
 checking whether we are cross compiling... no
 checking for suffix of executables...
 checking for suffix of object files... o
 checking whether we are using the GNU C compiler... no
 checking whether suncc accepts -g... yes
 checking for suncc option to accept ANSI C... none needed
 checking for style of include used by make... GNU
 checking dependency style of suncc... none
 checking whether suncc and cc understand -c and -o together... yes
 checking whether we are using the GNU C++ compiler... no
 checking whether sunCC accepts -g... yes
 checking dependency style of sunCC... none
 checking how to run the C++ preprocessor... sunCC -E
 checking build system type... x86_64-suse-linux
 checking host system type... x86_64-suse-linux
 checking for a sed that does not truncate output... /usr/bin/sed
 checking for egrep... grep -E
 checking for fgrep... grep -F
 checking for non-GNU ld... /usr/bin/ld -m elf_x86_64
 checking if the linker (/usr/bin/ld -m elf_x86_64) is GNU ld... yes
 checking for BSD- or MS-compatible name lister (nm)... /usr/bin/nm -B
 checking the name lister (/usr/bin/nm -B) interface... BSD nm
 checking whether ln -s works... yes
 checking the maximum length of command line arguments... 32768
 checking whether the shell understands some XSI constructs... yes
 checking whether the shell understands +=... yes
 checking for /usr/bin/ld -m elf_x86_64 option to reload object files... -r
 checking how to recognize dependent libraries... pass_all
 checking for ar... ar
 checking for strip... strip
 checking for ranlib... ranlib
 checking command to parse /usr/bin/nm -B output from suncc object... ok
 checking how to run the C preprocessor... suncc -E
 checking for ANSI C header files... yes
 checking for sys/types.h... yes
 checking for sys/stat.h... yes
 checking for stdlib.h... yes
 checking for string.h... yes
 checking for memory.h... yes
 checking for strings.h... yes
 checking for inttypes.h... yes
 checking for stdint.h... yes
 checking for unistd.h... yes
 checking for dlfcn.h... yes
 checking whether we are using the GNU C++ compiler... (cached) no
 checking whether sunCC accepts -g... (cached) yes
 checking dependency style of sunCC... (cached) none
 checking how to run the C++ preprocessor... sunCC -E
 checking for objdir... .libs
 checking for suncc option to produce PIC... -KPIC -DPIC
 checking if suncc PIC flag -KPIC -DPIC works... yes
 checking if suncc static flag -Bstatic works... no
 checking if suncc supports -c -o file.o... yes
 checking if suncc supports -c -o file.o... (cached) yes
 checking whether the suncc linker (/usr/bin/ld -m elf_x86_64 -m elf_x86_64) 
 supports shared libraries... yes
 checking dynamic linker characteristics...   RUNPATH /foo
 GNU/Linux ld.so
 checking how to hardcode library paths into programs... immediate
 checking whether stripping libraries is possible... yes
 checking if libtool supports shared libraries... yes
 checking whether to build shared libraries... yes
 checking whether to build static libraries... yes
 checking whether the sunCC linker (/usr/bin/ld -m elf_x86_64 -m elf_x86_64) 
 supports shared libraries... yes
 checking for sunCC option to produce PIC... -KPIC -DPIC
 checking 

Re: SunStudio compilers

2007-05-14 Thread Ralf Wildenhues
Hello Dmitri,

Thanks for the report.

* Dmitri Chubarov wrote on Sat, May 12, 2007 at 12:06:23PM CEST:
 When defining AC_LIBTOOL_PROG_COMPILER_PIC, the values libtool assigns
 for SunStudio 11 and 12 compilers on Linux are not correct. The values 
 should be
 lt_prog_compiler_wl='-Wl,'
 lt_prog_compiler_pic='-Kpic'
 lt_prog_compiler_static='-Bstatic'

 I attach a patch that should fix this problem. Applies to libtool 1.5.22.

This doesn't match my experience with Sun C/C++ 5.9 (I think it was that
version).  Libtool CVS HEAD has support for this on GNU/Linux, it uses
-KPIC as PIC flag, and `-Qoption ld ' for C++, `-Wl,' for C, and an
empty wl flag for Fortran; also it avoids matching for the compiler
name, as IIRC the suite uses multiple aliases.

It would be helpful if you could download and build a nightly snapshot
of CVS HEAD (see URL on the Libtool homepage) with your Sun compiler
suite, and send verbose testsuite output for both the old and the new
testsuite, as explained in README, for failures you encounter.

Thanks,
Ralf


___
Bug-libtool mailing list
Bug-libtool@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-libtool


Re: libtool-1.5.22 build (make check): 7 of 102 tests failed

2007-05-09 Thread Ralf Wildenhues
Hello Arto,

Thanks for the report.

* [EMAIL PROTECTED] wrote on Wed, May 09, 2007 at 08:55:12AM CEST:
 libtool-1.5.22 asks me to report:
 
 7 of 102 tests failed
 (10 tests were not run)
[...]
 the failed tests are ('grep FAIL $LOGFILE'):
 
 FAIL: depdemo-make.test
 FAIL: depdemo-make.test
 FAIL: depdemo-make.test
 FAIL: depdemo-make.test
 FAIL: mdemo2-make.test
 FAIL: mdemo2-exec.test
 FAIL: link-order.test
 
 System:sparc-sun-solaris2.6
 Compiler:  gcc-4.1.2
 Build: building in obj directory separate from source directory,
source directory is read-only and owned by a different
user than the building user (this turned out to be the
problem in some other GNU packages, because permission
bits of some test files in the distribution were not set
correctly, for example, tests not readable or executable
by group/other. Have not looked at the libtools tests,
though)

Weird, last time I checked Solaris 2.6, there were no such failures
(a couple of other tests failed though, for independent reasons).
Could you rerun the testsuite verbosely (see README for how) and
post the output (packed with gzip or bzip2)?

The Solaris 2.6 make has rather limited VPATH support, needed for
separating source and build tree (but so far I thought it was enough
for Libtool-1.5.22).  Are you using GNU make or Solaris make?

Thanks,
Ralf


___
Bug-libtool mailing list
Bug-libtool@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-libtool


Re: handling of -B with libtool

2007-05-09 Thread Ralf Wildenhues
* Mike Frysinger wrote on Tue, May 08, 2007 at 06:34:31PM CEST:
 
 -Bstatic would be valid for the compiler driver regardless ... if you had a 
 directory in $PWD named static ...

If you have a directory named static and used that as argument for -B,
you deserve trouble.  Also, isn't -B to be fed an absolute path?

 unless you mean invoking `ld` directly ?  -B to the compiler driver and -B to 
 the linker have very diff meanings ...

Sure.  But in general, libtool may invoke either the compiler driver or
the linker directly.  It doesn't do that for GCC any more, I think, but
it used to.

 i'm trying to use:
 LDFLAGS = -B/some/path
 in the build environment and things break when libtool is involved and it 
 tries to link a shared library because it strips this -B flag ...

You can work around it using
  -Wc,-B/some/path
or
  -Xcompiler -B/some/path
for now.

Cheers,
Ralf


___
Bug-libtool mailing list
Bug-libtool@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-libtool


Re: handling of -B with libtool

2007-05-08 Thread Ralf Wildenhues
Hello Mike,

* Mike Frysinger wrote on Tue, May 08, 2007 at 12:41:44AM CEST:
 looking through current libtool code, i dont see any places that it allows 
 gcc's -B arguments through to the linking stage ... is there such code

Currently not.  It would have to be at least a bit smart, too, to avoid
passing through stuff like -Bstatic etc.

 or does it need to be added to the allowed flag list for valid linking
 flags ?

Not if it was passed in $CC, as in
  ./configure CC='gcc -B /foo'

which seems only prudent, as it makes little sense to sometimes use -B
and sometimes not use it within one build, AFAICS.

Is there any problem you have encountered?

Cheers,
Ralf


___
Bug-libtool mailing list
Bug-libtool@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-libtool


Re: linking got broken on MacOSX

2007-05-02 Thread Ralf Wildenhues
Hello Peter, Christoph, all,

* Peter O'Gorman wrote on Wed, May 02, 2007 at 02:22:28PM CEST:

 Ralf, if you don't have a patch handy, I can look into this.

I don't care if you do the work or I, but it was me who broke it.  ;-)
All I can say is that a test case should be added, and that I probably
don't have any time before Sunday at the earliest, so if you beat me to
it, I certainly won't mind.

Cheers,
Ralf


___
Bug-libtool mailing list
Bug-libtool@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-libtool


Re: .ctor section of shared libraries with PathScale compiler

2007-04-26 Thread Ralf Wildenhues
Thanks Noah.  I installed that, but changed the constant to be a #define
in the header file.

To ease Jeff's concerns about -shared: if libtool supports shared
libraries for the system/compiler in question, then they will be
preferred over static libs.  So -shared is not needed in order for the
test to be effective.  And we don't want it to fail in the static-only
case.

Cheers,
Ralf

2007-04-27  Noah Misch  [EMAIL PROTECTED]

* tests/ctor.at: New file.
* Makefile.am (TESTSUITE_AT): Add tests/ctor.at.

Index: Makefile.am
===
RCS file: /cvsroot/libtool/libtool/Makefile.am,v
retrieving revision 1.217
diff -u -r1.217 Makefile.am
--- Makefile.am 24 Apr 2007 20:46:17 -  1.217
+++ Makefile.am 26 Apr 2007 22:32:48 -
@@ -448,6 +448,7 @@
  tests/nonrecursive.at \
  tests/recursive.at \
  tests/template.at \
+ tests/ctor.at \
  tests/early-libtool.at \
  tests/deplibs-ident.at \
  tests/stresstest.at \
--- /dev/null   2007-04-15 17:46:43.220064750 +0200
+++ tests/ctor.at   2007-04-27 00:31:36.0 +0200
@@ -0,0 +1,67 @@
+# ctor.at -- Test constructors via C++-*- Autotest -*-
+#
+#   Copyright (C) 2007 Free Software Foundation, Inc.
+#   Written by Noah Misch, 2007
+#
+#   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_BANNER([Constructors.])
+
+AT_SETUP([C++ static constructors])
+LT_AT_TAG([CXX])
+AT_KEYWORDS([libtool])
+
+AT_DATA(class.h,
+[[#define magic 0xaabbccdd
+class Foo {
+public:
+   Foo() { bar = magic; }
+   unsigned bar;
+};
+
+extern Foo instance;
+]])
+
+AT_DATA(libctor.cpp,
+[[#include class.h
+Foo instance;
+]])
+
+AT_DATA(main.cpp,
+[[#include class.h
+
+int main(int argc, char **argv)
+{
+  return instance.bar != magic;
+}
+]])
+
+AT_CHECK([$LIBTOOL --tag=CXX --mode=compile $CXX $CPPFLAGS $CXXFLAGS \
+ -c libctor.cpp -o libctor.lo], [0], [ignore], [ignore])
+AT_CHECK([$LIBTOOL --tag=CXX --mode=compile $CXX $CPPFLAGS $CXXFLAGS \
+ -c main.cpp -o main.lo], [0], [ignore], [ignore])
+AT_CHECK([$LIBTOOL --tag=CXX --mode=link $CXX $CXXFLAGS $LDFLAGS \
+ libctor.lo -o libctor.la -rpath /none], [0], [ignore], [ignore])
+AT_CHECK([$LIBTOOL --tag=CXX --mode=link $CXX $CXXFLAGS $LDFLAGS \
+ main.lo libctor.la -o main], [0], [ignore], [ignore])
+
+LT_AT_EXEC_CHECK([./main], [0])
+
+AT_CLEANUP


___
Bug-libtool mailing list
Bug-libtool@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-libtool


Re: Libtool fails to build working binary when -no-install is used

2007-04-10 Thread Ralf Wildenhues
* Peter O'Gorman wrote on Wed, Apr 04, 2007 at 12:06:58AM CEST:
 On Apr 3, 2007, at 4:44 PM, Ralf Wildenhues wrote:
 
 Do I understand correctly that Darwin has no way to hardcode library
 paths (other than the ones given by -install-name)?  OK to apply and
 backport?  It fixes the stresstest failure exposed by my last patch.
 
 Yes. Sorry, I have not been watching the list as closely as I should  
 be. This looks okay to me, please apply.

Done now, to both branches, thanks for the review!

Cheers,
Ralf


___
Bug-libtool mailing list
Bug-libtool@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-libtool


Re: libtool 1.5.23b tests on ia64-hp-hpux11.23 and alphaev56-dec-osf4.0f

2007-04-06 Thread Ralf Wildenhues
Hello Dave,

Thanks for the report.

* deckrider wrote on Fri, Apr 06, 2007 at 01:30:26AM CEST:
 
  I ran libtool 1.5.23b tests on ia64-hp-hpux11.23 and alphaev56-dec-osf4.0f.
 
  ia64-hp-hpux11.23 had only one fail: hardcode.test.

Known failure.

  alphaev56-dec-osf4.0f. reported that All 103 tests passed, even though
  this came out during the test cycle:
 
  PASS: demo-inst.test
  PASS: hardcode.test
  31897:.libs/lt-hell: /sbin/loader: Error: Unresolved symbol in
  .libs/lt-hell: nothing
[... more warnings that escaped ...]

Nothing to worry about.  These tests test broken programs on purpose.
I don't know how to shut up the runtime linker properly though.

Cheers,
Ralf


___
Bug-libtool mailing list
Bug-libtool@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-libtool


Re: Libtool fails to build working binary when -no-install is used

2007-04-03 Thread Ralf Wildenhues
Hi Peter, all,

* quoting myself:
 * Simon Josefsson wrote on Thu, Mar 29, 2007 at 12:17:32PM CEST:
 
  /bin/sh ../libtool --tag=CC   --mode=link gcc  -DLIBSSH2_DARWIN -I/ 
  usr/include -I/usr/include -no-install -L/usr/lib -lcrypto -L/usr/lib  
  -lz -o simple simple.o ../src/libssh2.la
  mkdir .libs
  gcc -DLIBSSH2_DARWIN -I/usr/include -I/usr/include -o simple  
  simple.o  -L/usr/lib ../src/.libs/libssh2.dylib -lcrypto -lz
  make  check-TESTS
  dyld: Library not loaded: /usr/local/lib/libssh2.1.dylib
 Referenced from: /Users/daniel/Desktop/libssh2/tests/./simple
 Reason: image not found
  FAIL: simple
 
 Looks like a Darwin-related (hint, hint! ;-) bug to me.

Do I understand correctly that Darwin has no way to hardcode library
paths (other than the ones given by -install-name)?  OK to apply and
backport?  It fixes the stresstest failure exposed by my last patch.

Cheers,
Ralf

* libltdl/config/ltmain.m4sh (func_mode_link) -no-install
[ darwin ]: Treat like `-no-fast-install', as we cannot
hardcode.  Report by Simon Josefsson.

Index: libltdl/config/ltmain.m4sh
===
RCS file: /cvsroot/libtool/libtool/libltdl/config/ltmain.m4sh,v
retrieving revision 1.71
diff -u -r1.71 ltmain.m4sh
--- libltdl/config/ltmain.m4sh  25 Mar 2007 12:12:42 -  1.71
+++ libltdl/config/ltmain.m4sh  3 Apr 2007 21:43:29 -
@@ -2770,9 +2770,9 @@
 
   -no-install)
case $host in
-   *-*-cygwin* | *-*-mingw* | *-*-pw32* | *-*-os2*)
+   *-*-cygwin* | *-*-mingw* | *-*-pw32* | *-*-os2* | *-*-darwin*)
  # The PATH hackery in wrapper scripts is required on Windows
- # in order for the loader to find any dlls it needs.
+ # and Darwin in order for the loader to find any dlls it needs.
  func_warning \`-no-install' is ignored for $host
  func_warning assuming \`-no-fast-install' instead
  fast_install=no


___
Bug-libtool mailing list
Bug-libtool@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-libtool


Re: Libtool fails to build working binary when -no-install is used

2007-03-29 Thread Ralf Wildenhues
Hi Simon,

Thanks for the bug report.

* Simon Josefsson wrote on Thu, Mar 29, 2007 at 12:17:32PM CEST:

 /bin/sh ../libtool --tag=CC   --mode=link gcc  -DLIBSSH2_DARWIN -I/ 
 usr/include -I/usr/include -no-install -L/usr/lib -lcrypto -L/usr/lib  
 -lz -o simple simple.o ../src/libssh2.la
 mkdir .libs
 gcc -DLIBSSH2_DARWIN -I/usr/include -I/usr/include -o simple  
 simple.o  -L/usr/lib ../src/.libs/libssh2.dylib -lcrypto -lz
 make  check-TESTS
 dyld: Library not loaded: /usr/local/lib/libssh2.1.dylib
Referenced from: /Users/daniel/Desktop/libssh2/tests/./simple
Reason: image not found
 FAIL: simple

Looks like a Darwin-related (hint, hint! ;-) bug to me.

Note to self: expose -no-install in testsuite ((also) in stresstest.at
as optional additional flag to `main' and `dlself').  No wonder it
doesn't work: it's not covered in the testsuite.  :-/

I think you should be able to work around it by adding
  -R ../src

to the link flags for `simple' (untested, please try it!  self: also put
in testsuite), that should be more efficient than dropping -no-install
and thus having the wrapper everywhere.  Please also note that on w32
you'll get (a warning and) a wrapper regardless, as there's no way to
hardcode there.

Cheers,
Ralf


___
Bug-libtool mailing list
Bug-libtool@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-libtool


Re: cygpath usage

2007-03-29 Thread Ralf Wildenhues
Hello Akim,

Thanks for the bug report.

* Akim Demaille wrote on Thu, Mar 29, 2007 at 05:13:01PM CEST:
 This is libtool 1.5.22, and I have seen the same problem with 1.5.23a.

FWIW, this is fixed in HEAD.

 # Fix the shell variable $srcfile for the compiler.
 fix_srcfile_path=`cygpath -w $srcfile`
 
 which obviously should have been
 
 # Fix the shell variable $srcfile for the compiler.
 fix_srcfile_path='`cygpath -w $srcfile`'

I'm applying the obvious fix below.  ;-)

 There is gonna be hair for quotes.  Why don't you use
 functions?  My usual $0.02 :)

Well if your $0.02 were multiplied by an, umm, large factor, you could
probably pay someone (else) to do a nice clean rewrite of Libtool.
Alternatively, I'd welcome you to do to Libtool what you did to Autoconf
some years ago.

Cheers,
Ralf

2007-03-29  Ralf Wildenhues  [EMAIL PROTECTED]

* libtool.m4 (AC_LIBTOOL_CONFIG) fix_srcfile_path: This
variable needs escaping, too.
Report by Akim Demaille.

Index: libtool.m4
===
RCS file: /cvsroot/libtool/libtool/Attic/libtool.m4,v
retrieving revision 1.314.2.174
diff -u -r1.314.2.174 libtool.m4
--- libtool.m4  18 Mar 2007 18:09:57 -  1.314.2.174
+++ libtool.m4  29 Mar 2007 17:09:33 -
@@ -4266,6 +4266,7 @@
 _LT_AC_TAGVAR(module_cmds, $1) \
 _LT_AC_TAGVAR(module_expsym_cmds, $1) \
 _LT_AC_TAGVAR(lt_cv_prog_compiler_c_o, $1) \
+_LT_AC_TAGVAR(fix_srcfile_path, $1) \
 _LT_AC_TAGVAR(exclude_expsyms, $1) \
 _LT_AC_TAGVAR(include_expsyms, $1); do
 
@@ -4637,7 +4638,7 @@
 sys_lib_dlsearch_path_spec=$lt_sys_lib_dlsearch_path_spec
 
 # Fix the shell variable \$srcfile for the compiler.
-fix_srcfile_path=$_LT_AC_TAGVAR(fix_srcfile_path, $1)
+fix_srcfile_path=$lt_fix_srcfile_path
 
 # Set to yes if exported symbols are required.
 always_export_symbols=$_LT_AC_TAGVAR(always_export_symbols, $1)


___
Bug-libtool mailing list
Bug-libtool@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-libtool


Re: Bug in LT_PROG_GCJ ?

2007-03-18 Thread Ralf Wildenhues
Hello Steve, and sorry for the delay,

* Ralf Wildenhues wrote on Fri, Mar 16, 2007 at 06:34:34PM CET:
 * Steve Ellcey wrote on Fri, Mar 16, 2007 at 06:30:38PM CET:
AC_DEFUN([LT_PROG_GCJ],
[m4_ifdef([AC_PROG_GCJ], [AC_PROG_GCJ],
  [m4_ifdef([A][M_PROG_GCJ], [A][M_PROG_GCJ],
[AC_CHECK_TOOL(GCJ, gcj,)
  test x${GCJFLAGS+set} = xset || GCJFLAGS=-g -O2
  AC_SUBST(GCJFLAGS)])])dnl
])
 [...]
   Does changing the line to
   AC_SUBST(GCJFLAGS)])])[]dnl
   
   work?

Applied to HEAD.  I put you in THANKS, too.

Cheers,
Ralf

2007-03-18  Ralf Wildenhues  [EMAIL PROTECTED]

* libltdl/m4/libtool.m4 (LT_PROG_GCJ): Avoid M4 expansion error
that caused `dnl' to be merged to the previous word.
* THANKS: Update.
Report by Steve Ellcey.

Index: libltdl/m4/libtool.m4
===
RCS file: /cvsroot/libtool/libtool/libltdl/m4/libtool.m4,v
retrieving revision 1.98
diff -u -r1.98 libtool.m4
--- libltdl/m4/libtool.m4   26 Feb 2007 07:44:23 -  1.98
+++ libltdl/m4/libtool.m4   18 Mar 2007 17:36:03 -
@@ -6844,7 +6844,7 @@
   [m4_ifdef([A][M_PROG_GCJ], [A][M_PROG_GCJ],
 [AC_CHECK_TOOL(GCJ, gcj,)
   test x${GCJFLAGS+set} = xset || GCJFLAGS=-g -O2
-  AC_SUBST(GCJFLAGS)])])dnl
+  AC_SUBST(GCJFLAGS)])])[]dnl
 ])
 
 # Old name:


___
Bug-libtool mailing list
Bug-libtool@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-libtool


Re: Bug in LT_PROG_GCJ ?

2007-03-16 Thread Ralf Wildenhues
* Steve Ellcey wrote on Fri, Mar 16, 2007 at 06:30:38PM CET:
   AC_DEFUN([LT_PROG_GCJ],
   [m4_ifdef([AC_PROG_GCJ], [AC_PROG_GCJ],
 [m4_ifdef([A][M_PROG_GCJ], [A][M_PROG_GCJ],
   [AC_CHECK_TOOL(GCJ, gcj,)
 test x${GCJFLAGS+set} = xset || GCJFLAGS=-g -O2
 AC_SUBST(GCJFLAGS)])])dnl
   ])
[...]
  Does changing the line to
  AC_SUBST(GCJFLAGS)])])[]dnl
  
  work?

 Were you (or maybe someone else) going to make this change in the
 libtool sources?

Yes.  However my Libtool work needs to wait until the weekend.  Sorry.

Cheers,
Ralf


___
Bug-libtool mailing list
Bug-libtool@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-libtool


Re: s390 Linux jpeg-6b problem

2007-03-07 Thread Ralf Wildenhues
Allow me to keep the mailing list in Cc:, thanks.

* Gnew, John C wrote on Wed, Mar 07, 2007 at 06:55:36PM CET:
 The tarball is at http://www.ijg.org/files/jpegsrc.v6b.tar.gz

Wow.  That's almost 9 years old!  Still it works fine here once I
replace the config.guess and config.sub files with newer ones from
http://savannah.gnu.org/cgi-bin/viewcvs/~checkout~/config/config/config.guess
http://savannah.gnu.org/cgi-bin/viewcvs/~checkout~/config/config/config.sub
:-)

 I manually changed the Makefile and it compiled just fine.

OK, good.

Cheers,
Ralf


___
Bug-libtool mailing list
Bug-libtool@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-libtool


Re: libtool-1.15.23b (i386-unknown-freebsd4.3) check results

2007-02-23 Thread Ralf Wildenhues
* David Fang wrote on Fri, Feb 23, 2007 at 10:26:06PM CET:
  This failure is because $LD is set wrongly, see the configure output
  earlier:
 
  | checking for ld used by ccache gcc-3.4.0... g++-3.4.0

 % ccache gcc-3.4.0 -print-prog-name=ld
 ld

Hmm.  Do you have $LD set?  Does ccache set this variable?
Also I noted configure computes a dependency style of none.
Looks like another ccache-induced artifact I cannot reproduce here.

Cheers,
Ralf


___
Bug-libtool mailing list
Bug-libtool@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-libtool


Re: libtool-1.15.23b (i386-unknown-freebsd4.3) check results

2007-02-22 Thread Ralf Wildenhues
Hello David,

* David Fang wrote on Thu, Feb 22, 2007 at 05:17:17AM CET:
 Here are my results for libtool-1.15.23b on
   i386-unknown-freebsd4.3 (most PASSes omitted):

 Some relevant excerpts and notes:
 
 --8 snip 8---
 = Finding libtool.m4's guesses at hardcoding values
 = Searching for hardcoded library directories in each program
 .libs was hardcoded in `hc-direct', as libtool expected
 .libs was hardcoded in `hc-libflag', as libtool expected
 `hc-libpath' was not linked properly, which fooled libtool
 .libs was not hardcoded in `hc-minusL', as libtool expected
 FAIL: hardcode.test

Hmm.

 --8 snip 8---
 /ufs/vlsi/fang/freebsd/bin/bash ./libtool --tag=CC   --mode=link ccache
 gcc-3.4.0  -g -O2 -no-undefined -version-info 3:12:1  -o libhello.la -rpath
 /tmp_mnt/cancun/home2/fang/local/src/libtool-1.5.23b/i386-freebsd4.3-build/tests/_inst/lib
 libhello_la-longer_file_name_hello.lo libhello_la-longer_file_name_foo.lo
 libhello_la-longer_file_name_foo2.lo -lm
 creating reloadable object files...
 creating a temporary reloadable object file: .libs/libhello.la-3.o
 g++-3.4.0 -r -o .libs/libhello.la-1.o
 .libs/libhello_la-longer_file_name_hello.o
 
 /usr/libexec/elf/ld: cannot find -lm
 collect2: ld returned 1 exit status

The command should be something like
  ld -r -o .libs/libhello.la-1.o .libs/libhello_la-longer_file_name_hello.o

This failure is because $LD is set wrongly, see the configure output
earlier:

| checking for ld used by ccache gcc-3.4.0... g++-3.4.0
| checking if the linker (g++-3.4.0) is GNU ld... no
| checking for g++-3.4.0 option to reload object files... -r

Please show the output of both of these:
  gcc-3.4.0 -print-prog-name=ld
  ccache gcc-3.4.0 -print-prog-name=ld

 === Running tagdemo-exec.test
 Executing uninstalled programs in ../tagdemo
 /usr/libexec/ld-elf.so.1: Cannot open ./.libs/libbaz.so
 ../../tests/tagdemo-exec.test: cannot execute ../tagdemo/tagdemo
 FAIL: tagdemo-exec.test
 --8 snip 8---
 This looks like the same failure I see on my own hello-world demo
 project: an installed binary linked to a shlib, still uses a hardcoded
 path to the *build* directory, not the install directory.

No.  The test is trying to execute an uninstalled program, you are
trying to execute an installed program.  Different situation.

I don't understand why this test fails though.  Could you try without
ccache?  Things should work with ccache as well, but it seems they
don't.

Thanks,
Ralf


___
Bug-libtool mailing list
Bug-libtool@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-libtool


Re: [libtool 2.1a] testsuite: 25 49 failed (cockpit error)

2007-02-19 Thread Ralf Wildenhues
* Lynn Ten Eyck wrote on Fri, Feb 16, 2007 at 03:53:29PM CET:
 On Fri, 2007-02-16 at 14:11 +0100, Ralf Wildenhues wrote:
 
  The failure of 25 is new to me.  Do you have a libltdl.so.7 installed in
  a place where the link editor finds it by default?  If yes, is there a
  libltdl.la file installed alongside with it?  If not, why not, who
  removed it?  It should be present.
 
 This was a cockpit error.  I did ./configure  make  make install,
 which installed the new system in /usr/local/.  My path was set to pick
 up the new versions of the excutables, but the linker was not told where
 to find the libraries.

But that shouldn't be necessary.  If the libltdl.la file exists, then 
libtool should hard-code the path to the library into the ltdldemo
program.

 lynn ls -l /usr/local/lib/libltd*
 -rw-r--r-- 1 root root 189678 Feb 15 21:55 /usr/local/lib/libltdl.a
 -rwxr-xr-x 1 root root950 Feb 15 21:55 /usr/local/lib/libltdl.la*
 lrwxrwxrwx 1 root root 16 Feb 15 21:55 /usr/local/lib/libltdl.so - 
 libltdl.so.7.0.0*
 lrwxrwxrwx 1 root root 16 Feb 15 21:55 /usr/local/lib/libltdl.so.7 - 
 libltdl.so.7.0.0*
 -rwxr-xr-x 1 root root 113165 Feb 15 21:55 /usr/local/lib/libltdl.so.7.0.0*
 
 /usr/local/lib64 is empty.
 
 I re-ran the tests with the LD_LIBRARY_PATH set to explicitly include
 /usr/local/lib.  Test 25 passed, and test 49 gave the known failure. 
 If you would like the log, I can send it, but I doubt if there is any
 new information in it.  I turned on the -v flag for verbose output.

Yes, please do not set LD_LIBRARY_PATH, then run
  make check-local TESTSUITEFLAGS='-v -d -x 25'
  cd tests/testsuite.dir

and send tests/testsuite.dir/25/config.log.

Thanks,
Ralf


___
Bug-libtool mailing list
Bug-libtool@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-libtool


Fix check for new libltdl (was: [libtool 2.1a] testsuite: 25 49 failed)

2007-02-19 Thread Ralf Wildenhues
* quoting myself, from Fri, Feb 16, 2007 at 02:11:34PM CET:
 
 There is still another failure in libltdl/m4/ltdl.m4: it won't reject
 the external libltdl if only libtldl.so is new enough but ltdl.h is too
 old (can happen if LDFLAGS was set correctly but CPPFLAGS wasn't).  In
 that case there will be a link error due to `lt_preloaded_symbols' being
 undefined.  Guess I'll fix that too...

I'm applying the following patch, which hopefully improves things in
this area.

Cheers,
Ralf

2007-02-19  Ralf Wildenhues  [EMAIL PROTECTED]

* libltdl/m4/ltdl.m4 (LT_WITH_LTDL): Fix detection of new enough
libltdl by actually checking for the declaration of
lt_dlinterface_register in ltdl.h with AC_CHECK_DECL.
Remove redundant configure output line.

Index: libltdl/m4/ltdl.m4
===
RCS file: /cvsroot/libtool/libtool/libltdl/m4/ltdl.m4,v
retrieving revision 1.31
diff -u -r1.31 ltdl.m4
--- libltdl/m4/ltdl.m4  27 Jan 2007 16:45:38 -  1.31
+++ libltdl/m4/ltdl.m4  19 Feb 2007 09:08:00 -
@@ -5,7 +5,7 @@
 # unlimited permission to copy and/or distribute it, with or without
 # modifications, as long as this notice is preserved.
 
-# serial 11 LTDL_INIT
+# serial 12 LTDL_INIT
 
 # LT_CONFIG_LTDL_DIR(DIRECTORY, [LTDL-MODE])
 # --
@@ -182,18 +182,17 @@
 if test x$with_included_ltdl != xyes; then
   # We are not being forced to use the included libltdl sources, so
   # decide whether there is a useful installed version we can use.
-  lt_dlinterface_register_found=no
   AC_CHECK_HEADER([ltdl.h],
-  [AC_CHECK_LIB([ltdl], [lt_dlinterface_register],
-  [with_included_ltdl=no],
-  [with_included_ltdl=yes])],
-
-  [],
+  [AC_CHECK_DECL([lt_dlinterface_register],
+  [AC_CHECK_LIB([ltdl], [lt_dlinterface_register],
+  [with_included_ltdl=no],
+  [with_included_ltdl=yes])],
+  [with_included_ltdl=yes],
+  [AC_INCLUDES_DEFAULT
+   #include ltdl.h])],
+  [with_included_ltdl=yes],
   [AC_INCLUDES_DEFAULT]
   )
-  AC_MSG_CHECKING([for lt_dlinterface_register in ltdl.h])
-  test x$with_included_ltdl = xno  lt_dlinterface_register_found=yes
-  AC_MSG_RESULT([$lt_dlinterface_register_found])
 fi
 
 if test x$enable_ltdl_install != xyes; then


___
Bug-libtool mailing list
Bug-libtool@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-libtool


Re: libtool issue with latest Sun cc compiler on Linux

2007-02-17 Thread Ralf Wildenhues
* Terry D. Dontje wrote on Fri, Feb 16, 2007 at 08:45:09PM CET:
 Very interesting, I think it is coming from ld look at the following:
[...]
 [EMAIL PROTECTED]:~/tmp/compissue ld --version
 GNU ld version 2.16.91.0.7-amd-sles9 20060317

Thanks, that's what I wanted to know.

Please note that currently, for portability it is necessary that you add
at least one object file to a library.  I'm slowly working towards
lifting this restriction in Libtool (and Automake), but am still a ways
away from it.  Adding such an object is also likely to be more efficient
than the worst-case fix in Libtool: extracting one of the convenience
archives and listing all its objects on the command line.  Note that
while it may be possible to have Libtool add a dummy object itself,
doing this portably is a pain.  I'd be very reluctant to go that route.

I'm removing the /dev/null, as shown below, in HEAD and branch-1-5,
and adding you to THANKS.

Cheers,
Ralf

HEAD:
2007-02-17  Ralf Wildenhues  [EMAIL PROTECTED]

* libltdl/m4/libtool.m4 (_LT_LINKER_SHLIBS) [ linux ]
whole_archive_flag_spec: For Sun C/C++ 5.9, do not add
/dev/null as dummy object, it fails with GNU ld version
2.16.91.0.7-amd-sles9.  Report by Terry D. Dontje.
* THANKS: Update.

Index: libltdl/m4/libtool.m4
===
RCS file: /cvsroot/libtool/libtool/libltdl/m4/libtool.m4,v
retrieving revision 1.94
diff -u -r1.94 libtool.m4
--- libltdl/m4/libtool.m4   14 Feb 2007 18:55:24 -  1.94
+++ libltdl/m4/libtool.m4   17 Feb 2007 08:14:54 -
@@ -4194,7 +4194,7 @@
esac
case `$CC -V 21 | sed 5q` in
*Sun\ C*)   # Sun C 5.9
- _LT_TAGVAR(whole_archive_flag_spec, 
$1)='${wl}--whole-archive`new_convenience=; for conv in $convenience\\; do 
test -z \$conv\ || new_convenience=\$new_convenience,$conv\; done; $ECHO 
\$new_convenience\` ${wl}--no-whole-archive /dev/null'
+ _LT_TAGVAR(whole_archive_flag_spec, 
$1)='${wl}--whole-archive`new_convenience=; for conv in $convenience\\; do 
test -z \$conv\ || new_convenience=\$new_convenience,$conv\; done; $ECHO 
\$new_convenience\` ${wl}--no-whole-archive'
  tmp_sharedflag='-G' ;;
*Sun\ F*)   # Sun Fortran 8.3
  tmp_sharedflag='-G' ;;

branch-1-5:
2007-02-17  Ralf Wildenhues  [EMAIL PROTECTED]

* libtool.m4 (AC_LIBTOOL_PROG_LD_SHLIBS) [ linux ]
whole_archive_flag_spec: For Sun C/C++ 5.9, do not add
/dev/null as dummy object, it fails with GNU ld version
2.16.91.0.7-amd-sles9.  Report by Terry D. Dontje.
* THANKS: Update.

Index: libtool.m4
===
RCS file: /cvsroot/libtool/libtool/Attic/libtool.m4,v
retrieving revision 1.314.2.171
diff -u -r1.314.2.171 libtool.m4
--- libtool.m4  11 Feb 2007 13:37:02 -  1.314.2.171
+++ libtool.m4  17 Feb 2007 08:16:28 -
@@ -5691,7 +5691,7 @@
esac
case `$CC -V 21 | sed 5q` in
*Sun\ C*)   # Sun C 5.9
- _LT_AC_TAGVAR(whole_archive_flag_spec, 
$1)='${wl}--whole-archive`new_convenience=; for conv in $convenience\\; do 
test -z \$conv\ || new_convenience=\$new_convenience,$conv\; done; $echo 
\$new_convenience\` ${wl}--no-whole-archive /dev/null'
+ _LT_AC_TAGVAR(whole_archive_flag_spec, 
$1)='${wl}--whole-archive`new_convenience=; for conv in $convenience\\; do 
test -z \$conv\ || new_convenience=\$new_convenience,$conv\; done; $echo 
\$new_convenience\` ${wl}--no-whole-archive'
  tmp_sharedflag='-G' ;;
*Sun\ F*)   # Sun Fortran 8.3
  tmp_sharedflag='-G' ;;


___
Bug-libtool mailing list
Bug-libtool@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-libtool


Re: [libtool 2.1a] testsuite: 25 49 failed

2007-02-16 Thread Ralf Wildenhues
Hello Lynn,

Thanks for the report.

* Lynn F. Ten Eyck wrote on Thu, Feb 15, 2007 at 11:44:02PM CET:
 
 I installed libtool 2.1a from CVS tonight and installed it.  The self- 
 test failed two tests.  The log reports most of the configuration  
 information.

 I installed the latest released  versions of Autoconf and Automake
 yesterday, which I believe are  Autoconf 2.61 and Automake 1.9.6,

FWIW, Automake 1.10 is current.

 as well as a snapshot of libtools  2.1a (not the CVS version).  I
 still ran into problems, so I got the  CVS version.

The snapshot should be updated once daily, so it shouldn't be much
different from the CVS version.  FYI, there are currently two active
branches: branch-1-5, where 1.5.24 will come from, and HEAD, which is
where 2.0 will come from.

Now to the actual bug report: The failures of test 49 are known, I'm
still working on a patch to fix them on all systems:
http://lists.gnu.org/archive/html/libtool-patches/2007-02/msg00033.html

The failure of 25 is new to me.  Do you have a libltdl.so.7 installed in
a place where the link editor finds it by default?  If yes, is there a
libltdl.la file installed alongside with it?  If not, why not, who
removed it?  It should be present.

There is still another failure in libltdl/m4/ltdl.m4: it won't reject
the external libltdl if only libtldl.so is new enough but ltdl.h is too
old (can happen if LDFLAGS was set correctly but CPPFLAGS wasn't).  In
that case there will be a link error due to `lt_preloaded_symbols' being
undefined.  Guess I'll fix that too...

Cheers,
Ralf

 25. old-m4-iface.at:89: testing ...
 libtoolize: linking file `./config.guess'
[...]
 ./old-m4-iface.at:135: CONFIG_SHELL=$SHELL $SHELL ./configure 
 $configure_options 
 stderr:
 stdout:
[...]
 checking whether to build shared libraries... yes
 checking whether to build static libraries... yes
 checking for ltdl.h... yes
 checking for lt_dlinterface_register in -lltdl... yes
 checking for lt_dlinterface_register in ltdl.h... yes
 checking whether to use included libltdl... no
 configure: creating ./config.status
 config.status: creating Makefile
 config.status: executing libtool commands
[...]
 ./old-m4-iface.at:135: $MAKE  
 stderr:
 stdout:
 make[4]: Entering directory 
 `/usr/local/libtool-cvs/libtool/tests/testsuite.dir/25'
 cd libltdl  make
 make[5]: Entering directory 
 `/usr/local/libtool-cvs/libtool/tests/testsuite.dir/25/libltdl'
 make  all-am
 make[6]: Entering directory 
 `/usr/local/libtool-cvs/libtool/tests/testsuite.dir/25/libltdl'
[...]
 /bin/sh ./libtool --mode=link gcc -no-undefined -g -O2  -o ltdldemo main.o 
 -dlopen module.la -lltdl
 libtool: link: rm -f .libs/ltdldemo.nm .libs/ltdldemo.nmS .libs/ltdldemo.nmT
 libtool: link: creating .libs/ltdldemoS.c
 libtool: link: (cd .libs  gcc -g -O2 -c -fno-builtin ltdldemoS.c)
 libtool: link: rm -f .libs/ltdldemoS.c .libs/ltdldemo.nm 
 .libs/ltdldemo.nmS .libs/ltdldemo.nmT
 libtool: link: gcc -g -O2 -o ltdldemo main.o .libs/ltdldemoS.o  -lltdl
 libtool: link: rm -f .libs/ltdldemoS.o
 make[4]: Leaving directory 
 `/usr/local/libtool-cvs/libtool/tests/testsuite.dir/25'
 ./old-m4-iface.at:138: ./ltdldemo; lt_status=$?; if test $lt_status -eq 0; 
 then :;
  elif test X$host != X$build  \
   { test -x ./ltdldemo || test -x ./ltdldemo$EXEEXT; }
  then (exit 77); else (exit $lt_status); fi
 --- /dev/null 2007-02-13 11:48:14.426723000 +
 +++ /usr/local/libtool-cvs/libtool/tests/testsuite.dir/at-stderr  
 2007-02-15 22:05:09.0 +
 @@ -0,0 +1 @@
 +./ltdldemo: error while loading shared libraries: libltdl.so.7: cannot open 
 shared object file: No such file or directory
 stdout:
 ./old-m4-iface.at:138: exit code was 127, expected 0
 25. old-m4-iface.at:89: 25. AC_WITH_LTDL (old-m4-iface.at:89): FAILED 
 (old-m4-iface.at:138)


___
Bug-libtool mailing list
Bug-libtool@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-libtool


Re: libtool issue with latest Sun cc compiler on Linux

2007-02-16 Thread Ralf Wildenhues
Hello Terry,

Thanks for the report.

* Terry D. Dontje wrote on Fri, Feb 16, 2007 at 01:55:10PM CET:
 
 [EMAIL PROTECTED]:~/tmp/compissue  cc -mt -c foo.c  -KPIC -DPIC -o foo.o 
 [EMAIL PROTECTED]:~/tmp/compissue ar cru libtest.a foo.o 
 [EMAIL PROTECTED]:~/tmp/compissue cc -G -Wl,--whole-archive,libtest.a 
 -Wl,--no-whole-archive -lnsl -lutil -lm -lc -mt -Wl,-soname 
 -Wl,libtest.so.0 -o libtest.so.0.0 /dev/null
 /dev/null: file not recognized: File truncated

That's weird.  I've had a chance to test this out now, and surprisingly,
I cannot reproduce this error over here with either of these versions:

| cc: Sun C 5.9 Build18_0 2006/03/13

| cc: Sun C 5.9 Linux_i386 Build35_2 2006/12/04

This is both on x86, and adding the /dev/null works:

$ touch a.c; cc -c a.c; ar cru liba.a a.o
| a.c, line 1: warning: empty translation unit
$ cc -G -Wl,--whole-archive,liba.a -Wl,--no-whole-archive -Wl,-soname 
-Wl,libtest.so.0 -o libtest.so.0.0 /dev/null -#
| ### Note: NLSPATH = 
/opt/sunstudiomars/prod/bin/../lib/locale/%L/LC_MESSAGES/%N.cat:/opt/sunstudiomars/prod/bin/../../lib/locale/%L/LC_MESSAGES/%N.cat
| ### command line files and options (expanded):
| ### -Wl,--whole-archive,liba.a -Wl,--no-whole-archive -Wl,-soname 
-Wl,libtest.so.0 -shared /dev/null -o libtest.so.0.0
| ### Note: LD_LIBRARY_PATH = /opt/intel_cc_80/lib:/opt/intel_fc_80/lib
| ### Note: LD_RUN_PATH = null
| /usr/bin/ld --whole-archive liba.a --no-whole-archive -soname libtest.so.0 -m 
elf_i386 -dynamic-linker /lib/ld-linux.so.2 /opt/sunstudiomars/prod/lib/crti.o 
/opt/sunstudiomars/prod/lib/values-xa.o -o libtest.so.0.0 -shared /dev/null -Y 
/opt/sunstudiomars/prod/lib:/lib:/usr/lib -Qy -lc 
/opt/sunstudiomars/prod/lib/libc_supp.a /opt/sunstudiomars/prod/lib/crtn.o
$ echo $?
0
$ /usr/bin/ld --version
| GNU ld version 2.17 Debian GNU/Linux

 Note the following is my Sun CC version info:
 cc: Sun C 5.9 Linux_i386 Build35_2 2006/12/04

Weird, that's the same version.  So how can I reproduce this failure, so
that we don't fall into this trap again?  Is the error even produced by
cc, or by chance by ld?

Thanks,
Ralf


___
Bug-libtool mailing list
Bug-libtool@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-libtool


Re: [GNU Autoconf 2.60] testsuite: 3 120 failed

2007-02-11 Thread Ralf Wildenhues
Hello Paul, all,

http://thread.gmane.org/gmane.comp.sysutils.autoconf.bugs/5266/focus=5549

* Paul Eggert wrote on Thu, Oct 12, 2006 at 09:45:24PM CEST:
 Ralf Wildenhues [EMAIL PROTECTED] writes:
 
  This patch kills $as_executable_p.  This breaks libtool.m4 from
  Libtool-1.5.22 (and possibly CVS HEAD, I haven't checked).
 
 OK, I installed this backward-compatibility hack.  I assume
 you'll be fixing libtool?
 
 2006-10-12  Paul Eggert  [EMAIL PROTECTED]
 
   * lib/m4sugar/m4sh.m4 (_AS_TEST_PREPARE): Set as_executable_p,
   for backward compatibility with Libtool 1.5.22.  Problem reported
   by Ralf Wildenhues.

Some things to be aware of here:

1) Libtool branch-1-5 aims to be compatible to Autoconf-2.50; also I aim
   to not add more unnecessary incompatibilities with Autoconf-2.13, as
   there are users who patch the missing bits to make it compatible with
   it.

2) Libtool (at least branch-1-5) aims to be compatible to Automake-1.4.

3) Autoconf-2.61b (CVS) still doesn't document AS_EXECUTABLE_P.

Do you think the approach below is safe enough?  Note I intentionally do
not use the _AS_TEST_PREPARE from 2.61: if you use new enough Autoconf,
then that is already defined and will be used.

Can I assume that AS_EXECUTABLE_P may eventually be made a public
Autoconf interface (then we could just do away with our copy of
_AS_TEST_PREPARE and AS_EXECUTABLE_P)?

Note CVS HEAD Libtool doesn't need this: it uses $as_executable_p only
in its version of AC_PROG_SED, which itself is not defined iff already
given by Autoconf.

OK to apply?

Cheers,
Ralf

2007-02-11  Ralf Wildenhues  [EMAIL PROTECTED]

* libtool.m4 (_AS_TEST_PREPARE, AS_EXECUTABLE_P): m4_defun
these macros, if undefined, with copies from Autoconf 2.59.
(LT_AC_PROG_SED): Use AS_EXECUTABLE_P, not $as_executable_p,
this is an internal Autoconf detail.

Index: libtool.m4
===
RCS file: /cvsroot/libtool/libtool/Attic/libtool.m4,v
retrieving revision 1.314.2.170
diff -u -r1.314.2.170 libtool.m4
--- libtool.m4  5 Feb 2007 19:40:53 -   1.314.2.170
+++ libtool.m4  11 Feb 2007 09:31:44 -
@@ -6483,6 +6483,26 @@
 [AC_CHECK_TOOL(RC, windres, no)
 ])
 
+
+# Cheap backport of AS_EXECUTABLE_P and required macros
+# from Autoconf 2.59; we should not use $as_executable_p directly.
+
+# _AS_TEST_PREPARE
+# 
+m4_ifndef([_AS_TEST_PREPARE],
+[m4_defun([_AS_TEST_PREPARE],
+[as_executable_p=test -f
+])])# _AS_TEST_PREPARE
+
+# AS_EXECUTABLE_P
+# ---
+# Check whether a file is executable.
+m4_ifndef([AS_EXECUTABLE_P],
+[m4_defun([AS_EXECUTABLE_P],
+[AS_REQUIRE([_AS_TEST_PREPARE])dnl
+$as_executable_p $1[]dnl
+])])# AS_EXECUTABLE_P
+
 
 # NOTE: This macro has been submitted for inclusion into   #
 #  GNU Autoconf as AC_PROG_SED.  When it is available in   #
@@ -6505,7 +6525,7 @@
   test -z $as_dir  as_dir=.
   for lt_ac_prog in sed gsed; do
 for ac_exec_ext in '' $ac_executable_extensions; do
-  if $as_executable_p $as_dir/$lt_ac_prog$ac_exec_ext; then
+  if AS_EXECUTABLE_P([$as_dir/$lt_ac_prog$ac_exec_ext]); then
 lt_ac_sed_list=$lt_ac_sed_list $as_dir/$lt_ac_prog$ac_exec_ext
   fi
 done


___
Bug-libtool mailing list
Bug-libtool@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-libtool


Re: [GNU Autoconf 2.60] testsuite: 3 120 failed

2007-02-11 Thread Ralf Wildenhues
Hi Peter,

Thanks for the quick review!

* Peter O'Gorman wrote on Sun, Feb 11, 2007 at 01:18:56PM CET:
 On Feb 11, 2007, at 6:33 PM, Ralf Wildenhues wrote:
 
 OK to apply?

 +m4_ifndef([_AS_TEST_PREPARE],
 +[m4_defun([_AS_TEST_PREPARE],
 +[as_executable_p=test -f

 Could we test if test -x works and use that? I know that this is  
 barely used, but it bugs me that test -f does not test for the  
 executable bit :)
 
 I think autoconf has this:

CVS Autoconf has something quite a bit more elaborate.  But I guess we
can at least do this much.  I'm installing the patch below.

Note that it doesn't define $as_test_x.

Cheers,
Ralf

2007-02-11  Ralf Wildenhues  [EMAIL PROTECTED]

* libtool.m4 (_AS_TEST_PREPARE, AS_EXECUTABLE_P): m4_defun
these macros, if undefined, with modified copies from Autoconf
2.59.
(LT_AC_PROG_SED): Use AS_EXECUTABLE_P, not $as_executable_p,
this is an internal Autoconf detail.

Index: libtool.m4
===
RCS file: /cvsroot/libtool/libtool/Attic/libtool.m4,v
retrieving revision 1.314.2.170
diff -u -r1.314.2.170 libtool.m4
--- libtool.m4  5 Feb 2007 19:40:53 -   1.314.2.170
+++ libtool.m4  11 Feb 2007 13:34:14 -
@@ -6483,6 +6483,30 @@
 [AC_CHECK_TOOL(RC, windres, no)
 ])
 
+
+# Cheap backport of AS_EXECUTABLE_P and required macros
+# from Autoconf 2.59; we should not use $as_executable_p directly.
+
+# _AS_TEST_PREPARE
+# 
+m4_ifndef([_AS_TEST_PREPARE],
+[m4_defun([_AS_TEST_PREPARE],
+[if test -x / /dev/null 21; then
+  as_executable_p='test -x'
+else
+  as_executable_p='test -f'
+fi
+])])# _AS_TEST_PREPARE
+
+# AS_EXECUTABLE_P
+# ---
+# Check whether a file is executable.
+m4_ifndef([AS_EXECUTABLE_P],
+[m4_defun([AS_EXECUTABLE_P],
+[AS_REQUIRE([_AS_TEST_PREPARE])dnl
+$as_executable_p $1[]dnl
+])])# AS_EXECUTABLE_P
+
 
 # NOTE: This macro has been submitted for inclusion into   #
 #  GNU Autoconf as AC_PROG_SED.  When it is available in   #
@@ -6505,7 +6529,7 @@
   test -z $as_dir  as_dir=.
   for lt_ac_prog in sed gsed; do
 for ac_exec_ext in '' $ac_executable_extensions; do
-  if $as_executable_p $as_dir/$lt_ac_prog$ac_exec_ext; then
+  if AS_EXECUTABLE_P([$as_dir/$lt_ac_prog$ac_exec_ext]); then
 lt_ac_sed_list=$lt_ac_sed_list $as_dir/$lt_ac_prog$ac_exec_ext
   fi
 done


___
Bug-libtool mailing list
Bug-libtool@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-libtool


Re: Wrapper executable using wrong path for cross-compiled binaries?

2007-02-05 Thread Ralf Wildenhues
Hello Simon,

Thanks for the report.

* Simon Josefsson wrote on Thu, Feb 01, 2007 at 10:53:08AM CET:
 Hi!  I'm trying to understand why 'make check' fails for GnuTLS with
 automake 1.10 as follows:
 
 ...
 fixme:msvcrt:_spawnve only trying .exe when no extension given
 Wine failed with return code 127
 FAIL: ...

That is, cross-compiled binaries and doing 'make check' with the help of
wine, right?  Libtool version?  How exactly did you configure GnuTLS?

 If I understand the wrapper program correctly (which I'm not sure of),
 the find_executable function is incorrect.  It causes the program to
 think that it should execv($SHELL
 Z:\home\jas\self\src\gnutls\tests/./simple).  That's wrong -- that
 path may be correct on the target system (wine), but the execv happens
 on the build target.

Hrmpf.

 Then I notice this comment:
 
   # we should really use a build-platform specific compiler
   # here, but OTOH, the wrappers (shell script and this C one)
   # are only useful if you want to execute the real binary.
   # Since the real binary is built for $host, then this
   # wrapper might as well be built for $host, too.
   $run $LTCC $LTCFLAGS -s -o $cwrapper $cwrappersource
 
 And that seems correct, and the real cause of my problem.
 
 I can see a few solutions:
 
 1) Use a build-platform specific compiler... however, libtool
typically doesn't know how to invoke that one, and on weird systems
there may not even be one.
 
 2) Modify the C wrapper code to deal with this problem and use better
paths.  I can propose a patch if you believe this is the right
approach.  Because 1) is really the right solution, even though it
is complicated, this should be regarded as a hack.
 
 3) Don't use an executable at all, but a simple shell script that
invokes .libs/$0.  I'm not sure I see a reason to use a executable
wrapper written in C, anyone else?

Wait a minute.  The usual thing that happens is that libtool builds both
a shell wrapper foo and an executable foo.exe.  The latter calls the
former.  Is there a shell wrapper?  Executing the shell wrapper should
work for you -- does it?


4) Automake should learn how to invoke cross-compiled binaries on a
simulator, or set EXEEXT correctly for this case.  Maybe best if
Autoconf learned it and taught Automake.

5) Libtool should allow to
  execv($simulator Z:\home\jas\self\src\gnutls\tests/./simple)

6) (4) and (5) combined.

Dunno what's the best way until we have a better one.

Cheers,
Ralf


___
Bug-libtool mailing list
Bug-libtool@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-libtool


Re: [patch] Dangling Pointer in libltdl

2007-01-28 Thread Ralf Wildenhues
* quoting myself:
 * Dave Brolley wrote on Wed, Jan 24, 2007 at 11:14:56PM CET:
  Given time, I should be able to come up with a test case if necessary.
 
 I have a test.  Will post and apply both when I have it cleaned up.

Here's what I've come up with and applied.  The HEAD test can also be
made to work with branch-1-5's libltdl, by something like
  make check-local TESTSUITEFLAGS='-k lt_dlexit' \
LTDLINCL=/path/to/branch-1-5/libltdl/ \
LIBLTDL=/path/to/branch-1-5/libltdl/libltdlc.la
LIBTOOL=/path/to/branch-1-5/libtool

(writing from memory, I think that was it).

Cheers,
Ralf

branch-1-5:
2007-01-28  Dave Brolley  [EMAIL PROTECTED]

* libltdl/ltdl.c (lt_dlexit): Make sure that 'cur' is not NULL
before checking that it is still in the list.

Index: libltdl/ltdl.c
===
RCS file: /cvsroot/libtool/libtool/libltdl/ltdl.c,v
retrieving revision 1.174.2.26
diff -u -r1.174.2.26 ltdl.c
--- libltdl/ltdl.c  28 Jan 2007 13:40:49 -  1.174.2.26
+++ libltdl/ltdl.c  28 Jan 2007 14:51:56 -
@@ -2341,6 +2341,19 @@
  lt_dlhandle tmp = cur;
  cur = cur-next;
  if (!LT_DLIS_RESIDENT (tmp))
+ /* Make sure that the handle pointed to by 'cur' still exists.
+lt_dlclose recursively closes dependent libraries which 
removes
+them from the linked list.  One of these might be the one
+pointed to by 'cur'.  */
+ if (cur)
+   {
+ for (tmp = handles; tmp; tmp = tmp-next)
+   if (tmp == cur)
+ break;
+ if (! tmp)
+   cur = handles;
+   }
+
saw_nonresident = 1;
  if (!LT_DLIS_RESIDENT (tmp)  tmp-info.ref_count = level)
{

HEAD:
2007-01-28  Dave Brolley  [EMAIL PROTECTED]
Ralf Wildenhues  [EMAIL PROTECTED]

* libltdl/ltdl.c (lt_dlexit): Make sure that 'cur' is not NULL
before checking that it is still in the list.
* tests/lt_dlexit.at: New test.
* Makefile.am (TESTSUITE_AT): Adjust.
(check-local): Also depend on libltdl/libltdlc.la.
(check-recursive): Removed, unnecessary use of Automake
internals.

Index: Makefile.am
===
RCS file: /cvsroot/libtool/libtool/Makefile.am,v
retrieving revision 1.204
diff -u -r1.204 Makefile.am
--- Makefile.am 28 Jan 2007 12:43:36 -  1.204
+++ Makefile.am 28 Jan 2007 14:50:59 -
@@ -411,6 +411,7 @@
  tests/search-path.at \
  tests/old-m4-iface.at \
  tests/am-subdir.at \
+ tests/lt_dlexit.at \
  tests/standalone.at \
  tests/subproject.at \
  tests/nonrecursive.at \
@@ -444,8 +445,6 @@
LIBTOOL=$(bindir)/`echo libtool | sed '$(program_transform_name)'` \
tst_aclocaldir=$(aclocaldir)
 
-check-recursive: $(srcdir)/$(TESTSUITE)
-
 # Use `$(srcdir)' for the benefit of non-GNU makes: this is
 # how `testsuite' appears in our dependencies.
 $(srcdir)/$(TESTSUITE): $(srcdir)/tests/package.m4 $(TESTSUITE_AT) Makefile.am
@@ -471,7 +470,7 @@
 CD_TESTDIR = abs_srcdir=`$(lt__cd) $(srcdir)  pwd`; cd tests
 
 # Hook the test suite into the check rule
-check-local: tests/atconfig $(srcdir)/$(TESTSUITE)
+check-local: tests/atconfig $(srcdir)/$(TESTSUITE) libltdl/libltdlc.la
$(CD_TESTDIR); \
CONFIG_SHELL=$(SHELL) $(SHELL) $$abs_srcdir/$(TESTSUITE) \
  $(TESTS_ENVIRONMENT) $(BUILDCHECK_ENVIRONMENT) $(TESTSUITEFLAGS)
Index: libltdl/ltdl.c
===
RCS file: /cvsroot/libtool/libtool/libltdl/ltdl.c,v
retrieving revision 1.245
diff -u -r1.245 ltdl.c
--- libltdl/ltdl.c  13 Oct 2006 14:11:18 -  1.245
+++ libltdl/ltdl.c  28 Jan 2007 14:50:59 -
@@ -283,6 +283,18 @@
{
  ++errors;
}
+ /* Make sure that the handle pointed to by 'cur' still 
exists.
+lt_dlclose recursively closes dependent libraries 
which removes
+them from the linked list.  One of these might be the 
one
+pointed to by 'cur'.  */
+ if (cur)
+   {
+ for (tmp = handles; tmp; tmp = tmp-next)
+   if (tmp == cur)
+ break;
+ if (! tmp)
+   cur = handles;
+   }
}
}
}
--- /dev/null   2007-01-26 00:38:36.692344249 +0100
+++ tests/lt_dlexit.at  2007-01-28 15:44:32.0 +0100
@@ -0,0 +1,137 @@
+# Hand

Re: strings.h in argz.c?

2007-01-27 Thread Ralf Wildenhues
* Paul Eggert wrote on Mon, Jan 22, 2007 at 03:22:51AM CET:
 
 My experience is that everyone who's reported a bug against SunOS
 4.1.x for several years, is either (1) doing it only because they're
 worried we might still want to be portable to SunOS 4.1.x, or (2)
 maintaining a computer museum.  Neither of these cases are worth
 worrying about.

OK.

 Ralf Wildenhues [EMAIL PROTECTED] writes:
  Is it likely (in practice) to have math functions like sin, cos,
  available but not math.h?  Similarly, is it likely to have string
  functions but not string.h?
 
 Not these days, no.  However it is possible that a freestanding
 environment would have neither math.h nor the math functions.  PalmOS
 is one fairly-contemporary example.  It's less likely for string.h to
 be missing (PalmOS has it, albeit in a shim mode if memory serves).

OK, that's good enough for Libtool.  If a test fails due to missing
math.h, I won't be worried, if it would fail later anyway due to a
missing sine function.

* Simon Josefsson wrote on Mon, Jan 22, 2007 at 08:53:37AM CET:
 Ralf Wildenhues [EMAIL PROTECTED] writes:
 
  We got a bug report about Libtool 1.5.22 and SunOS 4.1.x this year, so
  I'm not doing any C89 cleanup on branch-1-5.
 
 That's not a problem, I only meant it to apply to future version.  (I
 assume there will be future versions not based on branch-1-5 ;-)).

I do hope so, too.

  OTOH, the change may eventually cause 2 less header checks in user code;
  that is, once all other checks for string.h and strings.h are eliminated
  from their configury.
 
 Yes, and another problem might be code that checks for strings.h
 and/or memory.h, but not string.h.  It seems they might get the wrong
 headers..

Well, currently, Autoconf's _AC_INCLUDES_DEFAULT_REQUIREMENTS still
tests for these anyway.

 I don't know about math.h.  Math functions seem generally more
 optional than other functions to me, depending on platform.  If your
 patch only changed this for the self tests, that is probably OK, but
 it seems weird for libtool/ltdl to require math functions.

ACK.  Only the test suite requires them.

I applied the patch, with a NEWS bit added, to HEAD.

Cheers,
Ralf

Assume C89 for included headers, and throughout the testsuite.

* NEWS: Update.
* libltdl/argz.c: Do not include strings.h nor memory.h, include
string.h unconditionally.
Patch by Simon Josefsson [EMAIL PROTECTED].
* libltdl/libltdl/lt__private.h: Likewise.
* libltdl/m4/ltdl.m4 (LTDL_INIT): Do not check for string.h,
strings.h, memory.h.
* tests/cdemo/configure.ac: Assume presence of math.h.
* tests/cdemo/foo.c: Likewise.
* tests/demo/configure.ac: Likewise for math.h, string.h.
Assume 'const'.  Drop obsolete AC_EXEEXT.
* tests/demo/dlmain.c: Likewise.
* tests/demo/foo.c: Likewise.
* tests/depdemo/configure.ac: Likewise.
* tests/depdemo/l4/l4.c: Likewise.
* tests/f77demo/configure.ac: Likewise.  Also drop obsolete
AC_OBJEXT.
* tests/fcdemo/configure.ac: Likewise.
* tests/mdemo/configure.ac: Likewise.
* tests/mdemo/foo1.c: Likewise.
* tests/mdemo/foo2.c: Likewise.
* tests/mdemo2/configure.ac: Likewise.
* tests/pdemo/configure.ac: Likewise.
* tests/pdemo/longer_file_name_dlmain.c:
* tests/pdemo/longer_file_name_foo.c: Likewise.
* tests/pdemo/longer_file_name_foo2.c: Likewise.
* tests/tagdemo/configure.ac: Likewise.
* tests/tagdemo/foo.cpp: Likewise.

Index: NEWS
===
RCS file: /cvsroot/libtool/libtool/NEWS,v
retrieving revision 1.197
diff -u -r1.197 NEWS
--- NEWS24 Oct 2006 20:17:37 -  1.197
+++ NEWS27 Jan 2007 16:44:19 -
@@ -36,6 +36,9 @@
 * Initial support for the Sun compiler suite on GNU/Linux.
 * Improved support for GNU/kFreeBSD and GNU/NetBSD.
 * Search paths with GCC on multilib systems like x86_64 have been fixed.
+* The Libtool and libltdl macros and the testsuite now assume a C89
+  environment, consequently do not test for headers such as string.h,
+  strings.h, memory.h any more.
 * Bug fixes.
 
 New in 1.9f: 2004-10-23; CVS version 1.9e, Libtool team:


___
Bug-libtool mailing list
Bug-libtool@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-libtool


Re: libtool error

2007-01-26 Thread Ralf Wildenhues
Hello Matthew,

* Matthew Ford wrote on Fri, Jan 26, 2007 at 05:36:09AM CET:
 I am trying to build subversion 1.4.2 and continue to get this libtool
 error.

 cd subversion/mod_dav_svn  /bin/bash
 /ap/d/serena/tt/build/subversion-1.4.2/libtool --tag=CC --silent
 --mode=link gcc  -g -O2  -g -O2 -pthreads  -L/ap/d/serena/tt/build/lib
 -rpath  -avoid-version -module  -o mod_dav_svn.la  activity.lo
 deadprops.lo file_revs.lo liveprops.lo lock.lo log.lo merge.lo
 mod_dav_svn.lo replay.lo repos.lo update.lo util.lo version.lo
 .../../subversion/libsvn_repos/libsvn_repos-1.la
 .../../subversion/libsvn_fs/libsvn_fs-1.la
 .../../subversion/libsvn_delta/libsvn_delta-1.la
 .../../subversion/libsvn_subr/libsvn_subr-1.la -lsocket  -lz
 
 libtool: link: only absolute run-paths are allowed

The -rpath option to libtool needs as an argument an absolute path.
Please take a look at the Makefile which issued this.  Most likely
it contains something like
   -rpath $(libdir)

or a similarly named macro.  Find out why the macro is empty; it
shouldn't be.  Usually it would be substituted at the end of configure,
by config.status; in the corresponding Makefile.in there'd be a line
  libdir = @libdir@

or so.  The config.log file may contain information about its setting.

Hope that helps.

Cheers,
Ralf


___
Bug-libtool mailing list
Bug-libtool@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-libtool


Re: libtool, gettext, and HP-UX ia64 shared libraries

2007-01-24 Thread Ralf Wildenhues
Hello Bob,

Apologies for the enormous delay.  :-(

* Bob Proulx wrote on Sat, Jan 20, 2007 at 07:50:04PM CET:
  A while ago I raised an issue trying to build coreutils on HP-UX ia64.
  
http://lists.gnu.org/archive/html/bug-gnu-utils/2006-08/msg00083.html
 Let me keep this issue alive and kicking.  Libtool is still broken on
 HP-UX ia64.  But with this change it works.  I just don't know enough
 about libtool to suggest where libtool would need to be modified in
 order to make this a proper fix.
 
  Adding -L ../intl/.libs allows this to succeed.  This following
  command successfully links the test-names program.
  
cc -g -o .libs/test-names test-names.o libuniname.a -L ../intl/.libs 
  ../gnulib-lib/.libs/libgettextlib.so 
  /usr/local/build/coreutils/src/gettext-0.16.1/gettext-tools/intl/.libs/libintl.so
   -lc -Wl,+b -Wl,/usr/local/build/coreutils/lib
  
  Adding a -L path option seems to be required here.

Nope.  I think we fixed this issue in HEAD and branch-1-5 already, but
after 1.5.22.  I think the 2006-06-12 patch [1] on branch-1-5 is the
one you're looking for.  The important difference in your case is that
when creating gettext-tools/gnulib-lib/libgettext.la, in the link
command for .libs/libgettextlib-0.16.1.so, the argument
  +b /tmp/build/gettext-tools/intl/.libs:/prefix/lib

is correctly prefixed with `-Wl,':
  -Wl,+b -Wl,/tmp/build/gettext-tools/intl/.libs:/prefix/lib

I've tested now that with 
  gmake LIBTOOL=/path/to/build-of-libtool-branch-1-5/libtool

the build of gettext-0.16.1 successfully completes on HP-UX ia64.

Yay, another bugger down on the way to 1.5.24 ...

Cheers,
Ralf

[1] http://lists.gnu.org/archive/html/libtool-patches/2006-06/msg6.html


___
Bug-libtool mailing list
Bug-libtool@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-libtool


Re: [patch] Dangling Pointer in libltdl

2007-01-23 Thread Ralf Wildenhues
Hello Dave,

Thanks for the bug report.

* Dave Brolley wrote on Thu, Jan 18, 2007 at 07:39:23PM CET:
 
 The attached patch fixes a problem with a dangling pointer in lt_dlexit 
 withing libltdl. The problem is that lt_dlclose  is recursively called 
 (via unload_deplibs) in order to close dependent libraries. One of these 
 might be (and was for me!) the one pointed to by 'cur'.

I have trouble reproducing this bug easily.  Which system does it happen
on?  How does the graph formed by modules/libraries and
interdependencies (linking against/dlopening) look like?  In what order
are things opened/linked against, which ones are closed explicitly, for
this to trigger?  Do you mix calls to lt_dlopen with direct calls to
dlopen?  Do you mix libraries created with libtool with libraries
created without?

I would like to apply a test case along with the fix.  Easiest for me
would be to see a small example reproducing this (if you need help, I
can post an unfinished test case for this), or, failing that, the
original code that exposes the bug.  Failing that, you could put up an
strace output of a program that exposes the bug.  That way we should
hopefully be able to infer most information.  But be sure to bzip2-pack
it if you must post it rather than putting it on some web page.

 @@ -283,10 +283,19 @@ lt_dlexit (void)
   {
 ++errors;
   }
   }
   }
 +   /* Make sure that the handle pointed to by 'cur' still exists.
 +  lt_dlclose recursively closes dependent libraries which removes
 +  them from the linked list.  One of these might be the one
 +  pointed to by 'cur'.  */
 +   for (tmp = handles; tmp; tmp = tmp-next)
 + if (tmp == cur)
 +   break;
 +   if (! tmp)
 + cur = handles;

If the description is correct, the whole addition could go in the true
branch of the `if (tmp-info.ref_count = level)' test, no?

Cheers, and thanks again,
Ralf


___
Bug-libtool mailing list
Bug-libtool@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-libtool


Re: strings.h in argz.c?

2007-01-21 Thread Ralf Wildenhues
Hello Simon,

Apologies for the long delay.

* Simon Josefsson wrote on Mon, Oct 30, 2006 at 01:46:30PM CET:
 Bruno Haible [EMAIL PROTECTED] writes:

  Is strings.h needed on any modern platform?
 
  No.

 I see that argz.c comes from libtool.  Would this patch be acceptable?
 I'm cc:ing bug-libtool in case they have some legacy priority that
 demand strings.h.

We got a bug report about Libtool 1.5.22 and SunOS 4.1.x this year, so
I'm not doing any C89 cleanup on branch-1-5.

* Bruno Haible wrote on Mon, Oct 30, 2006 at 03:06:54PM CET:
 Simon Josefsson wrote:
  I assume that memory.h is a side-effect of using strings.h, and that
  memory.h is not needed today either?
 
 Yes. Even on older systems like Solaris 2.4, AIX 4.3, IRIX 6.5, HP-UX 11,
 OSF/1 4.0, the contents of memory.h is also available through string.h.

Thanks.  Here's a quick audit of Libtool CVS HEAD to assume more of C89.
I'm really not sure whether I should apply it: the mere prospect of
lessening testsuite exposure on older hosts seems to me that it could
easily be more of a problem than the few, half a decade old lines that
nobody has needed to touch in a long time.

OTOH, the change may eventually cause 2 less header checks in user code;
that is, once all other checks for string.h and strings.h are eliminated
from their configury.

WDYT?

Cheers,
Ralf

2007-01-21  Ralf Wildenhues  [EMAIL PROTECTED]

Assume C89.
* libltdl/argz.c: Do not include strings.h nor memory.h, include
string.h unconditionally.
Patch by Simon Josefsson [EMAIL PROTECTED].
* libltdl/libltdl/lt__private.h: Likewise.
* libltdl/m4/ltdl.m4 (LTDL_INIT): Do not check for string.h,
strings.h, memory.h.
* tests/cdemo/configure.ac: Assume presence of math.h.
* tests/cdemo/foo.c: Likewise.
* tests/demo/configure.ac: Likewise for math.h, string.h.
Assume 'const'.  Drop obsolete AC_EXEEXT.
* tests/demo/dlmain.c: Likewise.
* tests/demo/foo.c: Likewise.
* tests/depdemo/configure.ac: Likewise.
* tests/depdemo/l4/l4.c: Likewise.
* tests/f77demo/configure.ac: Likewise.  Also drop obsolete
AC_OBJEXT.
* tests/fcdemo/configure.ac: Likewise.
* tests/mdemo/configure.ac: Likewise.
* tests/mdemo/foo1.c: Likewise.
* tests/mdemo/foo2.c: Likewise.
* tests/mdemo2/configure.ac: Likewise.
* tests/pdemo/configure.ac: Likewise.
* tests/pdemo/longer_file_name_dlmain.c:
* tests/pdemo/longer_file_name_foo.c: Likewise.
* tests/pdemo/longer_file_name_foo2.c: Likewise.
* tests/tagdemo/configure.ac: Likewise.
* tests/tagdemo/foo.cpp: Likewise.

Index: libltdl/argz.c
===
RCS file: /cvsroot/libtool/libtool/libltdl/argz.c,v
retrieving revision 1.9
diff -u -r1.9 argz.c
--- libltdl/argz.c  24 Oct 2006 20:33:38 -  1.9
+++ libltdl/argz.c  21 Jan 2007 15:49:45 -
@@ -1,5 +1,5 @@
 /* argz.c -- argz implementation for non-glibc systems
-   Copyright (C) 2004, 2006 Free Software Foundation, Inc.
+   Copyright (C) 2004, 2006, 2007 Free Software Foundation, Inc.
Originally by Gary V. Vaughan  [EMAIL PROTECTED]
 
NOTE: The canonical source of this file is maintained with the
@@ -40,15 +40,7 @@
 #include stdlib.h
 #include sys/types.h
 #include errno.h
-
-#if defined(HAVE_STRING_H)
-#  include string.h
-#elif defined(HAVE_STRINGS_H)
-#  include strings.h
-#endif
-#if defined(HAVE_MEMORY_H)
-#  include memory.h
-#endif
+#include string.h
 
 #define EOS_CHAR '\0'
 
Index: libltdl/libltdl/lt__private.h
===
RCS file: /cvsroot/libtool/libtool/libltdl/libltdl/lt__private.h,v
retrieving revision 1.10
diff -u -r1.10 lt__private.h
--- libltdl/libltdl/lt__private.h   26 Oct 2006 20:39:04 -  1.10
+++ libltdl/libltdl/lt__private.h   21 Jan 2007 15:49:47 -
@@ -1,5 +1,5 @@
 /* lt__private.h -- internal apis for libltdl
-   Copyright (C) 2004, 2005, 2006 Free Software Foundation, Inc.
+   Copyright (C) 2004, 2005, 2006, 2007 Free Software Foundation, Inc.
Originally by Gary V. Vaughan  [EMAIL PROTECTED]
 
NOTE: The canonical source of this file is maintained with the
@@ -40,22 +40,12 @@
 #include ctype.h
 #include assert.h
 #include errno.h
+#include string.h
 
 #if defined(HAVE_UNISTD_H)
 #  include unistd.h
 #endif
 
-#if defined(HAVE_STRING_H)
-#  include string.h
-#else
-#  if defined(HAVE_STRINGS_H)
-#include strings.h
-#  endif
-#endif
-#if defined(HAVE_MEMORY_H)
-#  include memory.h
-#endif
-
 /* Import internal interfaces...  */
 #include lt__alloc.h
 #include lt__dirent.h
Index: libltdl/m4/ltdl.m4
===
RCS file: /cvsroot/libtool/libtool/libltdl/m4/ltdl.m4,v
retrieving revision 1.30
diff -u -r1.30 ltdl.m4
--- libltdl/m4/ltdl.m4  25 Aug 2006 15:04:30 -

Re: makeC++SharedLib_r not used on AIX

2007-01-16 Thread Ralf Wildenhues
Hello Tommi,

Thanks for the report and the test case, and apologies for the delay.

* Tommi Mäkitalo wrote on Fri, Dec 22, 2006 at 04:25:30PM CET:
 
 for building a C++-library on AIX there is a script makeC++SharedLib or 
 makeC++SharedLib_r in multithreaded apps, which according to IBM have to be 
 used. Otherwise static initializers are not called.

Yes, I see this.  It seems they use some asm hackery for reliable
initialization order.  This is definitely something libtool shouldn't
try to do itself.  But one problem with using one of makeC++SharedLib*
is exactly that choice: how would libtool choose the right one?

On an AIX systems I have access to, the script can have suffixes
  _r _r4 _r7 _128

(thread safe, thread safe with some compatibility library, 128 bit long
double; default is not thread safe), according to which some library
paths are added and libraries linked against.


Anyway, the manual documents that
  xlC -qmkshrobj[=PRIO]

should be used instead.  So I experimented with that.  It seems to help
but I don't think that we can automatically fix things for users that
actually need a certain initialization order.  There are several ways[1]
to set the relative initialization priority order, for users that need
this.

 I ran into this problem and prepared a testcase, which confirms this. I 
 modified the tagdemo to use a static std::string-object to print the in the 
 library. On AIX the string is empty.
 
 You can find my modified version of tagdemo on 
 http://www.tntnet.org/tagdemo-0.1.tar.gz and the output on AIX at 
 http://www.tntnet.org/tagdemo.out.

 There is a empty line instead of the message ** This is libfoo (tagdemo) ** 
 in the output.

I can get the testcase to work
- without runtimelinking:
  by adding -qmkshrobj to the link flags of libfoo.la:
make libfoo_la_LDFLAGS='-no-undefined -qmkshrobj'

- with runtimelinking:
configure LDFLAGS=-Wl,-brtl

  (this is needed at configure time because libtool makes some decisions
  based on this flag)

So first, runtimelinking is a suitable workaround.  Second, we should
think about adding the -qmkshrobj flag if xlC supports it.  Not sure yet
what other semantic changes it will cause.

Disclaimer: all my testing has been done with CVS HEAD Libtool only so
far.

Cheers,
Ralf

[1] 
http://publib.boulder.ibm.com/infocenter/pseries/v5r3/index.jsp?topic=/com.ibm.xlcpp8a.doc/proguide/ref/tushrlib.htm


___
Bug-libtool mailing list
Bug-libtool@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-libtool


Re: Bug report as requested.

2007-01-09 Thread Ralf Wildenhues
Hello Hugh,

Thanks for the bug report.

* Hugh Sasse wrote on Tue, Jan 09, 2007 at 11:07:54AM CET:
 libtool-1.5.22 on Sun-sparc-solaris2.9
 
 PASS: f77demo-static.test
 FAIL: f77demo-make.test
 SKIP: f77demo-exec.test
 PASS: f77demo-conf.test
 FAIL: f77demo-make.test
 SKIP: f77demo-exec.test
 PASS: f77demo-shared.test
 FAIL: f77demo-make.test
 SKIP: f77demo-exec.test

 Anything else I need to tell you for this to be useful?

Yes.  Please run
  make check VERBOSE=yes \
  TESTS=f77demo-static.test f77demo-make.test f77demo-exec.test \
 f77demo-conf.test f77demo-make.test f77demo-exec.test \
 f77demo-shared.test f77demo-make.test f77demo-exec.test

and post the output.  Probably you want to use gmake rather than Solaris
make.

Cheers,
Ralf


___
Bug-libtool mailing list
Bug-libtool@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-libtool


Re: -static does not select static libraries very well anymore ...

2007-01-08 Thread Ralf Wildenhues
Hello Roger,

* Roger March wrote on Fri, Jan 05, 2007 at 08:52:57PM CET:
 I have been using libtool 1.5.18 for my builds for awhile. The
 applications link against libraries containing both static and shared
 versions. When 1.5.18 is linked with the '-static' flag, it seems to
 pretty much select a static version for every library it can. When
 1.5.22 is used it seems to always go for the shared version if present.
 Has there been a conscious change in the semantics of '-static'? What
 should the behavior of '-static' be in the face of mixed static-shared
 links? Thanks.

Please see this thread:
http://thread.gmane.org/gmane.comp.gnu.libtool.general/7097/focus=6715.

We need to get 1.5.24 out.

Cheers, and a happy New Year,
Ralf


___
Bug-libtool mailing list
Bug-libtool@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-libtool


Re: help plz

2006-12-20 Thread Ralf Wildenhues
Hello Mehul,

* mehul shah wrote on Tue, Dec 19, 2006 at 03:37:09PM CET:
 
 libtool: unrecognized option `--tag=CXX'
 Try `libtool --help' for more information.

This error comes from a Libtool release older than 1.5.  Current is
1.5.22.  You need to ensure that a newer libtool is used.

Now, most of the time, software packages come with the libtool machinery
packed inside the package -- the libtool script is then built at the end
of the 'configure' step.  If that's the case for the package you're
compiling, then it seems that it has a bug.  If not, then you could
upgrade your system libtool, or read the package's documentation that
probably has details about a requirement for an external libtool.

Hope that helps.

Cheers,
Ralf


___
Bug-libtool mailing list
Bug-libtool@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-libtool


Re: bug in libtool rpath setting for _LT_AC_TAGVAR(hardcode_libdir_flag_spec, $1) (libtool 1.5.22)

2006-12-15 Thread Ralf Wildenhues
Hello James,

* James Andrewartha wrote on Wed, Dec 13, 2006 at 05:23:01PM CET:
 On Wed, 13 Dec 2006, Ralf Wildenhues wrote:
 
  Where are libnss3.so, libsmime3.so, libssl3.so, and libsoftokn3.so
  located?  Could you rerun 'make' non-parallel so we see which link
  is actually failing?
 
 They're located in 
 /scratch/gnometinderbox/jhautobuild/build-output/lib/xulrunner-1.8.1.1
 which is included via -L. pkg-config --libs xulrunner-nspr returns:
 -L/scratch/gnometinderbox/jhautobuild/build-output/lib/xulrunner-1.8.1.1 
 -lplds4 -lplc4 -lnspr4 -lpthread -ldl

Your libtool has link_all_deplibs=no (see the --config output).  This
shows that it's Debian's modified libtool.  It avoid linking against
indirect dependencies.  This change has not made it into GNU Libtool
because it has bugs, and also because it has some different semantics
which would need to be documented.  From the information you posted,
both of these alternative possibilities exist:

1)
You cannot be sure anymore that a library (or program) links against the
dependencies of dependent libraries directly.  So if you need those
depdepls (if you allow me to call them that way), then with Debian's
libtool you need to specify them explicitly on the command line.

2)
If you do not need them in your program, then you just observe a known
bug in Debian's libtool: while linking against uninstalled libraries,
the paths to depdepls are not found correctly, because libtool does not
walk the dependency path.

I think you are seeing (2).  In that case you could work around the
issue by linking directly against the needed libs, by adding these
arguments to the link (if you use Automake, add them to
create_account_LDADD):
  
/scratch/gnometinderbox/jhautobuild/build-output/lib/xulrunner-1.8.1.1/libnss3.la
  
/scratch/gnometinderbox/jhautobuild/build-output/lib/xulrunner-1.8.1.1/libsmime3.la
  
/scratch/gnometinderbox/jhautobuild/build-output/lib/xulrunner-1.8.1.1/libssl3.la
  
/scratch/gnometinderbox/jhautobuild/build-output/lib/xulrunner-1.8.1.1/libsoftokn3.la
  
Or you could just avoid Debian's libtool.  You could also file a bug
with them (point to this thread then, please).

Hope that helps.

Cheers,
Ralf

 failing build:
 make[4]: Entering directory 
 `/scratch/gnometinderbox/jhautobuild/cvs/evolution-data-server/addressbook/backends/groupwise'
 /bin/sh ../../../libtool --tag=CC --mode=link gcc  -O2 -Wall 
 -Wno-unknown-pragmas -Wno-strict-aliasing -Wno-format -Wno-cast-align -
 Wall -Wmissing-prototypes  -Wno-sign-compare   -o create-account 
 create-account.o ../../../addressbook/libedata-book/libedata-book-1.2.la 
 ../../../libedataserver/libedataserver-1.2.la 
 ../../../servers/groupwise/libegroupwise-1.2.la -pthread 
 -L/scratch/gnometinderbox/jhautobuild/build-output/lib 
 -L/scratch/gnometinderbox/jhautobuild/build-output/lib/xulrunner-1.8.1.1 
 -lxml2 -lbonobo-2 -lbonobo-activation -lgmodule-2.0 -lgconf-2 -lORBit-2 
 -lgthread-2.0 -lgobject-2.0 -lglib-2.0 -lplds4 -lplc4 -lnspr4 -lpthread 
 -ldl   -lpthread
 gcc -O2 -Wall -Wno-unknown-pragmas -Wno-strict-aliasing -Wno-format 
 -Wno-cast-align -Wall -Wmissing-prototypes -Wno-sign-compare -o 
 .libs/create-account create-account.o -pthread 
 ../../../addressbook/libedata-book/.libs/libedata-book-1.2.so 
 ../../../libedataserver/.libs/libedataserver-1.2.so 
 ../../../servers/groupwise/.libs/libegroupwise-1.2.so 
 -L/scratch/gnometinderbox/jhautobuild/build-output/lib 
 -L/scratch/gnometinderbox/jhautobuild/build-output/lib/xulrunner-1.8.1.1 
 /scratch/gnometinderbox/jhautobuild/build-output/lib/libxml2.so 
 /scratch/gnometinderbox/jhautobuild/build-output/lib/libbonobo-2.so 
 /scratch/gnometinderbox/jhautobuild/build-output/lib/libbonobo-activation.so 
 /scratch/gnometinderbox/jhautobuild/build-output/lib/libgmodule-2.0.so 
 /scratch/gnometinderbox/jhautobuild/build-output/lib/libgconf-2.so 
 /scratch/gnometinderbox/jhautobuild/build-output/lib/libORBit-2.so 
 /scratch/gnometinderbox/jhautobuild/build-output/lib/libgthread-2.0.so 
 /scratch/gnometinderbox/jhautobuild/build-output/lib/libgobject-2.0.so 
 /scratch/gnometinderbox/jhautobuild/build-output/lib/libglib-2.0.so 
 -lplds4 -lplc4 -lnspr4 -ldl -lpthread -Wl,--rpath 
 -Wl,/scratch/gnometinderbox/jhautobuild/build-output/lib
 /usr/bin/ld: warning: libnss3.so, needed by 
 /scratch/gnometinderbox/jhautobuild/cvs/evolution-data-server/camel/.libs/libcamel-1.2.so.0,
  
 not found (try using -rpath or -rpath-link)


___
Bug-libtool mailing list
Bug-libtool@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-libtool


Re: bug in libtool rpath setting for _LT_AC_TAGVAR(hardcode_libdir_flag_spec, $1) (libtool 1.5.22)

2006-12-13 Thread Ralf Wildenhues
Hello James,

Thanks for the report.

* James Andrewartha wrote on Wed, Dec 13, 2006 at 12:53:32AM CET:
 
 The stable libtool release has a bug in libtool.m4 that sets 
 _LT_AC_TAGVAR(hardcode_libdir_flag_spec, $1) to '${wl}--rpath ${wl}$libdir'
 by default instead of '${wl}-rpath ${wl}$libdir' (one less -). This causes 
 the build failure seen at 
 http://jhbuild.bxlug.be/builds/2006-12-12-0005/logs/evolution-data-server/#build
 
 This was fixed in the development release two years ago:

Yes, but we never knew or thought it was a necessity, we fixed it for
consistency only, thinking that ld accepts both -rpath and --rpath:
http://lists.gnu.org/archive/html/libtool-patches/2004-11/msg00039.html

And if you look closer at the build log, you'll find earlier link
command lines that succeed with --rpath.  So the failure is of a
different nature, but it does look like it could be a libtool bug.
Where are libnss3.so, libsmime3.so, libssl3.so, and libsoftokn3.so
located?  Could you rerun 'make' non-parallel so we see which link
is actually failing?

Could you post
  ./libtool --config

for the libtool script generated by the build, from the
/scratch/gnometinderbox/jhautobuild/cvs/evolution-data-server directory?

Also interesting would be (bzip2'ed) log of

  cd /scratch/gnometinderbox/jhautobuild/cvs/evolution-data-server/camel
  rm libcamel-1.2.la
  make libcamel-1.2.la LIBTOOL='../libtool --debug'

and similar for the link that is actually failing.

Thanks,
Ralf


___
Bug-libtool mailing list
Bug-libtool@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-libtool


Re: 1.5.22 running ldconfig for unknown reason

2006-10-24 Thread Ralf Wildenhues
Hi Akim,

Thanks for the report.

* Akim Demaille wrote on Tue, Oct 24, 2006 at 11:23:07AM CEST:
 
 I have not investigated the following, so for a start I would just
 like to know whether the following is expected or not (doesn't
 seem to be):

Yeah, looks like a missed optimization that can be done if
--disable-shared.  How did you configure, what's
  ./libtool --features
  ./libtool --config
?

I think we can't really test ldconfig at configure time because it may
be accessible to root only (and thus only available at make install
time).  I'm not sure whether we can take cross-compilation as a reason
for not running it though.

Another problem is that, at `libtool --finish' time, we cannot really
know if the libraries we just installed (we don't even know which they
were!) were static-only or not; anyway running ldconfig usually doesn't
hurt.

 [EMAIL PROTECTED] ~/src/urbi/kernel1 $ sudo make install -C _build/aibo/src
 PATH=$PATH:/sbin ldconfig -n /usr/local/gostai/kernel/mipsel-linux/aibo
 ../libtool: line 1: ldconfig: command not found
 
 As you can see ldconfig is run although the library is not
 dynamic (and besides, it's cross-compiled, so I'm not sure
 it makes sense anyway, but how could it know it?).  And it
 doesn't seem to catch the failure, which is a bug I guess.
 
 I'm not sure my situation is really valid, as I already started
 to discuss with Ralf in the following unfinished thread (lack
 of time...).
 
 http://lists.gnu.org/archive/html/libtool/2006-09/msg00109.html

Yeah, installing convenience archives is not so clean.  But people do
uglier things all the time...

Cheers,
Ralf


___
Bug-libtool mailing list
Bug-libtool@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-libtool


Re: [GNU Autoconf 2.60] testsuite: 3 120 failed

2006-10-12 Thread Ralf Wildenhues
[ removing bug-autoconf, adding bug-libtool ]

Hello Paul,

* Paul Eggert wrote on Wed, Oct 11, 2006 at 11:52:13PM CEST:
 Stepan Kasal [EMAIL PROTECTED] writes:
 
  3) AS_EXECUTABLE_P is reduced to `test -x' (on modern hosts).
  (See the attached autoconf-20061009-bin-sh-3.patch.)
  IIRC, the current implementation of AS_EXECUTABLE_P is a result of a
  long discussion.  In particular, mere `test -x' was refused because
  it is true for a directory, and one might encounter a directory named
  `perl' somewhere in PATH.
 
 OK, but we should still have a macro that expands to plain test -x,
 since sometimes it is useful to test whether the installer has the
 x permission on a file or directory or whatever.
 
 I installed this patch instead; it preserves the semantics of
 AS_EXECUTABLE_P and adds a new macro AS_TEST_X that behaves like test -x.

This patch kills $as_executable_p.  This breaks libtool.m4 from
Libtool-1.5.22 (and possibly CVS HEAD, I haven't checked).
Yes, it uses $as_executable_p instead of AS_EXECUTABLE_P, but since
neither are documented, it's not even clear which would be worse.

If it were only for Libtool, it'd be bad enough but fixable (with some
pushing for another release soon), but google tells me there are more
problem candidates out there.

Apologies in advance for more such bugs out there; I know Libtool uses
quite a few undocumented Autoconf things (some of which are known), but
I haven't had the time to do an audit yet.  OTOH, I would be much more
inclined to do so if Autoconf documented more of m4sh.  (And yes, I very
well acknowledge that I was part in postponing those documentation
additions back then.)

Thank you,
Ralf

 2006-10-11  Paul Eggert  [EMAIL PROTECTED]
 
   * lib/m4sugar/m4sh.m4 (AS_TEST_X): New macro.
   (AS_EXECUTABLE_P): Use as_test_x rather than as_executable_p.
   (_AS_TEST_PREPARE): Set as_test_x rather than as_executable_p.
   Use a better substitute, by inspecting the output of ls
   rather than just using :.
   * lib/autoconf/general.m4 (_AC_LINK_IFELSE): Use AS_TEST_X
   rather than AS_EXECUTABLE_P, since we needn't worry about
   non-regular files here.


___
Bug-libtool mailing list
Bug-libtool@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-libtool


Re: how to turn off shared library notice in output of make install?

2006-09-28 Thread Ralf Wildenhues
Hello Kent,

* Kent Boortz wrote on Thu, Sep 28, 2006 at 06:00:12AM CEST:
 
 I have been toying with an idea to create a wiki or something that is
 a GNU autotools cookbook. Not a tutorial, but more like the Perl
 cookbook. Unfortunately I still know way too little about the GNU
 autotools to fill in enough material for it to be useful.

If you want a tutorial, then the answer is this:
http://www-src.lip6.fr/~Alexandre.Duret-Lutz/autotools.html

If that is unclear, wrong, or missing things you think it also needs,
then by all means please write to the author.

I agree that it's not sufficient; there are of course the three manuals.
But still, a FAQ type of document is missing as well.  IMHO it would be
helpful if savannah.gnu.org offered projects a wiki of some sort -- I'd
prefer contributing to a site that can be expected to last longer than
an individual's commitment; and also it would facilitate avoiding too
much duplication of information.

Cheers,
Ralf


___
Bug-libtool mailing list
Bug-libtool@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-libtool


Re: how to turn off shared library notice in output of make install?

2006-09-27 Thread Ralf Wildenhues
[ Cc:ing bug-libtool ]

Hello Ed,

Thanks for the bug report.

* Ed Hartnett wrote on Wed, Sep 27, 2006 at 03:54:00PM CEST:
 I have shared libraries turned off by default, by having this in my
 configure.ac:
 
 AM_DISABLE_SHARED

 When I build and do a make install, with or without shared libraries,
 I get the following notice in the output:
 
 --
 Libraries have been installed in:
/shecky/n3_new/install/lib
 
 If you ever happen to want to link against installed libraries
[...]
 
 See any operating system documentation about shared libraries for
 more information, such as the ld(1) and ld.so(8) manual pages.
 --
 
 This is all well and good for shared libraries, but can I somehow turn
 off this notice in the case of static libraries only?

Several comments: first, this comment is not written if libtool gets the
option --silent.  With the next Automake release, the user will be able
to use
  configure LIBTOOLFLAGS=--silent

or
  make LIBTOOLFLAGS=--silent

to avoid much of libtool's blabla, and the developer will be able to set
  AM_LIBTOOLFLAGS=--silent

in his Makefile.am.  But I agree that in the static case, the notice is
wrong.  It's not completely superfluous, but maybe only something like
this would suffice:

| --
| Libraries have been installed in:
|/shecky/n3_new/install/lib
| 
| If you ever happen to want to link against installed libraries
| in a given directory, LIBDIR, you can use libtool, and specify
| the full pathname of the library, or use the `-LLIBDIR'
| flag during linking.
| --

Or would people prefer that nothing be output in this case?


Somewhat independently though, I also think that, when a package has
many directories and many makefiles from which libraries are installed,
then it would be neater to only output this blurb once, or at most once
per installation directory.  Or aggregated, as in:

| --
| Libraries have been installed in:
|/shecky/n3_new/install/lib
|/shecky/n3_new/install/lib64
|
| Modules have been installed in:
|/shecky/n3_new/install/lib/foopkg/
[...]

I don't see a trivial way to do this in Automake/Libtool yet, but I
suppose it could be solved at the same time as the inter-makefile
library-installation-order issue is solved.

Cheers,
Ralf


___
Bug-libtool mailing list
Bug-libtool@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-libtool


Re: how to turn off shared library notice in output of make install?

2006-09-27 Thread Ralf Wildenhues
* Ed Hartnett wrote on Wed, Sep 27, 2006 at 04:59:01PM CEST:
 Ralf Wildenhues [EMAIL PROTECTED] writes:
 
  to avoid much of libtool's blabla, and the developer will be able to set
AM_LIBTOOLFLAGS=--silent
 
 But can this be done now? That is, can I somehow send the --silent to
 libtool now?

Not easily I think, no.  Sorry.

Cheers,
Ralf


___
Bug-libtool mailing list
Bug-libtool@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-libtool


Re: --preserve-dup-deps seems not to work

2006-09-13 Thread Ralf Wildenhues
Hello Stefan,

Thanks for the bug report.

* Stefan Traby wrote on Wed, Sep 13, 2006 at 04:01:19AM CEST:
 
 I tried libtool-1.4.3 (which introduced --preserve-dup-deps)
 in addition to 1.5.22 which I use normally:
 
 The long (real-world) output is here:
 http://txt.hello-penguin.com/b841990fcf3769591e90b01c8947e03a.txt
 
 here a short variant:
 /bin/sh ./libtool --preserve-dup-deps --mode=link gcc  -g -O2 -o prog prog.o 
 liba.la libb.la liba.la libb.la 
 gcc -g -O2 -o prog prog.o  ./.libs/liba.a ./.libs/libb.a
 
 I don't know how to make libtool to honor duplicate dependencies.

In this special case, you have two convenience archives liba.la and
libb.la which have a circular dependency (as opposed to: one or both
libraries are to-be-installed static or shared libraries).  I agree
that this case should work.  But this case is also the easiest to work
around: you could add liba.la as a dependency to the link line of
libb.la:
  $LIBTOOL --mode=link --tag=CC $CC $CFLAGS $LDFLAGS -o libb.la \
   b.lo [OBJECTS...] liba.la

This is a bit wasteful in that all objects from liba will also appear
in some form or other in libb, but it should be portable.  It will
require you to add a dependency of libb.la on liba.la in your Makefile
(in case you use Automake it should take care of that, I believe).

I think we should fix this.  Proposed test case below.

Cheers,
Ralf

* tests/duplicate_deps.at: New file.  Test circular depending
convenience archives (currently failing).
* Makefile.am: Update.
Report by Stefan Traby [EMAIL PROTECTED].

Index: Makefile.am
===
RCS file: /cvsroot/libtool/libtool/Makefile.am,v
retrieving revision 1.198
diff -u -r1.198 Makefile.am
--- Makefile.am 12 Sep 2006 18:02:31 -  1.198
+++ Makefile.am 13 Sep 2006 05:48:01 -
@@ -399,6 +399,7 @@
  tests/libtoolize.at \
  tests/duplicate_members.at \
  tests/duplicate_conv.at \
+ tests/duplicate_deps.at \
  tests/inherited_flags.at \
  tests/convenience.at \
  tests/link-order.at \
--- /dev/null   2006-09-05 22:40:33.520458500 +0200
+++ tests/duplicate_deps.at 2006-09-13 07:48:16.0 +0200
@@ -0,0 +1,64 @@
+# Hand crafted tests for GNU Libtool. -*- Autotest -*-
+# Copyright 2006 Free Software Foundation, Inc.
+
+# This program 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, or (at your option)
+# any later version.
+
+# This program 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 this program; if not, write to the Free Software
+# Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA
+# 02110-1301, USA.
+
+AT_SETUP([preserve duplicate convenience deps])
+AT_KEYWORDS([libtool])
+
+# --preserve-dup-deps should work for convenience archives.
+
+# Create a circular dependency of liba and libb:
+# a1 pulls in b1, that pulls in a2.
+cat a1.c \EOF
+extern int b1 ();
+int a1 () { return b1 (); }
+EOF
+cat a2.c \EOF
+int a2 () { return 0; }
+EOF
+cat b1.c \EOF
+extern int a2 ();
+int b1 () { return a2 (); }
+EOF
+cat main.c \EOF
+extern int a1 ();
+int main () { return a1 (); }
+EOF
+
+for file in a1.c a2.c b1.c; do
+  $LIBTOOL --mode=compile $CC $CPPFLAGS $CFLAGS -c $file
+done
+$CC $CPPFLAGS $CFLAGS -c main.c
+$LIBTOOL --mode=link --tag=CC $CC $CFLAGS $LDFLAGS -o liba.la a1.lo a2.lo
+
+# This could be worked around by adding liba.la to libb.la
+# (in that case all objects from liba would be merged into
+# libb.a as well, possibly renamed.)
+$LIBTOOL --mode=link --tag=CC $CC $CFLAGS $LDFLAGS -o libb.la b1.lo liba.la
+AT_CHECK([$LIBTOOL --mode=link --tag=CC \
+ $CC $CFLAGS $LDFLAGS -o main main.$OBJEXT liba.la libb.la],
+ [0], [ignore], [ignore])
+LT_AT_EXEC_CHECK([./main])
+
+# This currently fails:
+AT_XFAIL_IF([:])
+$LIBTOOL --mode=link --tag=CC $CC $CFLAGS $LDFLAGS -o libb.la b1.lo
+AT_CHECK([$LIBTOOL --mode=link --preserve-dup-deps --tag=CC \
+ $CC $CFLAGS $LDFLAGS -o main main.$OBJEXT liba.la libb.la liba.la],
+ [0], [ignore], [ignore])
+
+AT_CLEANUP


___
Bug-libtool mailing list
Bug-libtool@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-libtool


Re: AC_LIBTOOL_SYS_DYNAMIC_LINKER gcc -print-search-dirs problem

2006-09-13 Thread Ralf Wildenhues
Hello Bob, Kate,

* Bob Friesenhahn wrote on Wed, Sep 13, 2006 at 04:34:52PM CEST:
 On Wed, 13 Sep 2006, Kate Minola wrote:
 
 On my x86_64-unknown-linux-gnu system, the m4 macro
 AC_LIBTOOL_SYS_DYNAMIC_LINKER in libtool.m4
 uses gcc -print-search-dirs to set  sys_lib_search_path_spec.

 I think that this is really a GCC bug.  I have the same problem under 
 Solaris.  Libtool should work around the GCC bug by detecting 64-bit 
 compilation and expanding the search path to look in the 64-bit 
 library directories first.

Would it be semantically correct for libtool to make use of any of
  gcc -print-multi-lib
  gcc -print-multi-directory
  gcc -print-multi-os-directory

?  If yes: which, and for which paths?  It seems of those, only the last
is understood by gcc 3.3; I have not tested earlier versions.

Cheers,
Ralf


___
Bug-libtool mailing list
Bug-libtool@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-libtool


Re: AC_LIBTOOL_SYS_DYNAMIC_LINKER gcc -print-search-dirs problem

2006-09-13 Thread Ralf Wildenhues
* Peter O'Gorman wrote on Wed, Sep 13, 2006 at 04:41:56PM CEST:

 As far as I'm aware there is not going to be a fix for this in gcc,  
 so yes, we need to fix it.
 Perhaps something like:
 
 echo int main(){return 0;}  conftest.c
 search_path=`$CC $CFLAGS -c conftest.c 21 | awk 'BEGIN {RS= } /^ 
 [\]?-L/ {sub (-L,);print $0};'`
 rm -f conftest.c conftest.o

Only as a last resort, if you ask me.  Other compilers love to
disguise as gcc, and Autoconf's AC_FC_LIBRARY_LDFLAGS is witness of
how helplessly maintenance-intensive an approach like the above is.

Cheers,
Ralf


___
Bug-libtool mailing list
Bug-libtool@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-libtool


Re: AC_LIBTOOL_SYS_DYNAMIC_LINKER gcc -print-search-dirs problem

2006-09-13 Thread Ralf Wildenhues
* Peter O'Gorman wrote on Wed, Sep 13, 2006 at 04:55:11PM CEST:
 On Sep 13, 2006, at 11:49 PM, Ralf Wildenhues wrote:
 
 Only as a last resort, if you ask me.  Other compilers love to
 disguise as gcc, and Autoconf's AC_FC_LIBRARY_LDFLAGS is witness of
 how helplessly maintenance-intensive an approach like the above is.
 
 That's looking at all kinds of flags, in this case we're only  
 interested in -L.

Alright, feel free to give it a shot.  From the Autoconf macro we know
that
   -LANG:=* | -LIST:* | -LNO:*

should be ignored, for pathscale and some other compilers I have
forgotten now.  Otherwise your awk script seems to work with PGI,
Intel, and PathScale.

Cheers,
Ralf


___
Bug-libtool mailing list
Bug-libtool@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-libtool


Re: AC_LIBTOOL_SYS_DYNAMIC_LINKER gcc -print-search-dirs problem

2006-09-13 Thread Ralf Wildenhues
* Peter O'Gorman wrote on Wed, Sep 13, 2006 at 05:20:28PM CEST:
 On Sep 14, 2006, at 12:12 AM, Ralf Wildenhues wrote:

 Alright, feel free to give it a shot.  From the Autoconf macro we know
 that
-LANG:=* | -LIST:* | -LNO:*
 
 should be ignored, for pathscale and some other compilers I have
 forgotten now.  Otherwise your awk script seems to work with PGI,
 Intel, and PathScale.
 
 I don't think we need to worry about that as the test is specific to  
 gcc. However I'll think about it more tomorrow when I hack at it,  
 bedtime here now :)

Oh yes you do.  All compilers I listed can cause
  with_gcc=yes

to be set.  Surely, you can blame them for not being exactly like GCC,
but in practice that won't save us from bug reports.

Also my gcc likes to output stuff like
  /usr/lib/gcc/x86_64-linux-gnu/4.0.3/32
  /usr/lib/gcc/x86_64-linux-gnu/4.0.3
  /usr/lib/gcc/x86_64-linux-gnu/4.0.3/32
  /usr/lib/gcc/x86_64-linux-gnu/4.0.3
  /usr/lib/gcc/x86_64-linux-gnu/4.0.3/../../../../lib32
  /usr/lib/gcc/x86_64-linux-gnu/4.0.3/../../..
  /lib/../lib32
  /usr/lib/../lib32

for -m32, and
  /usr/lib/gcc/x86_64-linux-gnu/4.0.3
  /usr/lib/gcc/x86_64-linux-gnu/4.0.3
  /usr/lib/gcc/x86_64-linux-gnu/4.0.3/../../../../lib64
  /usr/lib/gcc/x86_64-linux-gnu/4.0.3/../../..
  /lib/../lib64
  /usr/lib/../lib64

without a flag (i.e., -m64).  Looks kinda scary to not have /usr/lib and
/usr/lib32 and /usr/lib64 in this list.  I propose to put both the
unnormalized and normalized paths (`cd $path  pwd`) in the list.  On
my system, that will still not get you /usr/lib (to which lib64 is a
symlink), so there is still a problem (you certainly don't want to get
run paths due to a /usr/lib/libfoo.la).  :-/

Furthermore, your test needs a $CPPFLAGS (it's valid to put -m32 in
CPPFLAGS and LDFLAGS).

Cheers,
Ralf


___
Bug-libtool mailing list
Bug-libtool@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-libtool


Re: automake/libtool question

2006-09-12 Thread Ralf Wildenhues
Hello David,

* David Everly wrote on Tue, Sep 12, 2006 at 02:11:16PM CEST:
 On 9/12/06, Ralf Wildenhues [EMAIL PROTECTED] wrote:
 * David Everly wrote on Tue, Sep 12, 2006 at 01:02:47AM CEST:
 
  HP-UX B.11.23 U ia64

  Libtool is creating a script that wrappers the non-installed foo, and
  sets the LD_LIBRARY_PATH accordingly _except_ that there is no
  reference to the installed non-libtool-created library paths.
 
 Are you speaking about the case with -R/some/path or without?
 
 Yes, the ones using -R/some/path don't find themselves with
 corresponding entries to LD_LIBRARY_PATH in the wrapper script.

Ah yes, on HP-UX/IA shlibpath_overrides_runpath=yes, unlike on HP-UX/PA.

 If with, then why does it not work out of the box, i.e., without
 having to amend LD_LIBRARY_PATH?
 
 The reason I found this, is that someone had inadvertently set
 LD_LIBRARY_PATH to an older version of the library in a different
 directory.  During our build we need to run the executable from the
 build directory, and since they had LD_LIBRARY_PATH set, it superseded
 the -R/some/path, and this caused failure.

Yep.  OK, I think I understand.  IIRC some of these failures are
fixable, and some are not (easily portably fixable).  I need more
information in order to decide which class yours belongs to.

 This alone, does not make me think there is a libtool bug, but the
 fact that paths are inconsistently added to LD_LIBRARY_PATH does.

This suggests that this one could be fixable (since libtool does not
decide avoidtemprpath=yes).  But say, you also link to uninstalled
libtool libraries, right?

 Looking in the wrapper script, I noticed that, even though chatr of
 the actual executable showed similarly hard coded paths to both the
 libtool-created libraries as to the -R/some/path ones, there was the
 inconsistency the -R/some/path entries not being present in
 LD_LIBRARY_PATH.

Yep.  If this one turns out to be non-fixable, we may just have to
document that users may need to do both for linking against non-libtool
libraries: add -R/some/path to LDFLAGS, and /some/path to
$shlibpath_var.  Not sure yet.

 On our HP system, it might even be argued that the wrapper script
 should ensure that LD_LIBRARY_PATH is not set so that all the paths
 compiled in by libtool  can be honored.

Oh.  Well, then all those people would start crying that installed
proprietary compilers which themselves force the user to set
LD_LIBRARY_PATH to some given value so that the compiler-provided
libraries are found at runtime.

 (I don't deny that there could be a bug; if there is, then we should add
 a test case to expose it, and fix it.)
 
 I suppose a test case would be to build and install (not to the system
 path) a libtool library and a non-libtool library to mutually
 exclusive paths.  Then use libtool to link an executable to both
 shared libraries.

Is the executable in your test case linked directly to the installed
non-libtool library, or is that dependency pulled in through some
uninstalled libtool library?  (I'll try to come up with a test then,
or if you feel adventurous, feel free to do so too, preferably an
Autotest style test for the CVS HEAD version of Libtool.)

Cheers,
Ralf


___
Bug-libtool mailing list
Bug-libtool@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-libtool


Re: Fw: Re: gmake .... seems to be moved...

2006-09-05 Thread Ralf Wildenhues
Hello Maurizio,

There was a small misunderstanding.  With this line below:

 Please print the complete link command line that fails (the one that
 starts with .../libtool --mode=link) and its output, with --debug
 added as the first libtool option:
   .../libtool --debug --mode=link ... link-log 21

I meant you should run
/bin/bash ../libtool --debug --mode=link gcc  -DG_DISABLE_DEPRECATED -g -O2 \
 -g -Wall   -o libgtk-x11-2.0.la  -version-info 1000:2:1000 -export-dynamic \
  -export-symbols-regex ^[^_].* -rpath /usr/lib  fnmatch.lo \
  gtkaboutdialog.lo gtkaccelgroup.lo gtkaccellabel.lo gtkaccelmap.lo \
  gtkaccessible.lo gtkaction.lo gtkactiongroup.lo gtkadjustment.lo \
  [ ... lots of stuff deleted ... ]
  gtktrayicon-x11.lo   ../gdk-pixbuf/libgdk_pixbuf-2.0.la \
  ../gdk/libgdk-x11-2.0.la -L/usr/openwin/lib -R/usr/openwin/lib -lXrender \
  -lX11 -lsocket -lnsl -lpangocairo-1.0 -lpango-1.0 -latk-1.0 \
  -lgobject-2.0 -lgmodule-2.0 -lglib-2.0 -lintl -liconv -lcairo -lm \
  xdgmime/libxdgmime.la

That is the failing link command with '--debug' added.  In practice, you
would either run 'make', and copy and paste the command from its output
to your shell terminal and add '--debug' manually, and rerun as above;
or you fiddle with the Makefile to add the --debug there.

Cheers,
Ralf


___
Bug-libtool mailing list
Bug-libtool@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-libtool


Re: gmake .... seems to be moved...

2006-09-05 Thread Ralf Wildenhues
* Caloro Maurizio wrote on Tue, Sep 05, 2006 at 02:15:43PM CEST:
 
 Sorry for the mistake, i think now i have the correct one

Yes, the correct command.  Now please issue it in the
/usr/source/gtk+-2.10.2/gtk directory.  If you omit the
--debug, it should give the same errors as the ones you
originally reported.  I apologize for being sloppy in my
descriptions.

Cheers,
Ralf


___
Bug-libtool mailing list
Bug-libtool@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-libtool


Re: Fwd: Re: gmake .... seems to be moved...

2006-09-05 Thread Ralf Wildenhues
* Caloro Maurizio wrote on Tue, Sep 05, 2006 at 03:57:29PM CEST:
 
 LDFLAGS=-L/usr/lib; export LDFLAGS; /bin/bash ../libtool --debug 
 
 i see on the file on line 17775, 17790, 18011 end on the end
 start to swap with /usr/local/lib. 
 
 but its all under /usr/lib at home
 i dont know why he swap ...

The culprit is /usr/lib/libatk-1.0.la.  It contains references to
/usr/local:
  dependency_libs=' -L/usr/local/lib /usr/local/lib/libgobject-2.0.la 
/usr/local/lib/libgmodule-2.0.la /usr/local/lib/libglib-2.0.la 
/usr/local/lib/libintl.la /usr/local/lib/libiconv.la -lc'

If you know that all of the libraries libatk was linked against are
installed in /usr/lib (or binary compatible ones), then you may edit
the file /usr/lib/libatk-1.0.la and fix these references.

Cheers,
Ralf


___
Bug-libtool mailing list
Bug-libtool@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-libtool


Re: gmake .... seems to be moved...

2006-09-04 Thread Ralf Wildenhues
Hello Caloro,

Thanks for the report.  To decide whether this is a bug, we need more
information:

* Caloro Maurizio wrote on Mon, Sep 04, 2006 at 03:46:16PM CEST:
 
 my solaris has the following status SunOS filemoon 5.9
 Generic_118559-11 i86pc i386 i86pc
 
 GCC-4.1.1
 Binutils-2.17
 Libtool-2.1a

 configure run without error messages
 [./configure --prefix=/usr --exec-prefix=/usr --sysconfdir=/etc --with-gnu-ld]
 
 .[Make]
 -lpangocairo-1.0 -lpango-1.0 -latk-1.0 -lgobject-2.0 -lgmodule-2.0 -lglib-2.0 
 -lintl -liconv -lcairo -lm xdgmime/libxdgmime.la
 libtool: link: warning: 
 `/usr/lib/gcc/i386-pc-solaris2.9/4.1.1/../../..//libgmodule-2.0.la' seems to 
 be moved
*snip*

 grep: /usr/local/lib/libgobject-2.0.la: No such file or directory
 Can't open /usr/local/lib/libgobject-2.0.la
 libtool: link: `/usr/local/lib/libgobject-2.0.la' is not a valid libtool 
 archive

Please print the complete link command line that fails (the one that
starts with .../libtool --mode=link) and its output, with --debug
added as the first libtool option:
  .../libtool --debug --mode=link ... link-log 21

And also please show
  .../libtool --config

It may also help if you pointed a URL to the exact package you were
compiling (but probably that is rather not so important).  Please pack
large output with gzip or bzip2.

Cheers,
Ralf


___
Bug-libtool mailing list
Bug-libtool@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-libtool


  1   2   3   >