GNU bug report logs - #12184
GNU Automake 1.12.2 - 4 tests FAIL on Solaris 10 Sparc

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 12184 in the body.
You can then email your comments to 12184 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Dennis Clarke <dclarke <at> blastwave.org>
To: bug-automake <at> gnu.org
Subject: GNU Automake 1.12.2 - 4 tests FAIL on Solaris 10 Sparc
Date: Sun, 12 Aug 2012 05:33:09 +0000 (GMT)

[Message part 1 (text/plain, inline)]

============================================================================
Testsuite summary for GNU Automake 1.12.2
============================================================================
# TOTAL: 2578
# PASS:  2257
# SKIP:  271
# XFAIL: 46
# FAIL:  4
# XPASS: 0
# ERROR: 0
============================================================================
See ./test-suite.log
Please report to bug-automake <at> gnu.org
============================================================================

See testsuite log, large, compressed, attached. 

[test-suite.log_Sun_aug_12_0526_GMT_2012_Solaris_10_Sparc.bz2 (application/x-bzip, attachment)]

Message #8 received at 12184 <at> debbugs.gnu.org (full text, mbox):

From: Stefano Lattarini <stefano.lattarini <at> gmail.com>
To: Dennis Clarke <dclarke <at> blastwave.org>
Cc: 12184 <at> debbugs.gnu.org
Subject: Re: bug#12184: GNU Automake 1.12.2 - 4 tests FAIL on Solaris 10 Sparc
Date: Sun, 12 Aug 2012 11:20:37 +0200

tags 12184 + moreinfo
severity 12184 minor
thanks

On 08/12/2012 07:33 AM, Dennis Clarke wrote:
> ============================================================================
> Testsuite summary for GNU Automake 1.12.2
> ============================================================================
> # TOTAL: 2578
> # PASS:  2257
> # SKIP:  271
> # XFAIL: 46
> # FAIL:  4
> # XPASS: 0
> # ERROR: 0
> ============================================================================
> See ./test-suite.log
> Please report to bug-automake <at> gnu.org
> ============================================================================
> 
> See testsuite log, large, compressed, attached. 
>
Thanks.  The failures in 't/self-check-exit' and 't/self-check-explicit-skips'
are just testsuite weaknesses, and they have already been fixed recently, so
no need to worry about them.

The error in 't/silent-many-generic':

  + make
  ld: fatal: file baz2.o: wrong ELF class: ELFCLASS32
  ld: fatal: file processing errors. No output written to baz
  make: Fatal error: Command failed for target `baz'
  ...
  The following command caused the error:
  echo "  CXXLD   " baz;am--cxx  -erroff -m64 -R/usr/local/lib -L/usr/local/lib \
      -mc -xO3 -xs -D_TS_ERRNO  -o baz baz1.o baz2.o baz3.o  baz5.o baz6.o -ll
  *** Error code 1


seems a problem in your compilers' setup rather than in the test itself.  Could
you please investigate whether this is the case?

Thanks,
  Stefano

Message #15 received at 12184 <at> debbugs.gnu.org (full text, mbox):

From: Dennis Clarke <dclarke <at> blastwave.org>
To: Stefano Lattarini <stefano.lattarini <at> gmail.com>
Cc: 12184 <at> debbugs.gnu.org
Subject: Re: bug#12184: GNU Automake 1.12.2 - 4 tests FAIL on Solaris 10 Sparc
Date: Sun, 12 Aug 2012 10:34:10 +0000 (GMT)

----- Original Message -----
From: Stefano Lattarini <stefano.lattarini <at> gmail.com>
Date: Sunday, August 12, 2012 9:20 am
Subject: Re: bug#12184: GNU Automake 1.12.2 - 4 tests FAIL on Solaris 10 Sparc
To: Dennis Clarke <dclarke <at> blastwave.org>
Cc: 12184 <at> debbugs.gnu.org


> tags 12184 + moreinfo
> severity 12184 minor
> thanks
> 
> On 08/12/2012 07:33 AM, Dennis Clarke wrote:
> > ============================================================================
> > Testsuite summary for GNU Automake 1.12.2
> > ============================================================================
> > # TOTAL: 2578
> > # PASS:  2257
> > # SKIP:  271
> > # XFAIL: 46
> > # FAIL:  4
> > # XPASS: 0
> > # ERROR: 0
> > ============================================================================
> > See ./test-suite.log
> > Please report to bug-automake <at> gnu.org
> > ============================================================================
> > 
> > See testsuite log, large, compressed, attached. 
> >
> Thanks.  The failures in 't/self-check-exit' and 't/self-check-explicit-skips'
> are just testsuite weaknesses, and they have already been fixed 
> recently, so
> no need to worry about them.
> 
> The error in 't/silent-many-generic':
> 
>   + make
>   ld: fatal: file baz2.o: wrong ELF class: ELFCLASS32
>   ld: fatal: file processing errors. No output written to baz
>   make: Fatal error: Command failed for target `baz'
>   ...
>   The following command caused the error:
>   echo "  CXXLD   " baz;am--cxx  -erroff -m64 -R/usr/local/lib 
> -L/usr/local/lib \
>       -mc -xO3 -xs -D_TS_ERRNO  -o baz baz1.o baz2.o baz3.o  baz5.o 
> baz6.o -ll
>   *** Error code 1
> 
> 
> seems a problem in your compilers' setup rather than in the test 
> itself.  Could you please investigate whether this is the case?

Certainly, I will go back and have another look more carefully. 

Also, since I am running these tests and they do take forever we may as well deal with "performance tests not explicitly enabled". 

How does one enable such tests ? Something to do with EXPENSIVE_TESTS or similar ? 

Dennis 

Message #18 received at 12184 <at> debbugs.gnu.org (full text, mbox):

From: Stefano Lattarini <stefano.lattarini <at> gmail.com>
To: Dennis Clarke <dclarke <at> blastwave.org>
Cc: 12184 <at> debbugs.gnu.org
Subject: Re: bug#12184: GNU Automake 1.12.2 - 4 tests FAIL on Solaris 10 Sparc
Date: Sun, 12 Aug 2012 13:01:22 +0200

On 08/12/2012 12:34 PM, Dennis Clarke wrote:
> 
> From: Stefano Lattarini
>
>> seems a problem in your compilers' setup rather than in the test 
>> itself.  Could you please investigate whether this is the case?
> 
> Certainly, I will go back and have another look more carefully. 
>
Thanks.

> Also, since I am running these tests and they do take forever we
> may as well deal with "performance tests not explicitly enabled".
> 
> How does one enable such tests ? Something to do with EXPENSIVE_TESTS
> or similar ?
>
Nope: you have to run "make perf".

However, note that those tests are quite crude, woefully incomplete,
and mostly meant for developers only, so there's little point in
running them IMHO.  Sticking with the "normal" testsuite should be
enough.

Thanks,
  Stefano

Message #21 received at 12184 <at> debbugs.gnu.org (full text, mbox):

From: Dennis Clarke <dclarke <at> blastwave.org>
To: Stefano Lattarini <stefano.lattarini <at> gmail.com>
Cc: 12184 <at> debbugs.gnu.org
Subject: Re: bug#12184: GNU Automake 1.12.2 - 4 tests FAIL on Solaris 10 Sparc
Date: Sun, 12 Aug 2012 18:59:36 +0000 (GMT)

[Message part 1 (text/plain, inline)]

> On 08/12/2012 12:34 PM, Dennis Clarke wrote:
> > 
> > From: Stefano Lattarini
> >
> >> seems a problem in your compilers' setup rather than in the test 
> >> itself.  Could you please investigate whether this is the case?
> > 
> > Certainly, I will go back and have another look more carefully. 
> >
> Thanks.

Wow .. things just got a LOT worse here.  After nearly 7 hours : 

============================================================================
Testsuite summary for GNU Automake 1.12.2
============================================================================
# TOTAL: 2730
# PASS:  2445
# SKIP:  217
# XFAIL: 50
# FAIL:  17
# XPASS: 0
# ERROR: 1
============================================================================
See ./test-suite.log
Please report to bug-automake <at> gnu.org
============================================================================
gmake[2]: *** [test-suite.log] Error 1
gmake[2]: Leaving directory `/usr/local/build/automake-1.12.2_sparcv9_001'
gmake[1]: *** [check-TESTS] Error 2
gmake[1]: Leaving directory `/usr/local/build/automake-1.12.2_sparcv9_001'
gmake: *** [check-am] Error 2

