Re: compiler version checks
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Ralf Wildenhues on 4/27/2009 2:05 PM: > Thanks. This finally gave me enough incentive to do something about > this long-standing issue. > > OK to push this Autoconf patch and add Christian and John to THANKS? In general, I'm happy with the idea. But let's answer this question first: > +# Limit stderr logging to avoid copying full manpages. > +_AC_DO_LIMIT([$ac_compiler --version >&AS_MESSAGE_LOG_FD]) > +_AC_DO_LIMIT([$ac_compiler -v >&AS_MESSAGE_LOG_FD]) > +_AC_DO_LIMIT([$ac_compiler -V >&AS_MESSAGE_LOG_FD]) > +_AC_DO_LIMIT([$ac_compiler -qversion >&AS_MESSAGE_LOG_FD]) Rather than have four consecutive copies of _AC_DO_LIMIT, wouldn't something more compact like this (untested) snippet work? for ac_option in --version -v -V -qversion ; do _AC_DO_LIMIT([$ac_compiler $ac_option >&AS_MESSAGE_LOG_FD]) done - -- Don't work too hard, make some time for fun as well! Eric Blake e...@byu.net -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkn2SeIACgkQ84KuGfSFAYCAyQCgnDVW0pbM0CHE4G8WY+ohJPur wK8AnjnFoiNvybmfljwD2ZBs6UWh1INg =PYyK -END PGP SIGNATURE-
Re: [patch #6691] FreeMiNT support to libtool 1.5.26 (tested)
Hi Alan,
sorry for the delay.
* Alan Hourihane wrote on Wed, Apr 22, 2009 at 09:13:37PM CEST:
> On Wed, 2009-04-22 at 20:34 +0200, Ralf Wildenhues wrote:
> > * Alan Hourihane wrote on Wed, Apr 22, 2009 at 06:09:33PM CEST:
> > > These came up as the failures. The tests 16 & 73 seems to be exposing a
> > > linker bug that I'm looking at now. I'm sure the others are due to the
> > > fact that FreeMiNT doesn't have shared libraries or dlopen support. So I
> > > guess I need to tweak some other configuration files someplace.
> >
> > Can you send the tests/testsuite.log file also? Thanks!
>
> Sure, attached.
The log file indicates that running the new testsuite alone took 13
hours already. Whew. Thank You for going through this pain.
Perusing the log, I see that I need more information about this system,
listed as m68k-atari-mint. First off, is there some web site with good
information about the compiler, linker, runtime linker on this system?
You stated that this system does not provide any kind of shared
libraries. Is it planned that this changes at some point in the future?
More comments inline.
> uname -m = falcon
> uname -r = 1.17a
> uname -s = FreeMiNT
> uname -v = 4.4
>
> /usr/bin/uname -p = mc68060
> /bin/uname -X = unknown
> testsuite: starting at: Wed Apr 22 01:15:39 Local time zone must be set--see
> zic manual page 2009
> 1. libtoolize macro installation (libtoolize.at:83): ok (0m1.440s
> 0m22.160s)
[...]
> testsuite: ending at: Wed Apr 22 14:11:45 Local time zone must be set--see
> zic manual page 2009
> testsuite: test suite duration: 12h 56m 5s
> 16. duplicate_conv.at:25: testing ...
> ./duplicate_conv.at:79: $LIBTOOL --mode=link --tag=CC $CC $CFLAGS $LDFLAGS -o
> cee.$OBJEXT c.lo a/liba.la b/liba.la
> stderr:
> stdout:
> libtool: link: (cd .libs/cee.ox/liba.a && ar x
> "/tmp/libtool-2.2.6-mint/tests/testsuite.dir/16/a/.libs/liba.a")
> libtool: link: (cd .libs/cee.ox/lt1-liba.a && ar x
> "/tmp/libtool-2.2.6-mint/tests/testsuite.dir/16/b/.libs/liba.a")
> libtool: link: /j/usr/m68k-atari-mint/bin/ld -r -o cee.o
> .libs/cee.ox/liba.a/a.o .libs/cee.ox/lt1-liba.a/a.o
> .libs/cee.ox/lt1-liba.a/b.o
> libtool: link: rm -fr ".libs/cee.ox"
> ./duplicate_conv.at:81: $LIBTOOL --mode=link $CC $CFLAGS $LDFLAGS -o main
> main.$OBJEXT cee.$OBJEXT
> stderr:
> gcc: Internal error: Bus Error (program ld)
> Please submit a full bug report.
> See http://bugs.gentoo.org/> for instructions.
> stdout:
> libtool: link: gcc -g -O2 -o main main.o cee.o
> ./duplicate_conv.at:81: exit code was 1, expected 0
> 16. duplicate_conv.at:25: 16. duplicate convenience archive names
> (duplicate_conv.at:25): FAILED (duplicate_conv.at:81)
Two bugs here: one known bug in ltmain.m4sh, in that we do reloading of
non-PIC objects wrongly (c.o is forgotten).
The second issue looks like an error in gcc or the link editor. I bet
it's a problem with the earlier 'ld -r', that tends to be buggy
sometimes, as it typically receives less testing. However, as it
happens after the libtool bug, it may not be all that relevant to fix
it. You can try whether it still shows up after
cd tests/testsuite.dir/16
(cd .libs/cee.ox/liba.a && ar x
"/tmp/libtool-2.2.6-mint/tests/testsuite.dir/16/a/.libs/liba.a")
(cd .libs/cee.ox/lt1-liba.a && ar x
"/tmp/libtool-2.2.6-mint/tests/testsuite.dir/16/b/.libs/liba.a")
/j/usr/m68k-atari-mint/bin/ld -r -o cee.o c.o .libs/cee.ox/liba.a/a.o
.libs/cee.ox/lt1-liba.a/a.o .libs/cee.ox/lt1-liba.a/b.o
rm -fr ".libs/cee.ox"
../../../libtool --mode=link gcc -g -O2 -o main main.o cee.o
Test 73 Run tests with low max_cmd_len (cmdline_wrap.at:28) is just
another instance of this, so there is no need to look at it in further
detail.
> 41. old-m4-iface.at:107: testing ...
> ./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
> Not enabling shell tracing (command contains an embedded newline)
> --- /dev/null 1970-12-31 01:35:46.0 +
> +++ /tmp/libtool-2.2.6-mint/tests/testsuite.dir/at-stderr 2009-04-22
> 02:57:07.0 +
> @@ -0,0 +1 @@
> +error fetching func: symbol not found
> stdout:
> ./old-m4-iface.at:156: exit code was 1, expected 0
> 41. old-m4-iface.at:107: 41. AC_WITH_LTDL (old-m4-iface.at:107): FAILED
> (old-m4-iface.at:156)
There are several test failures that are similar. They look like there
is some bug in the dlpreloading support in Libtool on this system.
I'm still pondering how I can investigate those in a better way without
access to the system; I haven't been able to get a similar issue to show
up on Linux.
> 45. lt_dladvise.at:28: testing ...
> ./lt_dladvise.at:365: $LIBTOOL --mode=link $CC $CFLAGS $LDFLAGS -o main
> main.$OBJEXT $preloaded $modules $LIBLTDL
> stderr:
> ./.libs/libdepend.a(moddepend.o): In function `
Re: Fortran libraries on the Blue Gene with mpi
* Christian Rössel wrote on Mon, Apr 27, 2009 at 05:33:33PM CEST:
> Ralf Wildenhues wrote:
> > However, as a minor note, the logs all show:
> >
> > | checking dependency style of xlc... none
> > [...]
> > | checking dependency style of xlC... none
> >
> > which is kind of weird. IIRC the XL compilers have working dependency
> > extraction mechanisms, which are detected by the Automake code. There
> > has been one bug fix in Automake's depcomp script, but it was limited to
> > the --disable-static case. It would be worthwhile to investigate this.
> to create dependency output use the option -M or -qmakedep. Here the
> relevant relevant part of the man page:
>
> -M Creates an output file that contains information to be
> included in a "make" description file. This is
> equivalent to specifying -qmakedep without a suboption.
>
> -qmakedep[=gcc]
> Creates an output file that contains targets suitable
> for inclusion in a description file for the make command
> that describes the dependencies of the main source file
> in the compilation.
> Specifying 'gcc' changes the format of the generated
> dependency file.
> Specifying -qmakedep without 'gcc' is equivalent to
> specifying -M.
Thanks. I will address this issue in a separate message, later.
Let's finish the Libtool bits first.
> >>> # XL, BG
> >>> cd build-bgxl
> >>> ../configure CC=bgxlc CXX=bgxlC F77=bgfort FC=bgxlf95 GCJ=no \
> >>>LDFLAGS=-qnostaticlink
> >>> make
> >>> make -k check VERBOSE=yes 2>&1 | tee checklog-bgxl-1
> >>> cd ..
> >
> > This is where things start to get interesting.
>
> With the bg* compilers we build programs that are supposed to be run on
> the compute nodes. They may also run on the login-nodes, but you can't
> take that for granted (AFAIR the error "Illegal instruction" appears if
> you try to run a compute node program on a login node).
Ah! I completely misunderstood that. That means that all those builds
should run with cross-compiling enabled. Cross compilation mode is
enabled when --host is passed (and differs from either the passed
--build flag, or whatever configure computes as the build name);
you can also force cross compilation mode through the hack of passing
cross_compiling=yes
to configure. The --host argument will also cause configure to look for
all tool chain programs with a $host- prefix, in this case, with
--host=powerpc-bgp-linux that would be powerpc-bgp-linux-gcc etc.
> As all tests run
> on the login-nodes, we should expect failures. Also, a test that
> succeeds on the login node may not succeed on the compute node. IMHO all
> test programs build with bg* and mpi* compilers should be run on the
> compute nodes, not on the login nodes.
Well, in this case they should not be run at all, at least not those
that are run as part of the configure script.
> To run a program on the compute nodes you write a batch script and
> submit it to a queue. This process unfortunately differs from machine to
> machine. It is also not sensible to submit many small jobs to the queue
> as one job allocates at least 128 nodes.
:-)
> Maybe there is a way of calling
> all tests from a single batch script so that one has to submit only one job.
Not really. For those that failed on the login nodes, you can try to
submit one or two to the queue; if they then pass, I'd be pretty
confident that the others will work, too.
> > Test failures:
> >
> > - f77demo-* in the old testsuite
> > This is because the bgfort command does not exist.
> > It was a typo, should have been F77=bgfort77 or F77=bgf77 or F77=bgxlf
> > I guess. If you have energy left, here's how you can rerun those
> > tests:
> >
> >cd build-bgxl
> >../configure CC=bgxlc CXX=bgxlC F77=bgfort77 FC=bgxlf95 GCJ=no \
> > LDFLAGS=-qnostaticlink
> >gmake
> >gmake -k check VERBOSE=yes TESTSUITEFLAGS='-k F77' TESTS="\
> > tests/f77demo-static.test \
> > tests/f77demo-make.test \
> > tests/f77demo-exec.test \
> > tests/f77demo-conf.test \
> > tests/f77demo-make.test \
> > tests/f77demo-exec.test \
> > tests/f77demo-shared.test \
> > tests/f77demo-make.test \
> > tests/f77demo-exec.test"
>
> Please find the results attached (checklog-bgxl-2).
Thanks. f77demo-exec.test fails after f77demo-static.test, and
f77demo-make.test fails after f77demo-{conf,shared}.test. The first
failure is an "Illegal instruction" again, for which we have an
explanation now; the other two are again:
/bgsys/drivers/ppcfloor/gnu-linux/powerpc-bgp-linux/bin/ld: attempted static
link of dynamic object `./.libs/libfoo.so'
I still don't know the cause for this; but at least the F77 cases look
just like the FC cases.
Can you post the output of the following?
cd
compiler version checks (was: Fortran libraries on the Blue Gene with mpi)
* Christian Rössel wrote on Mon, Apr 27, 2009 at 05:33:33PM CEST:
> While looking at config.log I recognized that the XL compilers man page
> appears several times in config.log. This is caused by the following
> commands:
>
> configure:2925: checking for C compiler version
> configure:2933: bgcc --version >&5
> configure:2944: bgcc -v >&5
> configure:2955: bgcc -V >&5
>
> If you pass an unknown option, you get the entire man page. The correct
> version option for XL compilers is -qversion:
>
> -qversion[=verbose]
> Displays the official compiler product name and the
> compiler version found on the system.
>
> verbose
> Additionally displays information about the
> version, release, and level of each compiler
> component installed.
>
Thanks. This finally gave me enough incentive to do something about
this long-standing issue.
OK to push this Autoconf patch and add Christian and John to THANKS?
Cheers,
Ralf
Limit stderr logging for C compiler version.
* lib/autoconf/general.m4 (_AC_RUN_LOG_LIMIT, _AC_DO_LIMIT): New
internal macros, equivalent to _AC_RUN_LOG and _AC_DO, but with
an optional additional argument to limit the number of lines of
stderr output logged, defaulting to 10.
* lib/autoconf/c.m4 (AC_PROG_CC, AC_PROG_CXX, AC_PROG_OBJC): Use
_AC_DO_LIMIT for capturing compiler version output. Also test
-qversion, for the IBM xlc compiler.
* lib/autoconf/fortran.m4 (_AC_PROG_FC): Likewise.
* THANKS: Update.
Report by Christian Rössel and John R. Cary against Libtool.
diff --git a/lib/autoconf/c.m4 b/lib/autoconf/c.m4
index 3fa9c04..acdda4a 100644
--- a/lib/autoconf/c.m4
+++ b/lib/autoconf/c.m4
@@ -471,9 +471,11 @@ test -z "$CC" && AC_MSG_FAILURE([no acceptable C compiler
found in \$PATH])
_AS_ECHO_LOG([checking for _AC_LANG compiler version])
set X $ac_compile
ac_compiler=$[2]
-_AC_DO([$ac_compiler --version >&AS_MESSAGE_LOG_FD])
-_AC_DO([$ac_compiler -v >&AS_MESSAGE_LOG_FD])
-_AC_DO([$ac_compiler -V >&AS_MESSAGE_LOG_FD])
+# Limit stderr logging to avoid copying full manpages.
+_AC_DO_LIMIT([$ac_compiler --version >&AS_MESSAGE_LOG_FD])
+_AC_DO_LIMIT([$ac_compiler -v >&AS_MESSAGE_LOG_FD])
+_AC_DO_LIMIT([$ac_compiler -V >&AS_MESSAGE_LOG_FD])
+_AC_DO_LIMIT([$ac_compiler -qversion >&AS_MESSAGE_LOG_FD])
m4_expand_once([_AC_COMPILER_EXEEXT])[]dnl
m4_expand_once([_AC_COMPILER_OBJEXT])[]dnl
@@ -706,9 +708,10 @@ fi
_AS_ECHO_LOG([checking for _AC_LANG compiler version])
set X $ac_compile
ac_compiler=$[2]
-_AC_DO([$ac_compiler --version >&AS_MESSAGE_LOG_FD])
-_AC_DO([$ac_compiler -v >&AS_MESSAGE_LOG_FD])
-_AC_DO([$ac_compiler -V >&AS_MESSAGE_LOG_FD])
+_AC_DO_LIMIT([$ac_compiler --version >&AS_MESSAGE_LOG_FD])
+_AC_DO_LIMIT([$ac_compiler -v >&AS_MESSAGE_LOG_FD])
+_AC_DO_LIMIT([$ac_compiler -V >&AS_MESSAGE_LOG_FD])
+_AC_DO_LIMIT([$ac_compiler -qversion >&AS_MESSAGE_LOG_FD])
m4_expand_once([_AC_COMPILER_EXEEXT])[]dnl
m4_expand_once([_AC_COMPILER_OBJEXT])[]dnl
@@ -876,9 +879,10 @@ AC_CHECK_TOOLS(OBJC,
_AS_ECHO_LOG([checking for _AC_LANG compiler version])
set X $ac_compile
ac_compiler=$[2]
-_AC_DO([$ac_compiler --version >&AS_MESSAGE_LOG_FD])
-_AC_DO([$ac_compiler -v >&AS_MESSAGE_LOG_FD])
-_AC_DO([$ac_compiler -V >&AS_MESSAGE_LOG_FD])
+_AC_DO_LIMIT([$ac_compiler --version >&AS_MESSAGE_LOG_FD])
+_AC_DO_LIMIT([$ac_compiler -v >&AS_MESSAGE_LOG_FD])
+_AC_DO_LIMIT([$ac_compiler -V >&AS_MESSAGE_LOG_FD])
+_AC_DO_LIMIT([$ac_compiler -qversion >&AS_MESSAGE_LOG_FD])
m4_expand_once([_AC_COMPILER_EXEEXT])[]dnl
m4_expand_once([_AC_COMPILER_OBJEXT])[]dnl
diff --git a/lib/autoconf/fortran.m4 b/lib/autoconf/fortran.m4
index f144c0e..7da74d1 100644
--- a/lib/autoconf/fortran.m4
+++ b/lib/autoconf/fortran.m4
@@ -354,9 +354,10 @@ AC_CHECK_TOOLS([]_AC_FC[],
_AS_ECHO_LOG([checking for _AC_LANG compiler version])
set X $ac_compile
ac_compiler=$[2]
-_AC_DO([$ac_compiler --version >&AS_MESSAGE_LOG_FD])
-_AC_DO([$ac_compiler -v >&AS_MESSAGE_LOG_FD])
-_AC_DO([$ac_compiler -V >&AS_MESSAGE_LOG_FD])
+_AC_DO_LIMIT([$ac_compiler --version >&AS_MESSAGE_LOG_FD])
+_AC_DO_LIMIT([$ac_compiler -v >&AS_MESSAGE_LOG_FD])
+_AC_DO_LIMIT([$ac_compiler -V >&AS_MESSAGE_LOG_FD])
+_AC_DO_LIMIT([$ac_compiler -qversion >&AS_MESSAGE_LOG_FD])
rm -f a.out
m4_expand_once([_AC_COMPILER_EXEEXT])[]dnl
diff --git a/lib/autoconf/general.m4 b/lib/autoconf/general.m4
index 83254ed..9eaae80 100644
--- a/lib/autoconf/general.m4
+++ b/lib/autoconf/general.m4
@@ -2311,6 +2311,26 @@ AC_DEFUN([_AC_RUN_LOG_STDERR],
_AS_ECHO_LOG([\$? = $ac_status])
test $ac_status = 0; }])
+
+# _AC_RUN_LOG_LIMIT(COMMAND, LOG-COMMANDS, [LINES])
+# -
+# Like _AC_RUN_LOG, but only log LINES lines from stderr,
+# defaulting to 10 lines.
+AC_DEFUN([_AC_RUN_LOG_LIMIT],
+[{ { $2; } >&AS_MESSAGE_LOG_FD
+ ($1) 2>conftest.err
+ ac_status=$?
+ if test
Re: [patch #6691] FreeMiNT support to libtool 1.5.26 (tested)
On Wed, 2009-04-22 at 20:13 +0100, Alan Hourihane wrote: > On Wed, 2009-04-22 at 20:34 +0200, Ralf Wildenhues wrote: > > Hello Alan, > > > > thanks for the feedback. I've added the libtool-patches mailing list > > in Cc:, hope you don't mind (the savannah tracker entries get mailed > > there anyway). > > > > * Alan Hourihane wrote on Wed, Apr 22, 2009 at 06:09:33PM CEST: > > > These came up as the failures. The tests 16 & 73 seems to be exposing a > > > linker bug that I'm looking at now. I'm sure the others are due to the > > > fact that FreeMiNT doesn't have shared libraries or dlopen support. So I > > > guess I need to tweak some other configuration files someplace. > > > > Can you send the tests/testsuite.log file also? Thanks! > > Sure, attached. > > > > If you know where to poke that, let me know and I can re-test. > > > > The log file would help immensely in being able to tell that. > > > > The "Run tests with low max_cmd_len" test (73) is typically a followup > > failure of other test failures (it internally reruns some tests). > > Yeah, it seems to be doing test 16 again which is causing the linker > bug. > > > > 16: duplicate_conv.at:25 duplicate convenience archive names > > > libtool > > > 41: old-m4-iface.at:107 AC_WITH_LTDL > > > libtoolize automake autoconf > > > 44: lt_dlexit.at:30lt_dlexit unloading libs > > > libltdl > > > 45: lt_dladvise.at:28 lt_dlopenadvise library loading > > > libltdl > > > 51: standalone.at:79 linking libltdl without autotools > > > libtoolize > > > 55: subproject.at:109 linking libltdl without autotools > > > libtoolize > > > 69: configure-iface.at:159 --with-ltdl-include/lib > > > libltdl libtoolize automake autoconf > > > 70: configure-iface.at:225 --with-included-ltdl > > > libltdl libtoolize automake autoconf > > > 73: cmdline_wrap.at:28 Run tests with low max_cmd_len > > > recursive > > Let me know what else I can do. Ralf, Can you advise on the 41 - 70 failures which I believe need a tweak to the dl configuration which FreeMiNT doesn't have. Thanks, Alan.
