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]
On 6 Mar 2008, at 02:05, Bob Friesenhahn wrote: On Thu, 6 Mar 2008, Ralf Wildenhues wrote: 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. I was not able to find where libtool 'requests' a lzma package but I do see that all of the Makefile.in files in the distribution include a target for it (dist-lzma). Libtool was bootstrapped using Automake-1.10.1, but there is no reason that users of Libtool-2.2 need to use it too. I was careful to build the lzma release files by hand to compensate for not offering xdeltas or diffs -- and didn't introduce a dependency on the lzma rules to libtool-2.2 so that compatibility with older Automakes wasn't compromised. The reported error message seems quite strange, particularly since LZMA is in caps. I agree with Peter's diagnosis... Nelson's Automake installation seews broken somehow: that's a perl failure in the Automake code AFAICT. The reported errors occur when am-subdir.at run Nelson's automake (which is at least version 1.10, judging by the log messages. Cheers, Gary -- ())_. Email me: [EMAIL PROTECTED] ( '/ Read my blog: http://blog.azazil.net / )= ...and my book: http://sources.redhat.com/autobook `(_~)_ PGP.sig Description: This is a digitally signed message part ___ 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 2.2] testsuite: 19 35 36 44 45 46 48 49 50 51 52 53 60 61 62 64 failed [GNU/Linux PowerPC]
On Thu, 6 Mar 2008, Ralf Wildenhues wrote: 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? My feeling is that the sooner a fundamental problem with a compiler is found, the better, so it makes sense to adequately sanity-check all compilers that libtool is configured for in the configure script. If the compiler does not pass a basic sanity check, then libtool should not support the associated language tag. If the package specifies that it needs that language, then configure should quit with an error. Bob == Bob Friesenhahn [EMAIL PROTECTED], http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ ___ 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]
Ralf Wildenhues wrote: 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! Yes, thank you Nelson. 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? 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. 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. Peter -- Peter O'Gorman http://pogma.com ___ 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]
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. 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). 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. Bob == Bob Friesenhahn [EMAIL PROTECTED], http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ ___ 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 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
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]
Ralf Wildenhues wrote: * 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). Your call. 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. Peter -- Peter O'Gorman http://pogma.com ___ 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]
On Thu, 6 Mar 2008, Peter O'Gorman wrote: 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. I agree with most of this (ammended for cross-compile) except that it is wrong to assume that users watch configure output while it runs. Most people seem to use that time to get a cup of coffee (or another Canadian beer). 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. Bob == Bob Friesenhahn [EMAIL PROTECTED], http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ ___ 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 35 36 44 45 46 48 49 50 51 52 53 60 61 62 64 failed [GNU/Linux PowerPC]
[[libtool-patches removed from Cc:]] On 6 Mar 2008, at 16:52, Ralf Wildenhues wrote: * 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. Good point. Although an LT_ macro to spew a diversion collecting libtool configure time warnings (or similar) to make it easy for developers to add a consistently formatted summary at the end of their configure.ac still seems like a nice idea to me. Cheers, Gary -- =. Email me: [EMAIL PROTECTED] / @ @ /| Read my blog: http://blog.azazil.net \ \\ ...and my book: http://sources.redhat.com/autobook \^^\\ PGP.sig Description: This is a digitally signed message part ___ 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]
On Thu, 6 Mar 2008, Ralf Wildenhues wrote: 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. I tend to agree with this, but the author of the package needs a way to know that libtool has failed to sufficiently configure and have a way to notify the user. Right now there is no documented way to know if libtool encountered problems during configuration. Bob == Bob Friesenhahn [EMAIL PROTECTED], http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ ___ 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]
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, 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. Thoughts? Peter -- Peter O'Gorman http://pogma.com 2008-03-06 Peter O'Gorman [EMAIL PROTECTED] * libltdl/m4/libtool.m4 (_LT_PROG_FC): Report FC=no if the FC compiler is not a GNU compiler and the CXX compiler is a GNU compiler. Reported by Nelson H. F. Beebe. Index: libltdl/m4/libtool.m4 === RCS file: /sources/libtool/libtool/libltdl/m4/libtool.m4,v retrieving revision 1.138 diff -u -r1.138 libtool.m4 --- libltdl/m4/libtool.m4 4 Mar 2008 21:14:22 - 1.138 +++ libltdl/m4/libtool.m4 7 Mar 2008 01:00:35 - @@ -6644,6 +6644,15 @@ if test -z $FC || test X$FC = Xno; then _lt_disable_FC=yes fi + +# If g++ is being used, but the fortran compiler is not a gnu +# compiler, we should simply ignore it. It will not grok -shared, for +# example. +if test x$ac_cv_fc_compiler_gnu != x$GXX; then + FC=no + _lt_disable_FC=yes +fi + popdef([AC_MSG_ERROR]) ])# _LT_PROG_FC ___ 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]
On Thu, 6 Mar 2008, Peter O'Gorman wrote: 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, 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. This seems ok for now but it does seem that the inability to mix compilers which would otherwise interoperate should be put on the list of future libtool issues to solve for the next big release. It seems perfectly reasonable to use a non-GNU fortran or C++ compiler along with GCC. Bob == Bob Friesenhahn [EMAIL PROTECTED], http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ ___ 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]
On 6 Mar 2008, at 20:04, Peter O'Gorman wrote: 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, 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. Thoughts? What happens to a project written with gnu C and vendor fortran? Will this test spot g++ and refuse to build the fortran files? Maybe we should look into tagging the archive_cmds instead. Cheers, Gary -- =. Email me: [EMAIL PROTECTED] / @ @ /| Read my blog: http://blog.azazil.net \ \\ ...and my book: http://sources.redhat.com/autobook \^^\\ PGP.sig Description: This is a digitally signed message part ___ 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]
Nelson H. F. Beebe wrote: Re: [libtool 2.2] testsuite: 19 64 failed [GNU/Linux IA-32] Hmm. Does the gcj on this system add -liconv at link time, but somehow not add it to the rpath? Thank you for the response. The separate need for -Wl,-rpath,/path/to/something or -R/path/to/something in addition to -L/path/to/something is common on many Unix flavors if executables are to run without an environment variable like LD_LIBRARY_PATH having to be set. We don't use the ld.so.conf feature on GNU/Linux, because we found that it broke too many gnome packages. The gcj in /usr/local/bin does indeed add -liconv, thank you for confirming my suspicion. 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. What does: gcj -### -o /dev/null /dev/null show? I have two versions of gcj on this system: % \which -a gcj /usr/local/bin/gcj /usr/bin/gcj % /usr/bin/gcj --version gcj (GCC) 3.4.6 20060404 (Red Hat 3.4.6-9) % /usr/local/bin/gcj --version gcj (GCC) 3.4.3 % /usr/bin/gcj -### -o /dev/null /dev/null Reading specs from /usr/lib/gcc/i386-redhat-linux/3.4.6/specs Reading specs from /usr/lib/gcc/i386-redhat-linux/3.4.6/libgcj.spec rename spec lib to liborig Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/u sr/share/info --enable-shared --enable-threads=posix --disable-checking --with-s ystem-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-java-aw t=gtk --host=i386-redhat-linux Thread model: posix gcc version 3.4.6 20060404 (Red Hat 3.4.6-9) /usr/libexec/gcc/i386-redhat-linux/3.4.6/collect2 --eh-frame-hdr -m elf_ i386 -dynamic-linker /lib/ld-linux.so.2 -o /dev/null /usr/lib/gcc/i386 -redhat-linux/3.4.6/../../../crt1.o /usr/lib/gcc/i386-redhat-linux/3.4.6/../.. /../crti.o /usr/lib/gcc/i386-redhat-linux/3.4.6/crtbegin.o -L/usr/local/sys/ FortranPlus/fplus_55h/lib -L/usr/lib/gcc/i386-redhat-linux/3.4.6 -L/usr/lib/ gcc/i386-redhat-linux/3.4.6 -L/usr/lib/gcc/i386-redhat-linux/3.4.6/../../.. /dev/null -lgcc_s -lgcc -lgcj -lm -lpthread -lz -ldl -lgcc_s - lgcc -lc -lgcc_s -lgcc /usr/lib/gcc/i386-redhat-linux % /usr/local/bin/gcj -### -o /dev/null /dev/null Reading specs from /export/local/i386-linux/bin/../lib/gcc/i686-pc-linux-gnu/3.4 .3/specs Reading specs from /export/local/i386-linux/bin/../lib/gcc/i686-pc-linux-gnu/3.4 .3/../../../libgcj.spec rename spec lib to liborig Configured with: ../gcc-3.4.3/configure Thread model: posix gcc version 3.4.3 /export/local/i386-linux/bin/../libexec/gcc/i686-pc-linux-gnu/3.4.3/collect2 --eh-frame-hdr -m elf_i386 -dynamic-linker /lib/ld-linux.so.2 -o /d ev/null /usr/lib/crt1.o /usr/lib/crti.o /export/local/i386-linux/bin/../li b/gcc/i686-pc-linux-gnu/3.4.3/crtbegin.o -L/export/local/i386-linux/bin/../lib /gcc/i686-pc-linux-gnu/3.4.3 -L/export/local/i386-linux/bin/../lib/gcc -L/us r/local/sys/FortranPlus/fplus_55h/lib -L/usr/local/lib/gcc/i686-pc-linux-gnu/3 .4.3 -L/export/local/i386-linux/bin/../lib/gcc/i686-pc-linux-gnu/3.4.3/../../. ./../i686-pc-linux-gnu/lib -L/usr/local/lib/gcc/i686-pc-linux-gnu/3.4.3/../../ ../../i686-pc-linux-gnu/lib -L/export/local/i386-linux/bin/../lib/gcc/i686-pc- linux-gnu/3.4.3/../../.. -L/usr/local/lib/gcc/i686-pc-linux-gnu/3.4.3/../../.. /dev/null -lgcc_s -lgcc -lgcj -lm -liconv -lpthread -ldl -lgc c_s -lgcc -lc -lgcc_s -lgcc /export/local/i386-linux/bin/../lib/gcc/i6 86-pc-linux-gnu/3.4.3/crtend.o /usr/lib/crtn.o Thank you. Peter -- Peter O'Gorman http://pogma.com ___ 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]
Bob Friesenhahn wrote: On Thu, 6 Mar 2008, Peter O'Gorman wrote: 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, 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. This seems ok for now but it does seem that the inability to mix compilers which would otherwise interoperate should be put on the list of future libtool issues to solve for the next big release. It seems perfectly reasonable to use a non-GNU fortran or C++ compiler along with GCC. Thanks. I committed it. Not that I like it either :( Peter -- Peter O'Gorman http://pogma.com ___ 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]
Gary V. Vaughan wrote: On 6 Mar 2008, at 20:04, Peter O'Gorman wrote: 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, 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. Thoughts? What happens to a project written with gnu C and vendor fortran? Will this test spot g++ and refuse to build the fortran files? Depends on if those fortran compilers have their own rules or if they are inheriting. Maybe we should look into tagging the archive_cmds instead. I did not see this mail til just now (after the commit). Want me to revert? Peter -- Peter O'Gorman http://pogma.com ___ 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]
Ralf Wildenhues wrote: I find this patch very very ugly. It's a confession that after a decade, we still can't get multi-lang right. I'm pretty sure that it will cause regressions for some people, too. Ok - reverting. Btw, fixed my spam filter, now you and gary do not end up in spam mailbox :) Peter -- Peter O'Gorman http://pogma.com ___ 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]
Ralf Wildenhues wrote:
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=
Fixed with attached patch. Committed as obvious.
Thanks for pointing me in the right direction.
Peter
--
Peter O'Gorman
http://pogma.com
2008-03-07 Peter O'Gorman [EMAIL PROTECTED]
* libltdl/m4/libtool.m4 (_LT_LANG_GCJ_CONFIG): Need to set LD.
Reported by Nelson H. F. Beebe.
Index: libltdl/m4/libtool.m4
===
RCS file: /sources/libtool/libtool/libltdl/m4/libtool.m4,v
retrieving revision 1.140
diff -u -r1.140 libtool.m4
--- libltdl/m4/libtool.m4 7 Mar 2008 06:14:26 - 1.140
+++ libltdl/m4/libtool.m4 7 Mar 2008 06:37:46 -
@@ -6815,6 +6815,7 @@
CC=${GCJ-gcj}
compiler=$CC
_LT_TAGVAR(compiler, $1)=$CC
+_LT_TAGVAR(LD, $1)=$LD
_LT_CC_BASENAME([$compiler])
# GCJ did not exist at the time GCC didn't implicitly link libc in.
___
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: The gcj in /usr/local/bin does indeed add -liconv, thank you for confirming my suspicion. 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? Peter -- Peter O'Gorman http://pogma.com 2008-03-07 Peter O'Gorman [EMAIL PROTECTED] * tests/convenience.at (Java convenience archives): Skip test if gcj cannot compile a working executable from .java files. Report by Nelson H. F. Beebe. Index: tests/convenience.at === RCS file: /sources/libtool/libtool/tests/convenience.at,v retrieving revision 1.9 diff -u -r1.9 convenience.at --- tests/convenience.at 6 Mar 2008 19:59:25 - 1.9 +++ tests/convenience.at 7 Mar 2008 07:38:32 - @@ -262,8 +262,10 @@ # 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 +AT_CHECK([$GCJ $GCJFLAGS -c foo1.java || exit 77], [], [ignore], [ignore]) +AT_CHECK([$GCJ $GCJFLAGS --main=foo1 -o foo1 foo1.java A1.java || exit 77],[],[ignore],[ignore]) +AT_CHECK([./foo1$(EXEEXT) || exit 77],[],[ignore],[ignore]) +rm -f foo1.o foo1.obj foo1$(EXEEXT) fi $LIBTOOL --tag=GCJ --mode=compile $GCJ $GCJFLAGS -c foo$i.java ___ 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