real  6:44:37.252
user  4:00:02.873
sys   2:41:32.796


This is just, staggering. 

I am really trying to figure out what could be in the environment that 
is the cause of these multitude of failures. 

My env vars looks like : 

 $ env | sort 
AS=/usr/ccs/bin/as
CC=/opt/SUNWspro/bin/cc
CFLAGS=-erroff -xstrconst -xildoff -m64 -xmemalign=8s -xnolibmil -Xa -xcode=pic32 -xregs=no%appl -xlibmieee -mc -g -xs -ftrap=%none -Qy -xbuiltin=%none -xdebugformat=dwarf -xunroll=1 -xtarget=ultraT2 -xcache=8/16/4:4096/64/16 -D_TS_ERRNO -D_POSIX_PTHREAD_SEMANTICS -D_LARGEFILE64_SOURCE
CONFIG_SHELL=/bin/bash
CPPFLAGS=-I/usr/local/include -I/usr/local/include/readline
CXX=/opt/SUNWspro/bin/CC
CXXFLAGS=-erroff -xildoff -m64 -xmemalign=8s -xcode=pic32 -xregs=no%appl -xlibmieee -mc -g -xs -xunroll=1 -xtarget=ultraT2 -xcache=8/16/4:4096/64/16 -R/usr/local/lib -L/usr/local/lib -D_TS_ERRNO -D_POSIX_PTHREAD_SEMANTICS -D_LARGEFILE64_SOURCE
EDITOR=/usr/xpg4/bin/vi
GREP=/usr/local/bin/ggrep
HOME=/export/home/dclarke
LANG=C
LC_ALL=C
LC_COLLATE=C
LC_CTYPE=C
LC_MESSAGES=C
LC_MONETARY=C
LC_NUMERIC=C
LC_TIME=C
LD=/usr/ccs/bin/ld
LD_LIBRARY_PATH=/usr/local/lib
LD_OPTIONS=-L/usr/local/lib
LD_RUN_PATH=/usr/local/lib/$ISALIST:/usr/local/lib
LOGNAME=dclarke
M4=/usr/local/bin/gm4
MAIL=/usr/mail/dclarke
MANPATH=/usr/share/man:/usr/X11/share/man
PAGER=/usr/xpg4/bin/more
PATH=/usr/local/bin:/usr/xpg6/bin:/usr/xpg4/bin:/usr/ccs/bin:/opt/SUNWspro/bin:/usr/bin:/sbin:/bin:/usr/sbin:/usr/dt/bin:/usr/openwin/bin:/opt/schily/bin
PKG_CONFIG_PATH=/usr/local/lib/pkgconfig
PWD=/usr/local/build/automake-1.12.2_sparcv9_001
SED=/usr/local/bin/gsed
SHELL=/bin/bash
SRC=/usr/local/src
SSH_CLIENT=68.179.116.201 33207 22
SSH_CONNECTION=68.179.116.201 33207 66.225.151.250 22
SSH_TTY=/dev/pts/1
TERM=vt100
TZ=GMT0
USER=dclarke
VISUAL=/usr/xpg4/bin/vi
_=/usr/xpg4/bin/env

Note that CFLAGS are setup for a 64-bit build ( same as usual ) and with no optimization at all. In fact with -g we have debug builds and -xs tells us 
we even get this ( from the C Users Guide for Sun Studio 12 ) : 

B.2.137 -xs

        Allows debugging by dbx without object files.
        This option causes all the debug information to be copied into the
        executable. This has little impact on dbx performance or the 
        run-time performance of the program, but it does take more
        disk space.

great .. harmless. 

In fact there really isn't anything there that would be harmful. 

I have a lot of processor cores here ( 128 of them ) and if I can run 
gmake -j 8 check to speed things up I can get results in an hour. 

Any suggestions at all ? 

Dennis 

[test-suite.log_automake-1.12.2_sparcv9_Sun_Aug_12_1857_UTC_2012.gz (application/x-gzip, attachment)]

Message #24 received at 12184 <at> debbugs.gnu.org (full text, mbox):

From: Stefano Lattarini <stefano.lattarini <at> gmail.com>
To: Dennis Clarke <dclarke <at> blastwave.org>
Cc: 12184 <at> debbugs.gnu.org
Subject: Re: bug#12184: GNU Automake 1.12.2 - 4 tests FAIL on Solaris 10 Sparc
Date: Sun, 12 Aug 2012 21:53:08 +0200

On 08/12/2012 08:59 PM, Dennis Clarke wrote:
> 
> Wow .. things just got a LOT worse here.  After nearly 7 hours : 
> 
> ============================================================================
> Testsuite summary for GNU Automake 1.12.2
> ============================================================================
> # TOTAL: 2730
> # PASS:  2445
> # SKIP:  217
> # XFAIL: 50
> # FAIL:  17
> # XPASS: 0
> # ERROR: 1
> 
> This is just, staggering. 
> 
> I am really trying to figure out what could be in the environment that 
> is the cause of these multitude of failures. 
> 

My guess is that your grep (in /usr/local/bin/ggrep ) is busted.  First clue:

    FAIL: t/confsub
    ===============
    ...
    + /usr/local/bin/ggrep -F -v 'cd $(top_builddir)'
    Binary file subdir/Makefile.in matches

Huh?  How on earth is grep thinking that Automake has generated a binary file?


Another example:

    FAIL: t/parallel-tests-fork-bomb
    ================================
    ...
    + env TESTS=test-suite.test make -e check
    + st=1
    + cat output
    make  check-TESTS
    make: Warning: Infinite loop: Target `test-suite.log' depends on itself
    Current working directory /usr/local/build/automake-1.12.2_sparcv9_001/t/parallel-tests-fork-bomb.dir
     mkdir rec-0.d
    make: Warning: Infinite loop: Target `test-suite.log' depends on itself
    Current working directory /usr/local/build/automake-1.12.2_sparcv9_001/t/parallel-tests-fork-bomb.dir
     mkdir rec-0.d
    mkdir: Failed to make directory "rec-0.d"; File exists
     mkdir rec-1.d
    fatal: making test-suite.log: possible infinite recursion detected
    fatal: making test-suite.log: failed to create test-suite.trs
    fatal: making test-suite.log: failed to create test-suite.log
    *** Error code 1
    ...

and so far so good, because the setup in that test is explicitly meant
to elicit such error messages from make; but then we have:

    ...
    + /usr/local/bin/ggrep -E -i 'depend.* on itself' output \
       | /usr/local/bin/ggrep -F test-suite.log
    + continue
    + test no = yes
    + _am_exit 1

which is just wrong, because we've seen that the file 'output' contains
the string "Infinite loop: Target `test-suite.log' depends on itself",
which should be matched by the grep commands above.


Later, once again, ggrep mistakes a simple text file for a binary one:

    FAIL: t/tap-ambiguous-directive
    ===============================
    ...
    + cat
    + /usr/local/bin/ggrep -F ': all.test' stdout
    + cat exp
    PASS: all.test 1 # foo SKIP
    FAIL: all.test 2 # bar TODO
    PASS: all.test 3 # :SKIP
    FAIL: all.test 4 # :TODO
    SKIP: all.test 5 # SKIP SKIP
    XFAIL: all.test 6 # TODO TODO
    + cat got
    Binary file stdout matches
    ...

All the other failures seem similar to this last one.


> [SNIP]
>
> In fact there really isn't anything there that would be harmful. 
>
No in the compiler :-)  But GNU grep is busted on your system IMHO.

> I have a lot of processor cores here ( 128 of them ) and if I can run 
> gmake -j 8 check to speed things up I can get results in an hour. 
>
Great!

> Any suggestions at all ?
>
You might try this:

  $ gmake check -j8 FGREP='/usr/xpg4/bin/grep -F' EGREP='/usr/xpg4/bin/grep -E'

and see if/how things improve.

Thanks,
  Stefano

Message #27 received at 12184 <at> debbugs.gnu.org (full text, mbox):

From: Dennis Clarke <dclarke <at> blastwave.org>
To: Stefano Lattarini <stefano.lattarini <at> gmail.com>
Cc: 12184 <at> debbugs.gnu.org
Subject: Re: bug#12184: GNU Automake 1.12.2 - 4 tests FAIL on Solaris 10 Sparc
Date: Sun, 12 Aug 2012 20:08:11 +0000 (GMT)

