Re: [patch #6416] AmigaOS4 support in libtool
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
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
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
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
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]
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
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]
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]
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]
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
* 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]
* 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]
* 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]
* 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]
* 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
* 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]
* 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
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
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)
* 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)
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: Can't build Win32 DLL that links with static libraries
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: [libtool 2.2] testsuite: 34 failed
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
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
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
* 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
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
* 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
[ 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
* 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
[ 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.
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
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
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
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
* 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
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
* 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
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
[ 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
* 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
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
* 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
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
* 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
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
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
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: handling of -B with libtool
* 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
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
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
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
* 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 fails to build working binary when -no-install is used
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
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 ?
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 ?
* 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
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
* 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
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)
* 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)
* 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
* 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
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
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
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
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?
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
* 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?
* 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
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
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
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?
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
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.
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 ...
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
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)
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)
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
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
[ 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?
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?
[ 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?
* 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
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
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
* 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
* 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: automake/libtool question
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...
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...
* 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...
* 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...
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
Re: gmake .... seems to be moved...
* Ralf Wildenhues wrote on Mon, Sep 04, 2006 at 03:54:42PM CEST: Hello Caloro, Erm, apologies for messing up your first and last name, Maurizio. Cheers, Ralf ___ Bug-libtool mailing list Bug-libtool@gnu.org http://lists.gnu.org/mailman/listinfo/bug-libtool
Re: picewise linking and MS lib.exe
Hello Christopher, * Christopher Hulbert wrote on Sun, Aug 27, 2006 at 07:21:25PM CEST: Piecewise linking with the MS archiver (lib) doesn't work. Every invocation of the lib clobbers the old one. The solution is to list the library as the first object (really anywhere should be fine) in the next lib command. If I remember correctly, response files are not a feature of MSVC but of w32, so they should work with `lib' as well, right? Let's see to a fix when we know this. Which patch(es) against Libtool are you using to make MSVC support work? Cheers, Ralf ___ Bug-libtool mailing list Bug-libtool@gnu.org http://lists.gnu.org/mailman/listinfo/bug-libtool
Re: picewise linking and MS lib.exe
* Christopher Hulbert wrote on Mon, Aug 28, 2006 at 11:53:30AM CEST: Ah, I forgot about the MSVC patches (i.e. I didn't apply any patches, it was a fresh checkout of the libtool cvs sources). I'll search the patches for it and see if that helps. Is there any reason it's not already applied (like testing)? FWIW, I have yet to sort out some updates to Peter's last posted version. And the primary reason the outstanding bits are not applied is that they cause regressions on unrelated systems, and need more testing on some. Cheers, Ralf ___ Bug-libtool mailing list Bug-libtool@gnu.org http://lists.gnu.org/mailman/listinfo/bug-libtool
Re: libtool bug
Hello Eytan, Eytan Barouch writes: I downloaded and installed autoconf-2.59 libtool-1.5.22 libmad-0.15.1b/ automake-1.9.6 a52dec-0.7.4 and ogle-0.9.2 on SUSE9.3 with a P4 3.33GHz chip Toshiba laptop. I followed all instructions and in the final make stage I got: libtool: unrecognized option `--tag=CC' Try `libtool --help' for more information. This sounds like some older version of libtoolize was inadvertently used. What does ./libtool --version (note the leading ./ for the script in the build tree) say? Cheers, Ralf ___ Bug-libtool mailing list Bug-libtool@gnu.org http://lists.gnu.org/mailman/listinfo/bug-libtool
Re: OBJDUMP incorrect on cross-compiles to mingw32
Hi Simon, Thanks for the report. However, I do not think this is a bug: * Simon Josefsson wrote on Wed, Jun 21, 2006 at 03:48:08PM CEST: Hi! I'm using Debian's mingw32 packages to build native win32 DLL/EXE's with libtool. I'm configuring with: --host=i586-mingw32msvc --build=i686-pc-linux-gnu However, when linking a shared library, I get this error: [...] # Used on cygwin: object dumper. OBJDUMP=objdump This is incorrect on my system, the objdump binary is the i686-pc-linux-gnu objdump, which doesn't understand the Windows DLLs. The correct objdump would be called i586-mingw32msvc-objdump. Do you use AC_LIBTOOL_WIN32_DLL? Cheers, Ralf ___ Bug-libtool mailing list Bug-libtool@gnu.org http://lists.gnu.org/mailman/listinfo/bug-libtool
Re: Cygwin failure with large number of sources
* Christopher Hulbert wrote on Wed, Jun 14, 2006 at 04:37:50PM CEST: On 6/14/06, Ralf Wildenhues [EMAIL PROTECTED] wrote: setting not trigger a multiple archiver invocation? All these questions may be answered by the output of ./libtool --debug [rest of command line] log 21 That won't work. It's crashing I guess trying to call libtool with all those arguments. Ah, there is a fix for this: Create a file with all objects listed in it. Use it as argument to the libtool option -objectlist. If you want to create the file from a Makefile, and have all the object names in a variable, you could do echo $(ALLOBJECTS) | tr ' ' '\n' libfoo.objectlist but it could possibly fail as well (the shell command being too long, too), leaving you with the need to resort to some other means to create the list, possibly by using make variables which contain only subsets of object names which are short enough for the command line. If that still fails, but now inside libtool, post as decribed above. Cheers, Ralf ___ Bug-libtool mailing list Bug-libtool@gnu.org http://lists.gnu.org/mailman/listinfo/bug-libtool