> On 08/12/2012 08:59 PM, Dennis Clarke wrote:
> > 
> > Wow .. things just got a LOT worse here.  After nearly 7 hours : 
> > 
> > ============================================================================
> > Testsuite summary for GNU Automake 1.12.2
> > ============================================================================
> > # TOTAL: 2730
> > # PASS:  2445
> > # SKIP:  217
> > # XFAIL: 50
> > # FAIL:  17
> > # XPASS: 0
> > # ERROR: 1
> > 
> > This is just, staggering. 
> > 
> > I am really trying to figure out what could be in the environment 
> that 
> > is the cause of these multitude of failures. 
> > 
> 
> My guess is that your grep (in /usr/local/bin/ggrep ) is busted.  
> First clue:
> 
>     FAIL: t/confsub
>     ===============
>     ...
>     + /usr/local/bin/ggrep -F -v 'cd $(top_builddir)'
>     Binary file subdir/Makefile.in matches
> 
> Huh?  How on earth is grep thinking that Automake has generated a 
> binary file?

yeah, that is just plain wrong. What really annoys me is that grep-2.13 built fine and passed all of its testsuite. 

I am at a point where I may have to rm -rf /usr/local and start over from square zero with clean builds and clean tools. 

Really I am only doing this because I need Apache APR and HTTP to be up to date, latest and greatest and 64-bit all the way. 

There are a pile of dependencies. 

I am sure you know what I mean. 

> 
> 
> Another example:
> 
>     FAIL: t/parallel-tests-fork-bomb
>     ================================
>     ...
>     + env TESTS=test-suite.test make -e check
>     + st=1
>     + cat output
>     make  check-TESTS
>     make: Warning: Infinite loop: Target `test-suite.log' depends on itself
>     Current working directory /usr/local/build/automake-1.12.2_sparcv9_001/t/parallel-tests-fork-bomb.dir
>      mkdir rec-0.d
>     make: Warning: Infinite loop: Target `test-suite.log' depends on itself
>     Current working directory /usr/local/build/automake-1.12.2_sparcv9_001/t/parallel-tests-fork-bomb.dir
>      mkdir rec-0.d
>     mkdir: Failed to make directory "rec-0.d"; File exists
>      mkdir rec-1.d
>     fatal: making test-suite.log: possible infinite recursion detected
>     fatal: making test-suite.log: failed to create test-suite.trs
>     fatal: making test-suite.log: failed to create test-suite.log
>     *** Error code 1
>     ...
> 
> and so far so good, because the setup in that test is explicitly meant
> to elicit such error messages from make; but then we have:
> 
>     ...
>     + /usr/local/bin/ggrep -E -i 'depend.* on itself' output \
>        | /usr/local/bin/ggrep -F test-suite.log
>     + continue
>     + test no = yes
>     + _am_exit 1
> 
> which is just wrong, because we've seen that the file 'output' contains
> the string "Infinite loop: Target `test-suite.log' depends on itself",
> which should be matched by the grep commands above.
> 
> 
> Later, once again, ggrep mistakes a simple text file for a binary one:
> 
>     FAIL: t/tap-ambiguous-directive
>     ===============================
>     ...
>     + cat
>     + /usr/local/bin/ggrep -F ': all.test' stdout
>     + cat exp
>     PASS: all.test 1 # foo SKIP
>     FAIL: all.test 2 # bar TODO
>     PASS: all.test 3 # :SKIP
>     FAIL: all.test 4 # :TODO
>     SKIP: all.test 5 # SKIP SKIP
>     XFAIL: all.test 6 # TODO TODO
>     + cat got
>     Binary file stdout matches
>     ...
> 
> All the other failures seem similar to this last one.
> 
> 
> > [SNIP]
> >
> > In fact there really isn't anything there that would be harmful. 
> >
> No in the compiler :-)  But GNU grep is busted on your system IMHO.

  lovely :-(

I think I should be able to kill it and simply remove the bits that 
it affects.  Thankfully I keep an audit log of every file that gets
"installed" ( read copied into place ) in /usr/local thus : 

$  cat fidlist | grep -v "drwx" | awk '{ print $3 " " $8 " " $9 " " $10 " " $11 }' 
-rw-r--r-- Aug 12 09:01 ./lib/charset.alias
-rwxr-xr-x Aug 12 09:02 ./bin/gegrep
-rwxr-xr-x Aug 12 09:02 ./bin/ggrep
-rwxr-xr-x Aug 12 09:02 ./bin/gfgrep
-rw-r--r-- Aug 12 09:02 ./share/man/man1/gfgrep.1
-rw-r--r-- Aug 12 09:02 ./share/man/man1/gegrep.1
-rw-r--r-- Aug 12 09:02 ./share/man/man1/ggrep.1
-rw-r--r-- Aug 12 09:01 ./share/locale/ro/LC_MESSAGES/grep.mo
-rw-r--r-- Aug 12 09:01 ./share/locale/it/LC_MESSAGES/grep.mo
-rw-r--r-- Aug 12 09:01 ./share/locale/ca/LC_MESSAGES/grep.mo
-rw-r--r-- Aug 12 09:01 ./share/locale/sr/LC_MESSAGES/grep.mo
-rw-r--r-- Aug 12 09:01 ./share/locale/zh_TW/LC_MESSAGES/grep.mo
-rw-r--r-- Aug 12 09:01 ./share/locale/sl/LC_MESSAGES/grep.mo
-rw-r--r-- Aug 12 09:01 ./share/locale/eo/LC_MESSAGES/grep.mo
-rw-r--r-- Aug 12 09:01 ./share/locale/be/LC_MESSAGES/grep.mo
-rw-r--r-- Aug 12 09:01 ./share/locale/sk/LC_MESSAGES/grep.mo
-rw-r--r-- Aug 12 09:01 ./share/locale/tr/LC_MESSAGES/grep.mo
-rw-r--r-- Aug 12 09:01 ./share/locale/zh_CN/LC_MESSAGES/grep.mo
-rw-r--r-- Aug 12 09:01 ./share/locale/da/LC_MESSAGES/grep.mo
-rw-r--r-- Aug 12 09:01 ./share/locale/uk/LC_MESSAGES/grep.mo
-rw-r--r-- Aug 12 09:01 ./share/locale/vi/LC_MESSAGES/grep.mo
-rw-r--r-- Aug 12 09:01 ./share/locale/de/LC_MESSAGES/grep.mo
-rw-r--r-- Aug 12 09:01 ./share/locale/ja/LC_MESSAGES/grep.mo
-rw-r--r-- Aug 12 09:01 ./share/locale/th/LC_MESSAGES/grep.mo
-rw-r--r-- Aug 12 09:01 ./share/locale/el/LC_MESSAGES/grep.mo
-rw-r--r-- Aug 12 09:01 ./share/locale/pt/LC_MESSAGES/grep.mo
-rw-r--r-- Aug 12 09:01 ./share/locale/ko/LC_MESSAGES/grep.mo
-rw-r--r-- Aug 12 09:01 ./share/locale/eu/LC_MESSAGES/grep.mo
-rw-r--r-- Aug 12 09:01 ./share/locale/fi/LC_MESSAGES/grep.mo
-rw-r--r-- Aug 12 09:01 ./share/locale/sv/LC_MESSAGES/grep.mo
-rw-r--r-- Aug 12 09:01 ./share/locale/ru/LC_MESSAGES/grep.mo
-rw-r--r-- Aug 12 09:01 ./share/locale/id/LC_MESSAGES/grep.mo
-rw-r--r-- Aug 12 09:01 ./share/locale/cs/LC_MESSAGES/grep.mo
-rw-r--r-- Aug 12 09:01 ./share/locale/ky/LC_MESSAGES/grep.mo
-rw-r--r-- Aug 12 09:01 ./share/locale/lt/LC_MESSAGES/grep.mo
-rw-r--r-- Aug 12 09:01 ./share/locale/he/LC_MESSAGES/grep.mo
-rw-r--r-- Aug 12 09:01 ./share/locale/af/LC_MESSAGES/grep.mo
-rw-r--r-- Aug 12 09:01 ./share/locale/fr/LC_MESSAGES/grep.mo
-rw-r--r-- Aug 12 09:01 ./share/locale/pt_BR/LC_MESSAGES/grep.mo
-rw-r--r-- Aug 12 09:01 ./share/locale/nl/LC_MESSAGES/grep.mo
-rw-r--r-- Aug 12 09:01 ./share/locale/nb/LC_MESSAGES/grep.mo
-rw-r--r-- Aug 12 09:01 ./share/locale/ga/LC_MESSAGES/grep.mo
-rw-r--r-- Aug 12 09:01 ./share/locale/bg/LC_MESSAGES/grep.mo
-rw-r--r-- Aug 12 09:01 ./share/locale/pa/LC_MESSAGES/grep.mo
-rw-r--r-- Aug 12 09:01 ./share/locale/et/LC_MESSAGES/grep.mo
-rw-r--r-- Aug 12 09:01 ./share/locale/hr/LC_MESSAGES/grep.mo
-rw-r--r-- Aug 12 09:01 ./share/locale/hu/LC_MESSAGES/grep.mo
-rw-r--r-- Aug 12 09:01 ./share/locale/pl/LC_MESSAGES/grep.mo
-rw-r--r-- Aug 12 09:01 ./share/locale/es/LC_MESSAGES/grep.mo
-rw-r--r-- Aug 12 09:01 ./share/locale/gl/LC_MESSAGES/grep.mo
-rw-r--r-- Aug 12 09:02 ./share/info/grep.info


So I will kill off those binaries and edit /usr/local/lib/charset.alias to remove any reference to grep. 

> > I have a lot of processor cores here ( 128 of them ) and if I can 
> run 
> > gmake -j 8 check to speed things up I can get results in an hour. 
> >
> Great!
> 
> > Any suggestions at all ?
> >
> You might try this:
> 
>   $ gmake check -j8 FGREP='/usr/xpg4/bin/grep -F' 
> EGREP='/usr/xpg4/bin/grep -E'
> 
> and see if/how things improve.

I will do ALL of the above right away and let you know, hopefully in an hour or less.

Dennis 

ps: you Sir, are awesome

Message #30 received at 12184 <at> debbugs.gnu.org (full text, mbox):

From: Dennis Clarke <dclarke <at> blastwave.org>
To: Stefano Lattarini <stefano.lattarini <at> gmail.com>
Cc: 12184 <at> debbugs.gnu.org
Subject: Re: bug#12184: GNU Automake 1.12.2 - 4 tests FAIL on Solaris 10 Sparc
Date: Sun, 12 Aug 2012 23:46:34 +0000 (GMT)

[Message part 1 (text/plain, inline)]

A bit of recovery : 

============================================================================
Testsuite summary for GNU Automake 1.12.2
============================================================================
# TOTAL: 2730
# PASS:  2459
# SKIP:  217
# XFAIL: 50
# FAIL:  4
# XPASS: 0
# ERROR: 0
============================================================================
See ./test-suite.log
Please report to bug-automake <at> gnu.org
============================================================================
gmake[2]: *** [test-suite.log] Error 1
gmake[2]: Leaving directory `/usr/local/build/automake-1.12.2_sparcv9_002'
gmake[1]: *** [check-TESTS] Error 2
gmake[1]: Leaving directory `/usr/local/build/automake-1.12.2_sparcv9_002'
gmake: *** [check-am] Error 2

real  1:02:48.586
user  4:11:29.108
sys   2:56:30.837

At least I can get results in one hour now.  :-\

[test-suite_automake-1.12.2_sparcv9_Sun_Aug_12_2344_GMT_2012.log.gz (application/x-gzip, attachment)]

Message #33 received at 12184 <at> debbugs.gnu.org (full text, mbox):

From: Dennis Clarke <dclarke <at> blastwave.org>
To: Stefano Lattarini <stefano.lattarini <at> gmail.com>
Cc: 12184 <at> debbugs.gnu.org
Subject: Re: bug#12184: GNU Automake 1.12.2 - 4 tests FAIL on Solaris 10 Sparc
Date: Sun, 12 Aug 2012 23:59:31 +0000 (GMT)

> My guess is that your grep (in /usr/local/bin/ggrep ) is busted.  
> First clue:

By the way, I did have one test with GNU grep fail and yes, I did file a report. 
The reply was not helpful : 

From  	Jim Meyering <some email address> 
Sent  	Sunday, August 12, 2012 10:39 pm
To  	Dennis Clarke <dclarke <at> blastwave.org> 
Cc  	bug-grep <at> gnu.org 
Subject Re: grep-2.13 FAIL:  1

Dennis Clarke wrote:
> On Solaris 10 update 10 on Sparc with Sun Studio 12 tools.
>
> $ env | sort
> AS=/usr/ccs/bin/as
> CC=/opt/SUNWspro/bin/cc
> CFLAGS=-erroff -xstrconst -xildoff -m64 -xmemalign=8s -xnolibmil -Xc -xcode=pic32 -xregs=no%appl -xlibmieee -mc -g -xs -ftrap=%none -Qy -xbuiltin=%none -xdebugformat=dwarf -xunroll=1 -xtarget=ultraT2 -xcache=8/16/4:4096/64/16 -D_TS_ERRNO -D_POSIX_PTHREAD_SEMANTICS -D_LARGEFILE64_SOURCE
> COLUMNS=124
> CONFIG_SHELL=/bin/bash
> CPPFLAGS=-I/usr/local/include -I/usr/local/include/readline
> CXX=/opt/SUNWspro/bin/CC
> CXXFLAGS=-erroff -xildoff -m64 -xmemalign=8s -xcode=pic32 -xregs=no%appl -xlibmieee -mc -g -xs -xunroll=1 -xtarget=ultraT2 -xcache=8/16/4:4096/64/16 -R/usr/local/lib -L/usr/local/lib -D_TS_ERRNO -D_POSIX_PTHREAD_SEMANTICS -D_LARGEFILE64_SOURCE
...
> sjis-mb: skipped test: your system lacks the timeout program
> SKIP: sjis-mb
> PASS: spencer1
> FAIL: spencer1-locale
> PASS: status
...
> # TOTAL: 57
> # PASS:  44
> # SKIP:  9
> # XFAIL: 3
> # FAIL:  1
> # XPASS: 0
> # ERROR: 0

Thanks for the report.
On the sole Solaris 10 system to which I have access,
all of grep's tests pass when built with gcc-4.5.0
and the Sun Studio 12 tools appear not to be available here.

I suggest you try building with a recent version of gcc.

If you really must use that other compiler, consider
instrumenting the failing test to make it report the
precise grep command that is failing.  If you do, please
report that, along with the actual/expected output.

-------------------------------------------------------------

Essentially, we are Linux, we don't do UNIX, go make UNIX
like Linux. Good luck.

  ick 

dc

Message #36 received at 12184 <at> debbugs.gnu.org (full text, mbox):

From: Stefano Lattarini <stefano.lattarini <at> gmail.com>
To: Dennis Clarke <dclarke <at> blastwave.org>
Cc: 12184 <at> debbugs.gnu.org
Subject: Re: bug#12184: GNU Automake 1.12.2 - 4 tests FAIL on Solaris 10 Sparc
Date: Mon, 13 Aug 2012 10:06:36 +0200

On 08/13/2012 01:59 AM, Dennis Clarke wrote:
> 
>> My guess is that your grep (in /usr/local/bin/ggrep ) is busted.  
>> First clue:
> 
> By the way, I did have one test with GNU grep fail and yes,
> I did file a report.  The reply was not helpful :
> 
> From  	Jim Meyering <some email address> 
> Sent  	Sunday, August 12, 2012 10:39 pm
> To  	Dennis Clarke <dclarke <at> blastwave.org> 
> Cc  	bug-grep <at> gnu.org 
> Subject Re: grep-2.13 FAIL:  1
> 
> Dennis Clarke wrote:
>> On Solaris 10 update 10 on Sparc with Sun Studio 12 tools.
>>
>> $ env | sort
>> AS=/usr/ccs/bin/as
>> CC=/opt/SUNWspro/bin/cc
>> CFLAGS=-erroff -xstrconst -xildoff -m64 -xmemalign=8s -xnolibmil -Xc -xcode=pic32 -xregs=no%appl -xlibmieee -mc -g -xs -ftrap=%none -Qy -xbuiltin=%none -xdebugformat=dwarf -xunroll=1 -xtarget=ultraT2 -xcache=8/16/4:4096/64/16 -D_TS_ERRNO -D_POSIX_PTHREAD_SEMANTICS -D_LARGEFILE64_SOURCE
>> COLUMNS=124
>> CONFIG_SHELL=/bin/bash
>> CPPFLAGS=-I/usr/local/include -I/usr/local/include/readline
>> CXX=/opt/SUNWspro/bin/CC
>> CXXFLAGS=-erroff -xildoff -m64 -xmemalign=8s -xcode=pic32 -xregs=no%appl -xlibmieee -mc -g -xs -xunroll=1 -xtarget=ultraT2 -xcache=8/16/4:4096/64/16 -R/usr/local/lib -L/usr/local/lib -D_TS_ERRNO -D_POSIX_PTHREAD_SEMANTICS -D_LARGEFILE64_SOURCE
> ...
>> sjis-mb: skipped test: your system lacks the timeout program
>> SKIP: sjis-mb
>> PASS: spencer1
>> FAIL: spencer1-locale
>> PASS: status
> ...
>> # TOTAL: 57
>> # PASS:  44
>> # SKIP:  9
>> # XFAIL: 3
>> # FAIL:  1
>> # XPASS: 0
>> # ERROR: 0
> 
> Thanks for the report.
> On the sole Solaris 10 system to which I have access,
> all of grep's tests pass when built with gcc-4.5.0
> and the Sun Studio 12 tools appear not to be available here.
> 
> I suggest you try building with a recent version of gcc.
> 
> If you really must use that other compiler, consider
> instrumenting the failing test to make it report the
> precise grep command that is failing.  If you do, please
> report that, along with the actual/expected output.
>
How is this not helpful?  It suggested a possible way out from
your problem (use GCC), or, failing that, instructions to give
the developers what they need to start investigating the problem.

> -------------------------------------------------------------
> 
> Essentially, we are Linux, we don't do UNIX, go make UNIX
> like Linux.
>
Actually, most the GNU tools (among them grep) strive to be
greatly portable, sometimes even too much IMHO.

The issue is that the developers' time is limited, and if they
don't have a Solaris machine with a Sun compiler to test with,
well, they won't lose their time fighting to get one.  If Oracle
is interested in having their systems supported better, it's on
them to offer easy access to Solaris and the Sun C compiler to
Free Software and Open Source developers; if they don't, their
system will get a "best effort" support at most.  I see this as
right and proper, and sometimes even too generous.  And if a
user of a fringe/uncommon/proprietary systems is interested in
making things work for himself, it's on him to provide the
developers with enough help or feedback to make that possible;
this too seems appropriate to me.

Regards,
  Stefano

Message #39 received at 12184 <at> debbugs.gnu.org (full text, mbox):

From: Stefano Lattarini <stefano.lattarini <at> gmail.com>
To: Dennis Clarke <dclarke <at> blastwave.org>
Cc: 12184 <at> debbugs.gnu.org
Subject: Re: bug#12184: GNU Automake 1.12.2 - 4 tests FAIL on Solaris 10 Sparc
Date: Mon, 13 Aug 2012 10:21:02 +0200

On 08/13/2012 01:46 AM, Dennis Clarke wrote:
> 
> At least I can get results in one hour now.  :-\
> 
> [SNIP]
>
Same as before: the only actual failure is:

    FAIL: t/silent-many-generic
    ===========================

   ...
   + make
   ld: fatal: file baz2.o: wrong ELF class: ELFCLASS32
   ld: fatal: file processing errors. No output written to baz
   make: Fatal error: Command failed for target `baz'

which seems to suggest your C++ linker has issues linking together
objects generated by your C++ compilers with objects generated by
your Fortran 90 compiler.  Could you try whether/how the same issue
is present outside the Automake testsuite?

Thanks,
  Stefano

Message #42 received at 12184 <at> debbugs.gnu.org (full text, mbox):

From: Dennis Clarke <dclarke <at> blastwave.org>
To: Stefano Lattarini <stefano.lattarini <at> gmail.com>
Cc: 12184 <at> debbugs.gnu.org
Subject: Re: bug#12184: GNU Automake 1.12.2 - 4 tests FAIL on Solaris 10 Sparc
Date: Mon, 13 Aug 2012 18:10:09 +0000 (GMT)

> > I suggest you try building with a recent version of gcc.
> > 
> > If you really must use that other compiler, consider
> > instrumenting the failing test to make it report the
> > precise grep command that is failing.  If you do, please
> > report that, along with the actual/expected output.
> >
> How is this not helpful?  It suggested a possible way out from
> your problem (use GCC), or, failing that, instructions to give
> the developers what they need to start investigating the problem.
>

Part of the reason I am doing all this is to build a recent GCC. 
Something I do, a lot. I can not abide by the dependance on the 
very expensive Sun/Oracle developer tools. For the sake of reasonable
portability across many platforms I would rather work with GCc. 

see : http://gcc.gnu.org/gcc-4.7/buildstat.html

I have excellent results for GCC 4.7.1 on i386-pc-solaris2.8 which
is very very old. However it has the benefit that anything which
runs flawlessly on Solaris 8 will run everywhere else in the 
Solaris world.  Sparc is another issue and I am working on that. 
 
> > -------------------------------------------------------------
> > 
> > Essentially, we are Linux, we don't do UNIX, go make UNIX
> > like Linux.
> >
> Actually, most the GNU tools (among them grep) strive to be
> greatly portable, sometimes even too much IMHO.
> 
> The issue is that the developers' time is limited, and if they
> don't have a Solaris machine with a Sun compiler to test with,
> well, they won't lose their time fighting to get one.  If Oracle
> is interested in having their systems supported better, it's on
> them to offer easy access to Solaris and the Sun C compiler to
> Free Software and Open Source developers; if they don't, their
> system will get a "best effort" support at most.  I see this as
> right and proper, and sometimes even too generous.  And if a
> user of a fringe/uncommon/proprietary systems is interested in
> making things work for himself, it's on him to provide the
> developers with enough help or feedback to make that possible;
> this too seems appropriate to me.

Hey man, get off my soap box! I was here first.  :-)

I was in the OpenSolaris project from day zero long before it 
went public and I can tell you it was a farce and a sham how
ORacle handled that disaster. Also, they ( read Larry ) does 
not give a damn about open source or open anything. The idea
is a joke to him and all his executives. So forget them. 

However, some of us are still stuck dealing with the old Solaris
architecture until it finally vanishes from every server room
in the world, much like DEC Alpha, SGI or half a dozen great 
names we both know. 

Now then, I still need to get a stable toolchain built in order
to bootstrap GCC and then many other things to follow. 

Dennis 

Message #45 received at 12184 <at> debbugs.gnu.org (full text, mbox):

From: Dennis Clarke <dclarke <at> blastwave.org>
To: Stefano Lattarini <stefano.lattarini <at> gmail.com>
Cc: 12184 <at> debbugs.gnu.org
Subject: Re: bug#12184: GNU Automake 1.12.2 - 4 tests FAIL on Solaris 10 Sparc
Date: Mon, 13 Aug 2012 18:47:06 +0000 (GMT)

----- Original Message -----
From: Stefano Lattarini <stefano.lattarini <at> gmail.com>
Date: Monday, August 13, 2012 8:21 am
Subject: Re: bug#12184: GNU Automake 1.12.2 - 4 tests FAIL on Solaris 10 Sparc
To: Dennis Clarke <dclarke <at> blastwave.org>
Cc: 12184 <at> debbugs.gnu.org


> On 08/13/2012 01:46 AM, Dennis Clarke wrote:
> > 
> > At least I can get results in one hour now.  :-\
> > 
> > [SNIP]
> >
> Same as before: the only actual failure is:
> 
>     FAIL: t/silent-many-generic
>     ===========================
> 
>    ...
>    + make
>    ld: fatal: file baz2.o: wrong ELF class: ELFCLASS32
>    ld: fatal: file processing errors. No output written to baz
>    make: Fatal error: Command failed for target `baz'
> 
> which seems to suggest your C++ linker has issues linking together
> objects generated by your C++ compilers with objects generated by
> your Fortran 90 compiler.  Could you try whether/how the same issue
> is present outside the Automake testsuite?
> 

before I climb into that, I notice on configure output this :

checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables... 
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C compiler... no
checking whether /opt/SUNWspro/bin/cc accepts -g... yes
checking for /opt/SUNWspro/bin/cc option to accept ISO C89... none needed
checking whether the C++ compiler works... yes
checking for C++ compiler default output file name... a.out
checking for suffix of executables... 
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C++ compiler... no
checking whether /opt/SUNWspro/bin/CC accepts -g... yes
checking for xlf95... no
checking for f95... f95
checking whether the Fortran compiler works... yes
checking for Fortran compiler default output file name... a.out
checking for suffix of executables... 
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU Fortran compiler... no
checking whether f95 accepts -g... yes
checking for xlf... no
checking for f77... f77
checking whether the Fortran 77 compiler works... yes
checking for Fortran 77 compiler default output file name... a.out
checking for suffix of executables... 
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU Fortran 77 compiler... no
checking whether f77 accepts -g... yes
configure: will now look for GNU compilers
checking for gcc... no
configure: WARNING: botched installation for GNU C compiler
configure: tests requiring the GNU C compiler will be skipped
checking for g++... no
checking for gpp... no
configure: WARNING: botched installation for GNU C++ compiler
configure: tests requiring the GNU C++ compiler will be skipped
checking for gfortran... no
configure: WARNING: botched installation for GNU Fortran compiler
configure: tests requiring the GNU Fortran compiler will be skipped
checking for g77... no
checking for gfortran... no
configure: WARNING: botched installation for GNU Fortran 77 compiler
configure: tests requiring the GNU Fortran 77 compiler will be skipped
checking for gcj... no
configure: WARNING: botched installation for GNU Java compiler
configure: tests requiring the GNU Java compiler will be skipped
checking that generated files are newer than configure... done
configure: creating ./config.status


Is there some reason why GNU Fortran is a "need" ? 

Also, Java compiler, I think Solaris includes a really top notch
Java compiler in /usr/jdk/latest . 


dc

Message #48 received at 12184 <at> debbugs.gnu.org (full text, mbox):

From: Dennis Clarke <dclarke <at> blastwave.org>
To: Stefano Lattarini <stefano.lattarini <at> gmail.com>
Cc: 12184 <at> debbugs.gnu.org
Subject: Re: bug#12184: GNU Automake 1.12.2 - 4 tests FAIL on Solaris 10 Sparc
Date: Tue, 14 Aug 2012 00:20:35 +0000 (GMT)

cc: 12184 <at> debbugs.gnu.org

> On 08/13/2012 01:46 AM, Dennis Clarke wrote:
> > 
> > At least I can get results in one hour now.  :-\
> > 
> > [SNIP]
> >
> Same as before: the only actual failure is:
> 
>     FAIL: t/silent-many-generic
>     ===========================
> 
>    ...
>    + make
>    ld: fatal: file baz2.o: wrong ELF class: ELFCLASS32
>    ld: fatal: file processing errors. No output written to baz
>    make: Fatal error: Command failed for target `baz'
> 
> which seems to suggest your C++ linker has issues linking together
> objects generated by your C++ compilers with objects generated by
> your Fortran 90 compiler.  Could you try whether/how the same issue
> is present outside the Automake testsuite?

Am trying .. in the meantime I think the best I will see is : 

============================================================================
Testsuite summary for GNU Automake 1.12.2
============================================================================
# TOTAL: 2730
# PASS:  2459
# SKIP:  217
# XFAIL: 50
# FAIL:  4
# XPASS: 0
# ERROR: 0
============================================================================

So I am giving up on automake for now. However there is a bug or flaw in there somewhere however I don't know where. I was able to build plenty of other packages and even get the latest Apache and apr/apu built and running fine. 

So my thoughts are that I can do little until I have a decent bootstrap of GCC 4.7.1 and that won't happen quickly.  Getting away from Sun/Oracle Studio tools is the best advice here. Just avoid them. 

I am stuck with what I get in automake for at least a few days until I can come back to this. 

Dennis 

Message #51 received at 12184 <at> debbugs.gnu.org (full text, mbox):

From: Stefano Lattarini <stefano.lattarini <at> gmail.com>
To: Dennis Clarke <dclarke <at> blastwave.org>
Cc: 12184 <at> debbugs.gnu.org
Subject: Re: bug#12184: GNU Automake 1.12.2 - 4 tests FAIL on Solaris 10 Sparc
Date: Tue, 14 Aug 2012 10:19:04 +0200

On 08/13/2012 08:10 PM, Dennis Clarke wrote:
> 
> 
>>> I suggest you try building with a recent version of gcc.
>>>
>>> If you really must use that other compiler, consider
>>> instrumenting the failing test to make it report the
>>> precise grep command that is failing.  If you do, please
>>> report that, along with the actual/expected output.
>>>
>> How is this not helpful?  It suggested a possible way out from
>> your problem (use GCC), or, failing that, instructions to give
>> the developers what they need to start investigating the problem.
>>
> 
> Part of the reason I am doing all this is to build a recent GCC. 
>
Now, this is a good explanation.  However, note that Autoconf-generated
configure scripts and Automake-generated Makefiles should be portable
enough to work with a decent grep implementation like the one offered
in /usr/xpg4/bin/grep on Solaris.

> Something I do, a lot. I can not abide by the dependance on the 
> very expensive Sun/Oracle developer tools. For the sake of reasonable
> portability across many platforms I would rather work with GCc. 
> 
> see : http://gcc.gnu.org/gcc-4.7/buildstat.html
> 
> I have excellent results for GCC 4.7.1 on i386-pc-solaris2.8 which
> is very very old. However it has the benefit that anything which
> runs flawlessly on Solaris 8 will run everywhere else in the 
> Solaris world.  Sparc is another issue and I am working on that. 
>  
>>> -------------------------------------------------------------
>>>
>>> Essentially, we are Linux, we don't do UNIX, go make UNIX
>>> like Linux.
>>>
>> Actually, most the GNU tools (among them grep) strive to be
>> greatly portable, sometimes even too much IMHO.
>>
>> The issue is that the developers' time is limited, and if they
>> don't have a Solaris machine with a Sun compiler to test with,
>> well, they won't lose their time fighting to get one.  If Oracle
>> is interested in having their systems supported better, it's on
>> them to offer easy access to Solaris and the Sun C compiler to
>> Free Software and Open Source developers; if they don't, their
>> system will get a "best effort" support at most.  I see this as
>> right and proper, and sometimes even too generous.  And if a
>> user of a fringe/uncommon/proprietary systems is interested in
>> making things work for himself, it's on him to provide the
>> developers with enough help or feedback to make that possible;
>> this too seems appropriate to me.
> 
> Hey man, get off my soap box! I was here first.  :-)
>
Yeah, I noticed too late :-)  (after reading the latest messages
in the bug-grep list).

> [SNIP]
>

Regards,
  Stefano

Message #54 received at 12184 <at> debbugs.gnu.org (full text, mbox):

From: Stefano Lattarini <stefano.lattarini <at> gmail.com>
To: Dennis Clarke <dclarke <at> blastwave.org>
Cc: 12184 <at> debbugs.gnu.org
Subject: Re: bug#12184: GNU Automake 1.12.2 - 4 tests FAIL on Solaris 10 Sparc
Date: Tue, 14 Aug 2012 10:23:34 +0200

On 08/13/2012 08:47 PM, Dennis Clarke wrote:
> 
> 
> ----- Original Message -----
> From: Stefano Lattarini <stefano.lattarini <at> gmail.com>
> Date: Monday, August 13, 2012 8:21 am
> Subject: Re: bug#12184: GNU Automake 1.12.2 - 4 tests FAIL on Solaris 10 Sparc
> To: Dennis Clarke <dclarke <at> blastwave.org>
> Cc: 12184 <at> debbugs.gnu.org
> 
> 
>> On 08/13/2012 01:46 AM, Dennis Clarke wrote:
>>>
>>> At least I can get results in one hour now.  :-\
>>>
>>> [SNIP]
>>>
>> Same as before: the only actual failure is:
>>
>>     FAIL: t/silent-many-generic
>>     ===========================
>>
>>    ...
>>    + make
>>    ld: fatal: file baz2.o: wrong ELF class: ELFCLASS32
>>    ld: fatal: file processing errors. No output written to baz
>>    make: Fatal error: Command failed for target `baz'
>>
>> which seems to suggest your C++ linker has issues linking together
>> objects generated by your C++ compilers with objects generated by
>> your Fortran 90 compiler.  Could you try whether/how the same issue
>> is present outside the Automake testsuite?
>>
> 
> before I climb into that, I notice on configure output this :
> 
> checking whether the C compiler works... yes
> checking for C compiler default output file name... a.out
> checking for suffix of executables... 
> checking whether we are cross compiling... no
> checking for suffix of object files... o
> checking whether we are using the GNU C compiler... no
> checking whether /opt/SUNWspro/bin/cc accepts -g... yes
> checking for /opt/SUNWspro/bin/cc option to accept ISO C89... none needed
> checking whether the C++ compiler works... yes
> checking for C++ compiler default output file name... a.out
> checking for suffix of executables... 
> checking whether we are cross compiling... no
> checking for suffix of object files... o
> checking whether we are using the GNU C++ compiler... no
> checking whether /opt/SUNWspro/bin/CC accepts -g... yes
> checking for xlf95... no
> checking for f95... f95
> checking whether the Fortran compiler works... yes
> checking for Fortran compiler default output file name... a.out
> checking for suffix of executables... 
> checking whether we are cross compiling... no
> checking for suffix of object files... o
> checking whether we are using the GNU Fortran compiler... no
> checking whether f95 accepts -g... yes
> checking for xlf... no
> checking for f77... f77
> checking whether the Fortran 77 compiler works... yes
> checking for Fortran 77 compiler default output file name... a.out
> checking for suffix of executables... 
> checking whether we are cross compiling... no
> checking for suffix of object files... o
> checking whether we are using the GNU Fortran 77 compiler... no
> checking whether f77 accepts -g... yes
> configure: will now look for GNU compilers
> checking for gcc... no
> configure: WARNING: botched installation for GNU C compiler
> configure: tests requiring the GNU C compiler will be skipped
> checking for g++... no
> checking for gpp... no
> configure: WARNING: botched installation for GNU C++ compiler
> configure: tests requiring the GNU C++ compiler will be skipped
> checking for gfortran... no
> configure: WARNING: botched installation for GNU Fortran compiler
> configure: tests requiring the GNU Fortran compiler will be skipped
> checking for g77... no
> checking for gfortran... no
> configure: WARNING: botched installation for GNU Fortran 77 compiler
> configure: tests requiring the GNU Fortran 77 compiler will be skipped
> checking for gcj... no
> configure: WARNING: botched installation for GNU Java compiler
> configure: tests requiring the GNU Java compiler will be skipped
> checking that generated files are newer than configure... done
> configure: creating ./config.status
> 
> 
> Is there some reason why GNU Fortran is a "need" ? 
>
Only to run some tests.  That's why the configure script merely warn
if that compiler (or any of other ones, in fact) is missing: they are
not actually required to build and use Automake, but only to run its
testsuite properly.

> Also, Java compiler, I think Solaris includes a really top notch
> Java compiler in /usr/jdk/latest . 
>
That might be useful for the generic java tests (those checking the
JAVA primary), and those tests will automatically look for the
presence a 'java' and 'javac' programs in PATH at test runtime,
without a need for configure-time checks.  But some other test
cases actually target compilation into native object code with gcj;
they are not meant to work with generic Java compiler, however good
those might be.

HTH,
  Stefano

Message #57 received at 12184 <at> debbugs.gnu.org (full text, mbox):

From: Stefano Lattarini <stefano.lattarini <at> gmail.com>
To: Dennis Clarke <dclarke <at> blastwave.org>
Cc: 12184 <at> debbugs.gnu.org
Subject: Re: bug#12184: GNU Automake 1.12.2 - 4 tests FAIL on Solaris 10 Sparc
Date: Tue, 14 Aug 2012 10:38:37 +0200

On 08/14/2012 02:20 AM, Dennis Clarke wrote:
> cc: 12184 <at> debbugs.gnu.org
> 
>> On 08/13/2012 01:46 AM, Dennis Clarke wrote:
>>>
>>> At least I can get results in one hour now.  :-\
>>>
>>> [SNIP]
>>>
>> Same as before: the only actual failure is:
>>
>>     FAIL: t/silent-many-generic
>>     ===========================
>>
>>    ...
>>    + make
>>    ld: fatal: file baz2.o: wrong ELF class: ELFCLASS32
>>    ld: fatal: file processing errors. No output written to baz
>>    make: Fatal error: Command failed for target `baz'
>>
>> which seems to suggest your C++ linker has issues linking together
>> objects generated by your C++ compilers with objects generated by
>> your Fortran 90 compiler.  Could you try whether/how the same issue
>> is present outside the Automake testsuite?
> 
> Am trying .. in the meantime I think the best I will see is : 
> 
> ============================================================================
> Testsuite summary for GNU Automake 1.12.2
> ============================================================================
> # TOTAL: 2730
> # PASS:  2459
> # SKIP:  217
> # XFAIL: 50
> # FAIL:  4
> # XPASS: 0
> # ERROR: 0
> ============================================================================
> 
> So I am giving up on automake for now.
>
Why?  Three of those failures are spurious ones (already fixed in the
development version), and one of them is mostly due of a misconfiguration
in your Fortran/C++ compilers (or combination thereof), and even if it
turns out to be an actual bug in Automake, is one that would only affect
projects linking Fortran with C++ -- not very common I'd say.

> However there is a bug or flaw in there somewhere however I don't know where.
> I was able to build plenty of other packages and even get the latest Apache
> and apr/apu built and running fine.

> I am stuck with what I get in automake for at least a few days
> until I can come back to this.
> 
OK.  Waiting too see if the last failure gets resolved somehow, so that I'll
be able to close this bug report.

Thanks,
  Stefano

Message #60 received at 12184 <at> debbugs.gnu.org (full text, mbox):

From: Dennis Clarke <dclarke <at> blastwave.org>
To: Stefano Lattarini <stefano.lattarini <at> gmail.com>
Cc: 12184 <at> debbugs.gnu.org
Subject: Re: bug#12184: GNU Automake 1.12.2 - 4 tests FAIL on Solaris 10 Sparc
Date: Tue, 14 Aug 2012 15:30:36 +0000 (GMT)

> > Hey man, get off my soap box! I was here first.  :-)
> >
> Yeah, I noticed too late :-)  (after reading the latest messages
> in the bug-grep list).

I went through a little pain with pcre also but sorted it all 
out by determining that the output makefiles were assuming Linux,
as usual, and also trying to drive the link editor to set a 
init execution point in the ELF file that made no sense. 

Sorted it out and documented it : 

http://bugs.exim.org/show_bug.cgi?id=1278

So by the end of this process I hope to have a GCC compiler package
that anyone can use and all others can avoid the pain entirely. 

Dennis 

ps: I have been doing this for years .. so nothing new.

Message #63 received at 12184 <at> debbugs.gnu.org (full text, mbox):

From: Stefano Lattarini <stefano.lattarini <at> gmail.com>
To: Dennis Clarke <dclarke <at> blastwave.org>
Cc: 12184 <at> debbugs.gnu.org
Subject: Re: bug#12184: GNU Automake 1.12.2 - 4 tests FAIL on Solaris 10 Sparc
Date: Tue, 14 Aug 2012 19:23:56 +0200

On 08/14/2012 05:30 PM, Dennis Clarke wrote:
> 
>>> Hey man, get off my soap box! I was here first.  :-)
>>>
>> Yeah, I noticed too late :-)  (after reading the latest messages
>> in the bug-grep list).
> 
> I went through a little pain with pcre also but sorted it all 
> out by determining that the output makefiles were assuming Linux,
> as usual, and also trying to drive the link editor to set a 
> init execution point in the ELF file that made no sense. 
> 
> Sorted it out and documented it : 
> 
> http://bugs.exim.org/show_bug.cgi?id=1278
>
This should actually go to the grep list though, not to the automake
one ...  Or am I missing something?

Stefano

Message #66 received at 12184 <at> debbugs.gnu.org (full text, mbox):

From: Dennis Clarke <dclarke <at> blastwave.org>
To: Stefano Lattarini <stefano.lattarini <at> gmail.com>
Cc: 12184 <at> debbugs.gnu.org
Subject: Re: bug#12184: GNU Automake 1.12.2 - 4 tests FAIL on Solaris 10 Sparc
Date: Tue, 14 Aug 2012 17:33:14 +0000 (GMT)

> > http://bugs.exim.org/show_bug.cgi?id=1278
> >
> This should actually go to the grep list though, not to the automake
> one ...  Or am I missing something?

I as just illustrating that the portability issue is all over the place and in many software projects. It really doesn't matter if one looks at grep, automake, sed, pcre or whereever, you will run into issues the moment you leave the Linux reservation.  

In this pcre case what I saw was ( note, the words "saw" and "was" are mirrors I mis-type all the time ) horrific FLAGS in the Makefile that simply assume, you are on linux, you are using libtool and GNU ld, and if you are not, too bad for you : 

EXTRA_LIBPCRE16_LDFLAGS =                          -version-info 0:1:0
EXTRA_LIBPCRECPP_LDFLAGS =  -Wl,-i__ZN7pcrecpp6no_argE:__ZN7pcrecpp2RE6no_argE 
                          -version-info 0:0:
0
EXTRA_LIBPCREPOSIX_LDFLAGS =                               -version-info 0:1:0
EXTRA_LIBPCRE_LDFLAGS =                          -version-info 1:1:0

whatever that is, it looks horrific. 

Cleaning out all the whitespace I get : 

EXTRA_LIBPCRE16_LDFLAGS = -version-info 0:1:0
EXTRA_LIBPCRECPP_LDFLAGS = -Wl,-i__ZN7pcrecpp6no_argE:__ZN7pcrecpp2RE6no_argE
-version-info 0:0:0                           
EXTRA_LIBPCREPOSIX_LDFLAGS = -version-info 0:1:0
EXTRA_LIBPCRE_LDFLAGS = -version-info 1:1:0

It looks as if we are trying ot pass the ( mildly scary ) 
argument '-i__ZN7pcrecpp6no_argE:__ZN7pcrecpp2RE6no_argE' to the link
editor ld.

The first problem here is that the option -i does not mean very much to
the Solaris linker ld.  The other issue is that even on GNU Linux the 
-i option not be what we want. 


Anyways, anyone in the BSD world probably hits the same issues all the time and I can say from experience, years of it, this happens all the time and everywhere in Solaris pretty much. No ones fault other than the jerks at Sun followed by the much larger jerks at Oracle. It has taken them ten yers of stupid to get to a point where no one wants to work with UNIX anymore and hey, I live in front of Debian and love it. So who cares? Only the folks stuck ( trapped on some old business application ) on Solaris while they try to $$migrate$$ away .. forever. 

Dennis 

Message #69 received at 12184 <at> debbugs.gnu.org (full text, mbox):

From: Stefano Lattarini <stefano.lattarini <at> gmail.com>
To: Dennis Clarke <dclarke <at> blastwave.org>
Cc: 12184 <at> debbugs.gnu.org
Subject: Re: bug#12184: GNU Automake 1.12.2 - 4 tests FAIL on Solaris 10 Sparc
Date: Tue, 14 Aug 2012 19:52:49 +0200

On 08/14/2012 07:33 PM, Dennis Clarke wrote:
> No ones fault other than the jerks at Sun followed by the much
> larger jerks at Oracle.
>
While I might sympathize with your frustration, I *strongly* ask you
to refrain from name-calling on this list.  Using harsh words against
problematic/buggy software is OK, but insulting a potentially huge
group of people just to vent out some frustration is not acceptable.

Thanks,
  Stefano

Message #72 received at 12184 <at> debbugs.gnu.org (full text, mbox):

From: Stefano Lattarini <stefano.lattarini <at> gmail.com>
To: 12184 <at> debbugs.gnu.org
Cc: Dennis Clarke <dclarke <at> blastwave.org>
Subject: Testsuite on Solaris 10 Sparc
Date: Wed, 21 Nov 2012 12:54:33 +0100

Reference:
<http://debbugs.gnu.org/cgi/bugreport.cgi?bug=12184>

Hi Dennis.

Any news on this?  How is the testsuite of the latest Automake behaving
on your system?  I'm in the process of culling old bug reports from the
Automake bug tracker, so, since most of the failures seen in this
thread were spurious or related to setup problems, I'll close this
report in a few days if I don't hear anything back.

Regards,
  Stefano

Message #75 received at 12184 <at> debbugs.gnu.org (full text, mbox):

From: Dennis Clarke <dclarke <at> blastwave.org>
To: Stefano Lattarini <stefano.lattarini <at> gmail.com>
Cc: 12184 <at> debbugs.gnu.org
Subject: Re: Testsuite on Solaris 10 Sparc
Date: Wed, 21 Nov 2012 15:32:11 -0500

> Any news on this?  How is the testsuite of the latest Automake behaving
> on your system?  I'm in the process of culling old bug reports from the
> Automake bug tracker, so, since most of the failures seen in this
> thread were spurious or related to setup problems, I'll close this
> report in a few days if I don't hear anything back.

hold on a sec .. got busy with other things. 

However .. I think that at last glance we had a perfect test suite result
here.  Give me a few hours to verify. 

Dennis 
 

Message #78 received at 12184 <at> debbugs.gnu.org (full text, mbox):

From: Stefano Lattarini <stefano.lattarini <at> gmail.com>
To: Dennis Clarke <dclarke <at> blastwave.org>
Cc: 12184 <at> debbugs.gnu.org
Subject: Re: bug#12184: Testsuite on Solaris 10 Sparc
Date: Thu, 22 Nov 2012 10:02:21 +0100

On 11/21/2012 09:32 PM, Dennis Clarke wrote:
> 
>> Any news on this?  How is the testsuite of the latest Automake behaving
>> on your system?  I'm in the process of culling old bug reports from the
>> Automake bug tracker, so, since most of the failures seen in this
>> thread were spurious or related to setup problems, I'll close this
>> report in a few days if I don't hear anything back.
> 
> hold on a sec .. got busy with other things. 
> 
> However .. I think that at last glance we had a perfect test suite result
> here.  Give me a few hours to verify. 
>
No hurry, and thank you.

Regards,
  Stefano

Message #83 received at 12184-done <at> debbugs.gnu.org (full text, mbox):

From: Stefano Lattarini <stefano.lattarini <at> gmail.com>
To: Dennis Clarke <dclarke <at> blastwave.org>
Cc: 12184-done <at> debbugs.gnu.org
Subject: Re: bug#12184: Testsuite on Solaris 10 Sparc
Date: Fri, 23 Nov 2012 11:29:38 +0100

On 11/21/2012 09:32 PM, Dennis Clarke wrote:
> 
> 
>> Any news on this?  How is the testsuite of the latest Automake behaving
>> on your system?  I'm in the process of culling old bug reports from the
>> Automake bug tracker, so, since most of the failures seen in this
>> thread were spurious or related to setup problems, I'll close this
>> report in a few days if I don't hear anything back.
> 
> hold on a sec .. got busy with other things. 
> 
> However .. I think that at last glance we had a perfect test suite result
> here.  Give me a few hours to verify. 
> 
I see you've re-run the testsuite with Automake 1.12.5, and reported
the results here:

    <http://debbugs.gnu.org/cgi/bugreport.cgi?bug=12962>

Further discussion will take place there.  I'm thus closing this bug report.

Thanks,
  Stefano

Message #86 received at 12184-done <at> debbugs.gnu.org (full text, mbox):

From: Dennis Clarke <dclarke <at> blastwave.org>
To: Stefano Lattarini <stefano.lattarini <at> gmail.com>
Cc: 12184-done <at> debbugs.gnu.org
Subject: Re: bug#12184: Testsuite on Solaris 10 Sparc
Date: Fri, 23 Nov 2012 09:11:38 -0500

> I see you've re-run the testsuite with Automake 1.12.5, and reported
> the results here:
>

It seemed reasonable  to work with the latest release. 
 
> Further discussion will take place there.  I'm thus closing this bug report.

I will now go off and check grep and then come back to automake.

dc

Message #89 received at 12184-done <at> debbugs.gnu.org (full text, mbox):

From: Stefano Lattarini <stefano.lattarini <at> gmail.com>
To: Dennis Clarke <dclarke <at> blastwave.org>
Cc: 12184-done <at> debbugs.gnu.org
Subject: Re: bug#12184: Testsuite on Solaris 10 Sparc
Date: Fri, 23 Nov 2012 15:13:47 +0100

On 11/23/2012 03:11 PM, Dennis Clarke wrote:
> 
>> I see you've re-run the testsuite with Automake 1.12.5, and reported
>> the results here:
>>
> 
> It seemed reasonable  to work with the latest release. 
>
It is indeed reasonable, and in fact I appreciate it.  Sorry if my curt
message sounded like criticism -- it wasn't intended too.

>> Further discussion will take place there.  I'm thus closing this bug report.
> 
> I will now go off and check grep and then come back to automake.
> 
OK.

Thanks,
  Stefano

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.