GNU bug report logs - #11524
[platform-testers] Automake 1.12.0b test release

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 11524 in the body.
You can then email your comments to 11524 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: Dagobert Michelsen <dam <at> opencsw.org>
To: bug-automake <at> gnu.org
Cc: platform-testers <at> gnu.org
Subject: Re: [platform-testers] Automake 1.12.0b test release
Date: Sun, 20 May 2012 11:57:06 +0200

Hi Stefano,

Am 19.05.2012 um 16:17 schrieb Stefano Lattarini:
> The beta release "1.12.0b" of GNU Automake is now available at
> <ftp://alpha.gnu.org/gnu/automake/>.  The stable release 1.12.1 is
> planned for next Thursday (May 24).  The relevant changes since
> the last stable release 1.12 are described in this announce on the
> Automake list:
> 
> <http://lists.gnu.org/archive/html/automake/2012-05/msg00020.html>
> 
> Please send bug reports to <bug-automake <at> gnu.org>, and general
> feedback to <automake <at> gnu.org>.

I just tested on Solaris 9 Sparc with Sun Studio 12 and got 170 failed tests
as described in the testsuite log:
  http://buildfarm.opencsw.org/~dam/automake-1.12.0b-test-suite.log

Please let me know if you need further information or access to the buildfarm.


Best regards

  -- Dago

-- 
"You don't become great by trying to be great, you become great by wanting to do something,
and then doing it so hard that you become great in the process." - xkcd #896

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

From: Stefano Lattarini <stefano.lattarini <at> gmail.com>
To: Dagobert Michelsen <dam <at> opencsw.org>
Cc: 11524 <at> debbugs.gnu.org
Subject: Re: bug#11524: [platform-testers] Automake 1.12.0b test release
Date: Fri, 01 Jun 2012 14:12:03 +0200

tags 11524 + moreinfo
thanks

Hi Dagobert.

On 05/20/2012 11:57 AM, Dagobert Michelsen wrote:
> Hi Stefano,
> 
> Am 19.05.2012 um 16:17 schrieb Stefano Lattarini:
>> The beta release "1.12.0b" of GNU Automake is now available at
>> <ftp://alpha.gnu.org/gnu/automake/>.  The stable release 1.12.1 is
>> planned for next Thursday (May 24).  The relevant changes since
>> the last stable release 1.12 are described in this announce on the
>> Automake list:
>>
>> <http://lists.gnu.org/archive/html/automake/2012-05/msg00020.html>
>>
>> Please send bug reports to <bug-automake <at> gnu.org>, and general
>> feedback to <automake <at> gnu.org>.
> 
> I just tested on Solaris 9 Sparc with Sun Studio 12 and got 170 failed tests
> as described in the testsuite log:
>   http://buildfarm.opencsw.org/~dam/automake-1.12.0b-test-suite.log
> 
> Please let me know if you need further information or access to the buildfarm.
> 
I've so far been unable to reproduce the failures.  Can you replicate them
reliably?  If yes, could you give a more precise recipe on how to reproduce
them?

Thanks,
  Stefano

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

From: Stefano Lattarini <stefano.lattarini <at> gmail.com>
To: Dagobert Michelsen <dam <at> opencsw.org>
Cc: 11524 <at> debbugs.gnu.org
Subject: ping on automake bug#11524
Date: Tue, 11 Sep 2012 11:01:35 +0200

Resurrecting an oldish bug report:
<http://debbugs.gnu.org/cgi/bugreport.cgi?bug=11524>

Hi Dagobert.

Can you still reproduce the failures reported in bug#11524 with the
latest Automake version (1.12.3)?  If not, I will close the bug.

Regards,
  Stefano

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

From: Dagobert Michelsen <dam <at> opencsw.org>
To: Stefano Lattarini <stefano.lattarini <at> gmail.com>
Cc: 11524 <at> debbugs.gnu.org
Subject: Re: ping on automake bug#11524
Date: Tue, 11 Sep 2012 17:29:05 +0200

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

Hi Stefano,

Am 11.09.2012 um 11:01 schrieb Stefano Lattarini <stefano.lattarini <at> gmail.com>:
> Resurrecting an oldish bug report:
> <http://debbugs.gnu.org/cgi/bugreport.cgi?bug=11524>
> 
> Hi Dagobert.
> 
> Can you still reproduce the failures reported in bug#11524 with the
> latest Automake version (1.12.3)?  If not, I will close the bug.


I am just running the test suite, it is now about 75% finished without failures and will
probably take the night to finish. I'll keep you posted.


Best regards

  -- Dago

-- 
"You don't become great by trying to be great, you become great by wanting to do something,
and then doing it so hard that you become great in the process." - xkcd #896

[smime.p7s (application/pkcs7-signature, attachment)]

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

From: Dagobert Michelsen <dam <at> opencsw.org>
To: Stefano Lattarini <stefano.lattarini <at> gmail.com>
Cc: 11524 <at> debbugs.gnu.org
Subject: Re: bug#11524: ping on automake bug#11524
Date: Wed, 12 Sep 2012 09:12:20 +0200

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

Hi Stefano,

Am 11.09.2012 um 17:29 schrieb Dagobert Michelsen <dam <at> opencsw.org>:
> Am 11.09.2012 um 11:01 schrieb Stefano Lattarini <stefano.lattarini <at> gmail.com>:
>> Resurrecting an oldish bug report:
>> <http://debbugs.gnu.org/cgi/bugreport.cgi?bug=11524>
>> 
>> Can you still reproduce the failures reported in bug#11524 with the
>> latest Automake version (1.12.3)?  If not, I will close the bug.
> 
> I am just running the test suite, it is now about 75% finished without failures and will
> probably take the night to finish. I'll keep you posted.


Nope, not better than the version before:
  http://buildfarm.opencsw.org/~dam/automake-1.12.3-test-suite.log


Best regards

  -- Dago

-- 
"You don't become great by trying to be great, you become great by wanting to do something,
and then doing it so hard that you become great in the process." - xkcd #896

[smime.p7s (application/pkcs7-signature, attachment)]

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

From: Stefano Lattarini <stefano.lattarini <at> gmail.com>
To: Dagobert Michelsen <dam <at> opencsw.org>
Cc: 11524 <at> debbugs.gnu.org
Subject: Re: bug#11524: ping on automake bug#11524
Date: Wed, 12 Sep 2012 09:33:10 +0200

On 09/12/2012 09:12 AM, Dagobert Michelsen wrote:
> Hi Stefano,
>
Hi Dagobert, thanks for not giving up on this.

> Am 11.09.2012 um 17:29 schrieb Dagobert Michelsen <dam <at> opencsw.org>:
>> Am 11.09.2012 um 11:01 schrieb Stefano Lattarini <stefano.lattarini <at> gmail.com>:
>>> Resurrecting an oldish bug report:
>>> <http://debbugs.gnu.org/cgi/bugreport.cgi?bug=11524>
>>>
>>> Can you still reproduce the failures reported in bug#11524 with the
>>> latest Automake version (1.12.3)?  If not, I will close the bug.
>>
>> I am just running the test suite, it is now about 75% finished without failures
> and will probably take the night to finish. I'll keep you posted.
> 
> 
> Nope, not better than the version before:
>   http://buildfarm.opencsw.org/~dam/automake-1.12.3-test-suite.log
> 
Did you run the testsuite with a particular PATH or environment setup? I
ask because, when I tried to reproduce your failures on the same machine,
I wasn't able to.

In particular, almost all of the reported failures are due to something
like this:

    $ ./configure am_cv_CC_dependencies_compiler_type=...
    ...
    checking for gcc... gcc
    checking whether the C compiler works... no
    configure: error: C compiler cannot create executables
    See `config.log' for more details
    not ok 1 - [in-tree build] configure
    FAIL: t/depcomp-lt-cpp.tap 1 - [in-tree build] configure

which reeks of spurious failure and/or environment botch-up to me.

Thanks,
  Stefano

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

From: Stefano Lattarini <stefano.lattarini <at> gmail.com>
To: Dagobert Michelsen <dam <at> opencsw.org>
Cc: 11524 <at> debbugs.gnu.org
Subject: Re: bug#11524: ping on automake bug#11524
Date: Wed, 21 Nov 2012 11:11:42 +0100

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

On 09/12/2012 09:33 AM, Stefano Lattarini wrote:
> On 09/12/2012 09:12 AM, Dagobert Michelsen wrote:
>> Hi Stefano,
>>
> Hi Dagobert, thanks for not giving up on this.
> 
>> Am 11.09.2012 um 17:29 schrieb Dagobert Michelsen <dam <at> opencsw.org>:
>>> Am 11.09.2012 um 11:01 schrieb Stefano Lattarini <stefano.lattarini <at> gmail.com>:
>>>> Resurrecting an oldish bug report:
>>>> <http://debbugs.gnu.org/cgi/bugreport.cgi?bug=11524>
>>>>
>>>> Can you still reproduce the failures reported in bug#11524 with the
>>>> latest Automake version (1.12.3)?  If not, I will close the bug.
>>>
>>> I am just running the test suite, it is now about 75% finished without failures
>> and will probably take the night to finish. I'll keep you posted.
>>
>>
>> Nope, not better than the version before:
>>   http://buildfarm.opencsw.org/~dam/automake-1.12.3-test-suite.log
>>
> Did you run the testsuite with a particular PATH or environment setup? I
> ask because, when I tried to reproduce your failures on the same machine,
> I wasn't able to.
> 
> In particular, almost all of the reported failures are due to something
> like this:
> 
>     $ ./configure am_cv_CC_dependencies_compiler_type=...
>     ...
>     checking for gcc... gcc
>     checking whether the C compiler works... no
>     configure: error: C compiler cannot create executables
>     See `config.log' for more details
>     not ok 1 - [in-tree build] configure
>     FAIL: t/depcomp-lt-cpp.tap 1 - [in-tree build] configure
> 
> which reeks of spurious failure and/or environment botch-up to me.
>
Any news on this bug?  Can it still be reproduced with Automake 1.12.5?
Can it be reproduced with the development version of Automake from the
'master' branch?  Since the evidence so far seems to point to spurious
errors, I will close this report in a few days if I haven't heard back
by then.

Thanks,
  Stefano

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

From: Dagobert Michelsen <dam <at> opencsw.org>
To: Stefano Lattarini <stefano.lattarini <at> gmail.com>
Cc: 11524 <at> debbugs.gnu.org
Subject: Re: bug#11524: ping on automake bug#11524
Date: Wed, 21 Nov 2012 22:17:35 +0100

Hi Stefano,

Am 21.11.2012 um 11:11 schrieb Stefano Lattarini <stefano.lattarini <at> gmail.com>:
> Reference:
> <http://debbugs.gnu.org/cgi/bugreport.cgi?bug=11524>
> 
> Any news on this bug?  Can it still be reproduced with Automake 1.12.5?
> Can it be reproduced with the development version of Automake from the
> 'master' branch?  Since the evidence so far seems to point to spurious
> errors, I will close this report in a few days if I haven't heard back
> by then.


I still get quite some failures:
  http://buildfarm.opencsw.org/~dam/automake-1.12.5-test-suite.log


Best regards

  -- Dago

-- 
"You don't become great by trying to be great, you become great by wanting to do something,
and then doing it so hard that you become great in the process." - xkcd #896

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

From: Stefano Lattarini <stefano.lattarini <at> gmail.com>
To: Dagobert Michelsen <dam <at> opencsw.org>
Cc: 11524 <at> debbugs.gnu.org,
	"automake-patches <at> gnu.org" <automake-patches <at> gnu.org>,
	12836 <at> debbugs.gnu.org
Subject: Re: bug#11524: ping on automake bug#11524
Date: Thu, 22 Nov 2012 10:39:44 +0100

[+cc bug#12836, automake-patches]

On 11/21/2012 10:17 PM, Dagobert Michelsen wrote:
> Hi Stefano,
>
Hi Dagobert, thanks for the quick reply.

> Am 21.11.2012 um 11:11 schrieb Stefano Lattarini <stefano.lattarini <at> gmail.com>:
>> Reference:
>> <http://debbugs.gnu.org/cgi/bugreport.cgi?bug=11524>
>>
>> Any news on this bug?  Can it still be reproduced with Automake 1.12.5?
>> Can it be reproduced with the development version of Automake from the
>> 'master' branch?  Since the evidence so far seems to point to spurious
>> errors, I will close this report in a few days if I haven't heard back
>> by then.
> 
> 
> I still get quite some failures:
>   http://buildfarm.opencsw.org/~dam/automake-1.12.5-test-suite.log
>
Let's try to go through them one by one (in different replies).

> FAIL: t/lex-header
> lex-header: running flex --version
> flex version 2.5.4
>
OK, this version of flex is ~ 15 years old, and ...

> /bin/bash ./ylwrap `test -f 'lexer.l' || echo './'`lexer.l \
>    lex.yy.c foo-lexer.c -- flex --header-file=mylex.h
> flex: unknown flag '-'.  For usage, try
>	flex --help
> *** Error code 1
> make: Fatal error: Command failed for target `foo-lexer.c'
>
... doesn't support the '--header-file' option.  This issue has been
reported once already (in automake bug#12836, which I am CC:ing).
The patch should take care of the issue.  Can you confirm it works?

---- 8< ---- 8< ---- 8< ---- 8< ---- 8< ---- 8< ---- 8< ---- 8< ----

From 656f866264c7afe0f821eb0962aad8ff2f65c531 Mon Sep 17 00:00:00 2001
Message-Id: <656f866264c7afe0f821eb0962aad8ff2f65c531.1353576830.git.stefano.lattarini <at> gmail.com>
From: Stefano Lattarini <stefano.lattarini <at> gmail.com>
Date: Thu, 22 Nov 2012 10:29:37 +0100
Subject: [PATCH] tests: fix a spurious failure with older flex versions

See automake bug#11524 and bug#12836.

* t/lex-header.sh: Here, we use flex option '--header-file',
but that option is not supported by some older flex versions.
Simply skip this test if such an old flex version is detected.

Signed-off-by: Stefano Lattarini <stefano.lattarini <at> gmail.com>
---
 t/lex-header.sh | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/t/lex-header.sh b/t/lex-header.sh
index f8d7333..ad2976e 100755
--- a/t/lex-header.sh
+++ b/t/lex-header.sh
@@ -20,6 +20,12 @@
 required='cc flex'
 . ./defs || exit 1

+# Here, we need to use the use flex option '--header-file', but some
+# older flex versions don't support is (see automake bug#11524 and
+# bug#12836).  Skip this test if such an old flex version is detected.
+$LEX --help | grep '.*--header-file' \
+  || skip_ "flex doesn't support the --header-file' option"
+
 cat >> configure.ac << 'END'
 AC_PROG_CC
 AC_PROG_LEX
-- 
1.8.0.209.gf3828dc

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

From: Stefano Lattarini <stefano.lattarini <at> gmail.com>
To: Dagobert Michelsen <dam <at> opencsw.org>
Cc: 11524 <at> debbugs.gnu.org
Subject: Re: bug#11524: ping on automake bug#11524
Date: Thu, 22 Nov 2012 10:42:32 +0100

On 11/21/2012 10:17 PM, Dagobert Michelsen wrote:
> 
> I still get quite some failures:
>   http://buildfarm.opencsw.org/~dam/automake-1.12.5-test-suite.log

> FAIL: t/depcomp-lt-cpp
> ======================
>
> depcomp-lt-cpp: running libtoolize --version
> libtoolize (GNU libtool) 2.4.2
> [SNIP]
> + . depcomp.sh
> +++ pwd
> ++ ocwd=/home/dam/.../automake-1.12.5/t/depcomp-lt-cpp.dir
> ++ longpath=this-is/a-path/which-has/quite-a/definitely/truly/long_long_name
> ++ cachevar=am_cv_CC_dependencies_compiler_type
> [SNIP]
> ++ displayed_depmode='(cached) cpp'
> ++ cfg_deptrack=am_cv_CC_dependencies_compiler_type=cpp
> ++ /opt/csw/bin/ggrep -F am_cv_CC_dependencies_compiler_type configure
> if ${am_cv_CC_dependencies_compiler_type+:} false; then :
>   am_cv_CC_dependencies_compiler_type=none
>         am_cv_CC_dependencies_compiler_type=$depmode
>   am_cv_CC_dependencies_compiler_type=none
> { $as_echo "$as_me:${as_lineno-$LINENO}: result: $am_cv_CC_dependencies_compiler_type" >&5
> $as_echo "$am_cv_CC_dependencies_compiler_type" >&6; }
> CCDEPMODE=depmode=$am_cv_CC_dependencies_compiler_type
>   && test "$am_cv_CC_dependencies_compiler_type" = gcc3; then
> ++ cd_top
> ++ cd /home/dam/.../automake-1.12.5/t/depcomp-lt-cpp.dir
> [SNIP]
> ++ mkdir intree
> ++ cd intree
> [SNIP]
> ++ ./configure am_cv_CC_dependencies_compiler_type=cpp
> configure: error: in `/home/dam/mgar/pkg/automake/trunk/work/solaris10-sparc/build-isa-sparcv8plus-version-1.12.5/automake-1.12.5/t/depcomp-lt-cpp.dir/intree':
> configure: error: C compiler cannot create executables
> See `config.log' for more details
> ++ tap_result_='not ok'
> ++ result_ 'not ok' -D '' -r '' -- '[in-tree build] configure'
> ++ set +x
> ++ cat stdout
> checking for a BSD-compatible install... /opt/csw/bin/ginstall -c
> checking whether build environment is sane... yes
> checking for a thread-safe mkdir -p... /opt/csw/bin/gmkdir -p
> checking for gawk... gawk
> checking whether make sets $(MAKE)... yes
> checking for gcc... gcc
> checking whether the C compiler works... no
> not ok 1 - [in-tree build] configure
> FAIL: t/depcomp-lt-cpp.tap 1 - [in-tree build] configure
>
OK, this reeks of spurious failure.  Can you post the contents of the
'config.log' corresponding to this configure run?  It should have been
left in the 'intree' subdirectory of the 'depcomp-lt-cpp.dir' test
directory.

The other failures in the 't/depcomp-*.tap' tests look similar, so
if we solve this failure, we are likely going to solve those other
ones as well.

Thanks,
  Stefano

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

From: Stefano Lattarini <stefano.lattarini <at> gmail.com>
To: Dagobert Michelsen <dam <at> opencsw.org>
Cc: 11524 <at> debbugs.gnu.org
Subject: Re: bug#11524: ping on automake bug#11524
Date: Thu, 22 Nov 2012 10:50:58 +0100

On 11/21/2012 10:17 PM, Dagobert Michelsen wrote:
> 
> I still get quite some failures:
>   http://buildfarm.opencsw.org/~dam/automake-1.12.5-test-suite.log
> 

> FAIL: t/amhello-binpkg
> ======================
>
> [SNIP]
>
> + make
> make  all-recursive
> Making all in src
> source='main.c' object='main.o' libtool=no \
> DEPDIR=.deps depmode=none /bin/bash ../depcomp \
> /opt/SUNWspro/bin/cc -DHAVE_CONFIG_H -I. -I..    -I/opt/csw/include  -xO3 -m32 -xarch=sparc -c main.c
> /opt/SUNWspro/bin/cc  -xO3 -m32 -xarch=sparc  -m32 -xarch=sparc -L/opt/csw/lib -o hello main.o
> ++ pwd
> + make DESTDIR=/home/dam/.../amhello-1.0/inst install
> Making install in src
> [SNIP]
> + cd inst
> + find . -type f -print
> ++ cat ../files.lst
> + tar cvf amhello-1.0-i686.tar.gz ./usr/bin/hello ./usr/share/doc/amhello/README
> ++ sed -n -e 's/^EXEEXT *= *//p'
> + EXEEXT=
> + tar --version
> + grep GNU
> + : Be laxer with other tar implementations, to avoid spurious failures.
> + /opt/csw/bin/ggrep -E '(^| )\./usr/bin/hello( |$)' tar.got
> + am_exit_trap 1
> + exit_status=1

Could you please send us the content of these files?

  t/amhello-binpkg.dir/amhello-1.0/files.lst
  t/amhello-binpkg.dir/amhello-1.0/inst/tar.got

Thanks,
  Stefano

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

From: Stefano Lattarini <stefano.lattarini <at> gmail.com>
To: Dagobert Michelsen <dam <at> opencsw.org>
Cc: 11524 <at> debbugs.gnu.org,
	"automake-patches <at> gnu.org" <automake-patches <at> gnu.org>,
	12836 <at> debbugs.gnu.org
Subject: Re: bug#12836: bug#11524: ping on automake bug#11524
Date: Sat, 24 Nov 2012 13:06:00 +0100

On 11/22/2012 10:39 AM, Stefano Lattarini wrote:
>
> 
>> FAIL: t/lex-header
>> lex-header: running flex --version
>> flex version 2.5.4
>>
> OK, this version of flex is ~ 15 years old, and ...
> 
>> /bin/bash ./ylwrap `test -f 'lexer.l' || echo './'`lexer.l \
>>    lex.yy.c foo-lexer.c -- flex --header-file=mylex.h
>> flex: unknown flag '-'.  For usage, try
>> 	flex --help
>> *** Error code 1
>> make: Fatal error: Command failed for target `foo-lexer.c'
>>
> ... doesn't support the '--header-file' option.  This issue has been
> reported once already (in automake bug#12836, which I am CC:ing).
> The patch should take care of the issue.
> 
>  -*-*-*-
>
> Subject: [PATCH] tests: fix a spurious failure with older flex versions
> 
> See automake bug#11524 and bug#12836.
> 
> * t/lex-header.sh: Here, we use flex option '--header-file',
> but that option is not supported by some older flex versions.
> Simply skip this test if such an old flex version is detected.
> 
I've now pushed this patch (to maint).

Regards,
  Stefano

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

From: Dagobert Michelsen <dam <at> opencsw.org>
To: Stefano Lattarini <stefano.lattarini <at> gmail.com>
Cc: 11524 <at> debbugs.gnu.org
Subject: Re: bug#11524: ping on automake bug#11524
Date: Mon, 26 Nov 2012 09:19:12 +0100

Hi Stefano,

sorry fot the delay, I was away.

Am 22.11.2012 um 10:50 schrieb Stefano Lattarini <stefano.lattarini <at> gmail.com>:
> On 11/21/2012 10:17 PM, Dagobert Michelsen wrote:
>> 
>> I still get quite some failures:
>>  http://buildfarm.opencsw.org/~dam/automake-1.12.5-test-suite.log
>> 
> 
>> FAIL: t/amhello-binpkg
>> ======================
>> 
>> [SNIP]
>> 
>> + make
>> make  all-recursive
>> Making all in src
>> source='main.c' object='main.o' libtool=no \
>> DEPDIR=.deps depmode=none /bin/bash ../depcomp \
>> /opt/SUNWspro/bin/cc -DHAVE_CONFIG_H -I. -I..    -I/opt/csw/include  -xO3 -m32 -xarch=sparc -c main.c
>> /opt/SUNWspro/bin/cc  -xO3 -m32 -xarch=sparc  -m32 -xarch=sparc -L/opt/csw/lib -o hello main.o
>> ++ pwd
>> + make DESTDIR=/home/dam/.../amhello-1.0/inst install
>> Making install in src
>> [SNIP]
>> + cd inst
>> + find . -type f -print
>> ++ cat ../files.lst
>> + tar cvf amhello-1.0-i686.tar.gz ./usr/bin/hello ./usr/share/doc/amhello/README
>> ++ sed -n -e 's/^EXEEXT *= *//p'
>> + EXEEXT=
>> + tar --version
>> + grep GNU
>> + : Be laxer with other tar implementations, to avoid spurious failures.
>> + /opt/csw/bin/ggrep -E '(^| )\./usr/bin/hello( |$)' tar.got
>> + am_exit_trap 1
>> + exit_status=1
> 
> Could you please send us the content of these files?
> 
>  t/amhello-binpkg.dir/amhello-1.0/files.lst
>  t/amhello-binpkg.dir/amhello-1.0/inst/tar.got


Sure, I just copied over the whole build directory, feel free to take a look:
  http://buildfarm.opencsw.org/~dam/automake-1.12.5/
It is the build with your patch applied.


Just let me know if I can help.


Best regards

  -- Dago

-- 
"You don't become great by trying to be great, you become great by wanting to do something,
and then doing it so hard that you become great in the process." - xkcd #896

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

From: Dagobert Michelsen <dam <at> opencsw.org>
To: Stefano Lattarini <stefano.lattarini <at> gmail.com>
Cc: 11524 <at> debbugs.gnu.org,
	"automake-patches <at> gnu.org" <automake-patches <at> gnu.org>,
	12836 <at> debbugs.gnu.org
Subject: Re: bug#11524: ping on automake bug#11524
Date: Mon, 26 Nov 2012 09:21:21 +0100

Hi Stefano,

Am 22.11.2012 um 10:39 schrieb Stefano Lattarini <stefano.lattarini <at> gmail.com>:

> [+cc bug#12836, automake-patches]
> 
> On 11/21/2012 10:17 PM, Dagobert Michelsen wrote:
>> Hi Stefano,
>> 
> Hi Dagobert, thanks for the quick reply.
> 
>> Am 21.11.2012 um 11:11 schrieb Stefano Lattarini <stefano.lattarini <at> gmail.com>:
>>> Reference:
>>> <http://debbugs.gnu.org/cgi/bugreport.cgi?bug=11524>
>>> 
>>> Any news on this bug?  Can it still be reproduced with Automake 1.12.5?
>>> Can it be reproduced with the development version of Automake from the
>>> 'master' branch?  Since the evidence so far seems to point to spurious
>>> errors, I will close this report in a few days if I haven't heard back
>>> by then.
>> 
>> 
>> I still get quite some failures:
>>  http://buildfarm.opencsw.org/~dam/automake-1.12.5-test-suite.log
>> 
> Let's try to go through them one by one (in different replies).
> 
>> FAIL: t/lex-header
>> lex-header: running flex --version
>> flex version 2.5.4
>> 
> OK, this version of flex is ~ 15 years old, and ...
> 
>> /bin/bash ./ylwrap `test -f 'lexer.l' || echo './'`lexer.l \
>>   lex.yy.c foo-lexer.c -- flex --header-file=mylex.h
>> flex: unknown flag '-'.  For usage, try
>> 	flex --help
>> *** Error code 1
>> make: Fatal error: Command failed for target `foo-lexer.c'
>> 
> ... doesn't support the '--header-file' option.  This issue has been
> reported once already (in automake bug#12836, which I am CC:ing).
> The patch should take care of the issue.  Can you confirm it works?

Looks good, no more "unknown flag" in test-suite.log


Best regards

  -- Dago

> ---- 8< ---- 8< ---- 8< ---- 8< ---- 8< ---- 8< ---- 8< ---- 8< ----
> 
> From 656f866264c7afe0f821eb0962aad8ff2f65c531 Mon Sep 17 00:00:00 2001
> Message-Id: <656f866264c7afe0f821eb0962aad8ff2f65c531.1353576830.git.stefano.lattarini <at> gmail.com>
> From: Stefano Lattarini <stefano.lattarini <at> gmail.com>
> Date: Thu, 22 Nov 2012 10:29:37 +0100
> Subject: [PATCH] tests: fix a spurious failure with older flex versions
> 
> See automake bug#11524 and bug#12836.
> 
> * t/lex-header.sh: Here, we use flex option '--header-file',
> but that option is not supported by some older flex versions.
> Simply skip this test if such an old flex version is detected.
> 
> Signed-off-by: Stefano Lattarini <stefano.lattarini <at> gmail.com>
> ---
> t/lex-header.sh | 6 ++++++
> 1 file changed, 6 insertions(+)
> 
> diff --git a/t/lex-header.sh b/t/lex-header.sh
> index f8d7333..ad2976e 100755
> --- a/t/lex-header.sh
> +++ b/t/lex-header.sh
> @@ -20,6 +20,12 @@
> required='cc flex'
> . ./defs || exit 1
> 
> +# Here, we need to use the use flex option '--header-file', but some
> +# older flex versions don't support is (see automake bug#11524 and
> +# bug#12836).  Skip this test if such an old flex version is detected.
> +$LEX --help | grep '.*--header-file' \
> +  || skip_ "flex doesn't support the --header-file' option"
> +
> cat >> configure.ac << 'END'
> AC_PROG_CC
> AC_PROG_LEX
> -- 
> 1.8.0.209.gf3828dc

-- 
"You don't become great by trying to be great, you become great by wanting to do something,
and then doing it so hard that you become great in the process." - xkcd #896

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

From: Stefano Lattarini <stefano.lattarini <at> gmail.com>
To: Dagobert Michelsen <dam <at> opencsw.org>
Cc: 11524 <at> debbugs.gnu.org
Subject: Re: bug#11524: ping on automake bug#11524
Date: Mon, 26 Nov 2012 12:25:54 +0100

On 11/26/2012 09:19 AM, Dagobert Michelsen wrote:
> Hi Stefano,
> 
> sorry fot the delay, I was away.
>
No problem.

> Am 22.11.2012 um 10:50 schrieb Stefano Lattarini <stefano.lattarini <at> gmail.com>:
>> On 11/21/2012 10:17 PM, Dagobert Michelsen wrote:
>>>
>>> I still get quite some failures:
>>>  http://buildfarm.opencsw.org/~dam/automake-1.12.5-test-suite.log
>>>
>>
>>> FAIL: t/amhello-binpkg
>>> ======================
>>>
>>> [SNIP]
>>>
>>> + make
>>> make  all-recursive
>>> Making all in src
>>> source='main.c' object='main.o' libtool=no \
>>> DEPDIR=.deps depmode=none /bin/bash ../depcomp \
>>> /opt/SUNWspro/bin/cc -DHAVE_CONFIG_H -I. -I..    -I/opt/csw/include  -xO3 -m32 -xarch=sparc -c main.c
>>> /opt/SUNWspro/bin/cc  -xO3 -m32 -xarch=sparc  -m32 -xarch=sparc -L/opt/csw/lib -o hello main.o
>>> ++ pwd
>>> + make DESTDIR=/home/dam/.../amhello-1.0/inst install
>>> Making install in src
>>> [SNIP]
>>> + cd inst
>>> + find . -type f -print
>>> ++ cat ../files.lst
>>> + tar cvf amhello-1.0-i686.tar.gz ./usr/bin/hello ./usr/share/doc/amhello/README
>>> ++ sed -n -e 's/^EXEEXT *= *//p'
>>> + EXEEXT=
>>> + tar --version
>>> + grep GNU
>>> + : Be laxer with other tar implementations, to avoid spurious failures.
>>> + /opt/csw/bin/ggrep -E '(^| )\./usr/bin/hello( |$)' tar.got
>>> + am_exit_trap 1
>>> + exit_status=1
>>
>> Could you please send us the content of these files?
>>
>>  t/amhello-binpkg.dir/amhello-1.0/files.lst
>>  t/amhello-binpkg.dir/amhello-1.0/inst/tar.got
> 
> 
> Sure, I just copied over the whole build directory, feel free to take a look:
>   http://buildfarm.opencsw.org/~dam/automake-1.12.5/
>
Thank you, this is really helpful.

Turns out this failure:
>
> FAIL: t/amhello-binpkg
>
is a spurious one, due to a tiny difference in the "tar cvf" output.  The
patch below should take care of it.  Can you confirm it does the trick?

Thanks,
  Stefano

---- 8< ---- 8< ---- 8< ---- 8< ---- 8< ---- 8< ---- 8< ---- 8< ---- 8< ----

From 993fd9f3f6ede8ef9c1cbb1fa91fa60b9ccf57d7 Mon Sep 17 00:00:00 2001
Message-Id: <993fd9f3f6ede8ef9c1cbb1fa91fa60b9ccf57d7.1353928992.git.stefano.lattarini <at> gmail.com>
From: Stefano Lattarini <stefano.lattarini <at> gmail.com>
Date: Mon, 26 Nov 2012 12:22:51 +0100
Subject: [PATCH] tests: fix a spurious testsuite failure on Solaris

Reported in automake bug#11524.

* t/amhello-binpkg.sh: When non-GNU tar is in use, relax grepping of
"tar cvf ..." output a little more.

Signed-off-by: Stefano Lattarini <stefano.lattarini <at> gmail.com>
---
 t/amhello-binpkg.sh | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/t/amhello-binpkg.sh b/t/amhello-binpkg.sh
index c1d2575..f6988ce 100755
--- a/t/amhello-binpkg.sh
+++ b/t/amhello-binpkg.sh
@@ -44,8 +44,8 @@ if tar --version </dev/null | grep GNU; then
 END
 else
   : Be laxer with other tar implementations, to avoid spurious failures.
-  $EGREP '(^| )\./usr/bin/hello'$EXEEXT'( |$)' tar.got
-  $EGREP '(^| )\./usr/share/doc/amhello/README( |$)' tar.got
+  $EGREP '(^| )(\./)?usr/bin/hello'$EXEEXT'( |$)' tar.got
+  $EGREP '(^| )(\./)?usr/share/doc/amhello/README( |$)' tar.got
 fi

 :
-- 
1.8.0.1.240.ge8a1f5a

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

From: Stefano Lattarini <stefano.lattarini <at> gmail.com>
To: Dagobert Michelsen <dam <at> opencsw.org>
Cc: 11524 <at> debbugs.gnu.org
Subject: Re: bug#11524: ping on automake bug#11524
Date: Mon, 26 Nov 2012 12:38:43 +0100

On 11/22/2012 10:42 AM, Stefano Lattarini wrote:
> On 11/21/2012 10:17 PM, Dagobert Michelsen wrote:
>>
>> I still get quite some failures:
>>   http://buildfarm.opencsw.org/~dam/automake-1.12.5-test-suite.log
> 
>> FAIL: t/depcomp-lt-cpp
>> ======================
>>
>> depcomp-lt-cpp: running libtoolize --version
>> libtoolize (GNU libtool) 2.4.2
>> [SNIP]
>> + . depcomp.sh
>> +++ pwd
>> ++ ocwd=/home/dam/.../automake-1.12.5/t/depcomp-lt-cpp.dir
>> ++ longpath=this-is/a-path/which-has/quite-a/definitely/truly/long_long_name
>> ++ cachevar=am_cv_CC_dependencies_compiler_type
>> [SNIP]
>> ++ displayed_depmode='(cached) cpp'
>> ++ cfg_deptrack=am_cv_CC_dependencies_compiler_type=cpp
>> ++ /opt/csw/bin/ggrep -F am_cv_CC_dependencies_compiler_type configure
>> if ${am_cv_CC_dependencies_compiler_type+:} false; then :
>>   am_cv_CC_dependencies_compiler_type=none
>>         am_cv_CC_dependencies_compiler_type=$depmode
>>   am_cv_CC_dependencies_compiler_type=none
>> { $as_echo "$as_me:${as_lineno-$LINENO}: result: $am_cv_CC_dependencies_compiler_type" >&5
>> $as_echo "$am_cv_CC_dependencies_compiler_type" >&6; }
>> CCDEPMODE=depmode=$am_cv_CC_dependencies_compiler_type
>>   && test "$am_cv_CC_dependencies_compiler_type" = gcc3; then
>> ++ cd_top
>> ++ cd /home/dam/.../automake-1.12.5/t/depcomp-lt-cpp.dir
>> [SNIP]
>> ++ mkdir intree
>> ++ cd intree
>> [SNIP]
>> ++ ./configure am_cv_CC_dependencies_compiler_type=cpp
>> configure: error: in `/home/dam/mgar/pkg/automake/trunk/work/solaris10-sparc/build-isa-sparcv8plus-version-1.12.5/automake-1.12.5/t/depcomp-lt-cpp.dir/intree':
>> configure: error: C compiler cannot create executables
>> See `config.log' for more details
>> ++ tap_result_='not ok'
>> ++ result_ 'not ok' -D '' -r '' -- '[in-tree build] configure'
>> ++ set +x
>> ++ cat stdout
>> checking for a BSD-compatible install... /opt/csw/bin/ginstall -c
>> checking whether build environment is sane... yes
>> checking for a thread-safe mkdir -p... /opt/csw/bin/gmkdir -p
>> checking for gawk... gawk
>> checking whether make sets $(MAKE)... yes
>> checking for gcc... gcc
>> checking whether the C compiler works... no
>> not ok 1 - [in-tree build] configure
>> FAIL: t/depcomp-lt-cpp.tap 1 - [in-tree build] configure
>>
> OK, this reeks of spurious failure.
> 
A look to:

 <http://buildfarm.opencsw.org/~dam/automake-1.12.5/t/depcomp-lt-gcc.dir/intree/config.log>

seems to confirm this:

    ...
    compilation terminated.
    configure:2949: $? = 1
    configure:2969: checking whether the C compiler works
    configure:2991: gcc  -I/opt/csw/include -m32 -xarch=sparc -L/opt/csw/lib conftest.c  >&5
    gcc: error: language arch=sparc not recognized
    gcc: error: language arch=sparc not recognized
    configure:2995: $? = 1
    configure:3033: result: no
    configure: failed program was:
    ...

And according to

 <http://buildfarm.opencsw.org/~dam/automake-1.12.5/t/get-sysconf.log>

You're passing flags specific to the Solaris C compiler in the LDFLAGS variable;
that is, the "-xarch=sparc" in:

    LDFLAGS='-m32 -xarch=sparc -L/opt/csw/lib'

Since LDFLAGS is used also by gcc, chaos ensues.

Could yo try to re-run the testsuite with a fixed environment, that is,
exporting flags specific to the Solaris compiler in CFLAGS rather than
in LDLFAGS?

Thanks,
  Stefano

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

From: Dagobert Michelsen <dam <at> opencsw.org>
To: Stefano Lattarini <stefano.lattarini <at> gmail.com>
Cc: 11524 <at> debbugs.gnu.org
Subject: Re: bug#11524: ping on automake bug#11524
Date: Mon, 26 Nov 2012 12:44:47 +0100

Hi Stefano,
Am 26.11.2012 um 12:38 schrieb Stefano Lattarini <stefano.lattarini <at> gmail.com>:

> On 11/22/2012 10:42 AM, Stefano Lattarini wrote:
>> On 11/21/2012 10:17 PM, Dagobert Michelsen wrote:
>>> 
>>> I still get quite some failures:
>>>  http://buildfarm.opencsw.org/~dam/automake-1.12.5-test-suite.log
>> 
>>> FAIL: t/depcomp-lt-cpp
>>> ======================
>>> 
>>> depcomp-lt-cpp: running libtoolize --version
>>> libtoolize (GNU libtool) 2.4.2
>>> [SNIP]
>>> + . depcomp.sh
>>> +++ pwd
>>> ++ ocwd=/home/dam/.../automake-1.12.5/t/depcomp-lt-cpp.dir
>>> ++ longpath=this-is/a-path/which-has/quite-a/definitely/truly/long_long_name
>>> ++ cachevar=am_cv_CC_dependencies_compiler_type
>>> [SNIP]
>>> ++ displayed_depmode='(cached) cpp'
>>> ++ cfg_deptrack=am_cv_CC_dependencies_compiler_type=cpp
>>> ++ /opt/csw/bin/ggrep -F am_cv_CC_dependencies_compiler_type configure
>>> if ${am_cv_CC_dependencies_compiler_type+:} false; then :
>>>  am_cv_CC_dependencies_compiler_type=none
>>>        am_cv_CC_dependencies_compiler_type=$depmode
>>>  am_cv_CC_dependencies_compiler_type=none
>>> { $as_echo "$as_me:${as_lineno-$LINENO}: result: $am_cv_CC_dependencies_compiler_type" >&5
>>> $as_echo "$am_cv_CC_dependencies_compiler_type" >&6; }
>>> CCDEPMODE=depmode=$am_cv_CC_dependencies_compiler_type
>>>  && test "$am_cv_CC_dependencies_compiler_type" = gcc3; then
>>> ++ cd_top
>>> ++ cd /home/dam/.../automake-1.12.5/t/depcomp-lt-cpp.dir
>>> [SNIP]
>>> ++ mkdir intree
>>> ++ cd intree
>>> [SNIP]
>>> ++ ./configure am_cv_CC_dependencies_compiler_type=cpp
>>> configure: error: in `/home/dam/mgar/pkg/automake/trunk/work/solaris10-sparc/build-isa-sparcv8plus-version-1.12.5/automake-1.12.5/t/depcomp-lt-cpp.dir/intree':
>>> configure: error: C compiler cannot create executables
>>> See `config.log' for more details
>>> ++ tap_result_='not ok'
>>> ++ result_ 'not ok' -D '' -r '' -- '[in-tree build] configure'
>>> ++ set +x
>>> ++ cat stdout
>>> checking for a BSD-compatible install... /opt/csw/bin/ginstall -c
>>> checking whether build environment is sane... yes
>>> checking for a thread-safe mkdir -p... /opt/csw/bin/gmkdir -p
>>> checking for gawk... gawk
>>> checking whether make sets $(MAKE)... yes
>>> checking for gcc... gcc
>>> checking whether the C compiler works... no
>>> not ok 1 - [in-tree build] configure
>>> FAIL: t/depcomp-lt-cpp.tap 1 - [in-tree build] configure
>>> 
>> OK, this reeks of spurious failure.
>> 
> A look to:
> 
> <http://buildfarm.opencsw.org/~dam/automake-1.12.5/t/depcomp-lt-gcc.dir/intree/config.log>
> 
> seems to confirm this:
> 
>    ...
>    compilation terminated.
>    configure:2949: $? = 1
>    configure:2969: checking whether the C compiler works
>    configure:2991: gcc  -I/opt/csw/include -m32 -xarch=sparc -L/opt/csw/lib conftest.c  >&5
>    gcc: error: language arch=sparc not recognized
>    gcc: error: language arch=sparc not recognized
>    configure:2995: $? = 1
>    configure:3033: result: no
>    configure: failed program was:
>    ...
> 
> And according to
> 
> <http://buildfarm.opencsw.org/~dam/automake-1.12.5/t/get-sysconf.log>
> 
> You're passing flags specific to the Solaris C compiler in the LDFLAGS variable;
> that is, the "-xarch=sparc" in:
> 
>    LDFLAGS='-m32 -xarch=sparc -L/opt/csw/lib'
> 
> Since LDFLAGS is used also by gcc, chaos ensues.

Unfortunately this is necessary most of the time as the linker on Solaris is mostly invoked from the
compiler when compiling with Sun Studio, especially for selecting 32/64. Nonetheless I can of course
take out the flags and give it a try on a package-by-package basis and disable these for automake.

> Could yo try to re-run the testsuite with a fixed environment, that is,
> exporting flags specific to the Solaris compiler in CFLAGS rather than
> in LDLFAGS?


Sure, running now.


Best regards

  -- Dago

-- 
"You don't become great by trying to be great, you become great by wanting to do something,
and then doing it so hard that you become great in the process." - xkcd #896

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

From: Dagobert Michelsen <dam <at> opencsw.org>
To: Stefano Lattarini <stefano.lattarini <at> gmail.com>
Cc: 11524 <at> debbugs.gnu.org
Subject: Re: bug#11524: ping on automake bug#11524
Date: Mon, 26 Nov 2012 20:08:53 +0100

Hi Stefano,

Am 26.11.2012 um 12:44 schrieb Dagobert Michelsen <dam <at> opencsw.org>:
> Hi Stefano,
> Am 26.11.2012 um 12:38 schrieb Stefano Lattarini <stefano.lattarini <at> gmail.com>:
> 
>> On 11/22/2012 10:42 AM, Stefano Lattarini wrote:
>>> On 11/21/2012 10:17 PM, Dagobert Michelsen wrote:
>>>> 
>>>> I still get quite some failures:
>>>> http://buildfarm.opencsw.org/~dam/automake-1.12.5-test-suite.log
>>> 
>>>> FAIL: t/depcomp-lt-cpp
>>>> ======================
>>>> 
>>>> depcomp-lt-cpp: running libtoolize --version
>>>> libtoolize (GNU libtool) 2.4.2
>>>> [SNIP]
>>>> + . depcomp.sh
>>>> +++ pwd
>>>> ++ ocwd=/home/dam/.../automake-1.12.5/t/depcomp-lt-cpp.dir
>>>> ++ longpath=this-is/a-path/which-has/quite-a/definitely/truly/long_long_name
>>>> ++ cachevar=am_cv_CC_dependencies_compiler_type
>>>> [SNIP]
>>>> ++ displayed_depmode='(cached) cpp'
>>>> ++ cfg_deptrack=am_cv_CC_dependencies_compiler_type=cpp
>>>> ++ /opt/csw/bin/ggrep -F am_cv_CC_dependencies_compiler_type configure
>>>> if ${am_cv_CC_dependencies_compiler_type+:} false; then :
>>>> am_cv_CC_dependencies_compiler_type=none
>>>>       am_cv_CC_dependencies_compiler_type=$depmode
>>>> am_cv_CC_dependencies_compiler_type=none
>>>> { $as_echo "$as_me:${as_lineno-$LINENO}: result: $am_cv_CC_dependencies_compiler_type" >&5
>>>> $as_echo "$am_cv_CC_dependencies_compiler_type" >&6; }
>>>> CCDEPMODE=depmode=$am_cv_CC_dependencies_compiler_type
>>>> && test "$am_cv_CC_dependencies_compiler_type" = gcc3; then
>>>> ++ cd_top
>>>> ++ cd /home/dam/.../automake-1.12.5/t/depcomp-lt-cpp.dir
>>>> [SNIP]
>>>> ++ mkdir intree
>>>> ++ cd intree
>>>> [SNIP]
>>>> ++ ./configure am_cv_CC_dependencies_compiler_type=cpp
>>>> configure: error: in `/home/dam/mgar/pkg/automake/trunk/work/solaris10-sparc/build-isa-sparcv8plus-version-1.12.5/automake-1.12.5/t/depcomp-lt-cpp.dir/intree':
>>>> configure: error: C compiler cannot create executables
>>>> See `config.log' for more details
>>>> ++ tap_result_='not ok'
>>>> ++ result_ 'not ok' -D '' -r '' -- '[in-tree build] configure'
>>>> ++ set +x
>>>> ++ cat stdout
>>>> checking for a BSD-compatible install... /opt/csw/bin/ginstall -c
>>>> checking whether build environment is sane... yes
>>>> checking for a thread-safe mkdir -p... /opt/csw/bin/gmkdir -p
>>>> checking for gawk... gawk
>>>> checking whether make sets $(MAKE)... yes
>>>> checking for gcc... gcc
>>>> checking whether the C compiler works... no
>>>> not ok 1 - [in-tree build] configure
>>>> FAIL: t/depcomp-lt-cpp.tap 1 - [in-tree build] configure
>>>> 
>>> OK, this reeks of spurious failure.
>>> 
>> A look to:
>> 
>> <http://buildfarm.opencsw.org/~dam/automake-1.12.5/t/depcomp-lt-gcc.dir/intree/config.log>
>> 
>> seems to confirm this:
>> 
>>   ...
>>   compilation terminated.
>>   configure:2949: $? = 1
>>   configure:2969: checking whether the C compiler works
>>   configure:2991: gcc  -I/opt/csw/include -m32 -xarch=sparc -L/opt/csw/lib conftest.c  >&5
>>   gcc: error: language arch=sparc not recognized
>>   gcc: error: language arch=sparc not recognized
>>   configure:2995: $? = 1
>>   configure:3033: result: no
>>   configure: failed program was:
>>   ...
>> 
>> And according to
>> 
>> <http://buildfarm.opencsw.org/~dam/automake-1.12.5/t/get-sysconf.log>
>> 
>> You're passing flags specific to the Solaris C compiler in the LDFLAGS variable;
>> that is, the "-xarch=sparc" in:
>> 
>>   LDFLAGS='-m32 -xarch=sparc -L/opt/csw/lib'
>> 
>> Since LDFLAGS is used also by gcc, chaos ensues.
> 
> Unfortunately this is necessary most of the time as the linker on Solaris is mostly invoked from the
> compiler when compiling with Sun Studio, especially for selecting 32/64. Nonetheless I can of course
> take out the flags and give it a try on a package-by-package basis and disable these for automake.
> 
>> Could yo try to re-run the testsuite with a fixed environment, that is,
>> exporting flags specific to the Solaris compiler in CFLAGS rather than
>> in LDLFAGS?
> 
> Sure, running now.


This looks *much* better now:
  http://buildfarm.opencsw.org/~dam/automake-1.12.5-2012-11-26/
However, what I don't understand is that I especially select Sun Studio compiler which
accepts the defined LDFLAGS. Why does automake try to test gcc stuff with the flags?
I mean, if I set the compiler to gcc and pass gcc flags it would probably also work.


Best regards

  -- Dago

-- 
"You don't become great by trying to be great, you become great by wanting to do something,
and then doing it so hard that you become great in the process." - xkcd #896

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

From: Stefano Lattarini <stefano.lattarini <at> gmail.com>
To: Dagobert Michelsen <dam <at> opencsw.org>
Cc: 11524 <at> debbugs.gnu.org
Subject: Re: bug#11524: ping on automake bug#11524
Date: Mon, 26 Nov 2012 20:35:16 +0100

On 11/26/2012 08:08 PM, Dagobert Michelsen wrote:
> Hi Stefano,
> 
>> Am 26.11.2012 um 12:38 schrieb Stefano Lattarini <stefano.lattarini <at> gmail.com>:
>>>
>>> OK, this reeks of spurious failure.
>>>
>>>   ...
>>>   compilation terminated.
>>>   configure:2949: $? = 1
>>>   configure:2969: checking whether the C compiler works
>>>   configure:2991: gcc  -I/opt/csw/include -m32 -xarch=sparc -L/opt/csw/lib conftest.c  >&5
>>>   gcc: error: language arch=sparc not recognized
>>>   gcc: error: language arch=sparc not recognized
>>>   configure:2995: $? = 1
>>>   configure:3033: result: no
>>>   configure: failed program was:
>>>   ...
>>>
>>> According to
>>>
>>> <http://buildfarm.opencsw.org/~dam/automake-1.12.5/t/get-sysconf.log>
>>>
>>> you're passing flags specific to the Solaris C compiler in the LDFLAGS variable;
>>> that is, the "-xarch=sparc" in:
>>>
>>>   LDFLAGS='-m32 -xarch=sparc -L/opt/csw/lib'
>>>
>>> Since LDFLAGS is used also by gcc, chaos ensues.
>>
>> Unfortunately this is necessary most of the time as the linker on Solaris
>> is mostly invoked from the compiler when compiling with Sun Studio, especially
>> for selecting 32/64. Nonetheless I can of course take out the flags and give
>> it a try on a package-by-package basis and disable these for automake.
>>
>>> Could yo try to re-run the testsuite with a fixed environment, that is,
>>> exporting flags specific to the Solaris compiler in CFLAGS rather than
>>> in LDLFAGS?
>>
>> Sure, running now.
> 
> 
> This looks *much* better now:
>   http://buildfarm.opencsw.org/~dam/automake-1.12.5-2012-11-26/
>
Good!

> However, what I don't understand is that I especially select Sun Studio compiler
> which accepts the defined LDFLAGS. Why does automake try to test gcc stuff with
> the flags?
>
Because some tests require the GNU compilers, and they explicitly force use
of them, even if the user have specified other compilers for the "generic"
tests (which are the majority).  So far, the testsuite has been careful not
to use the generic CFLAGS, CXXFLAGS, ... for this kind of tests (using
GNU_CFLAGS, GNU_CXXFLAGS, ... instead) but hasn't bothered to do the same
for LDFLAGS, because before your report I had never seen a failure due to
LDFLAGS being incompatible with GCC.  But maybe this is a glitch that is
worth fixing after all.  I'll think about it (so I'm not yet closing this
bug report, until a decision is make).

> I mean, if I set the compiler to gcc and pass gcc flags it would probably
> also work.
>
It should be so, yes.

Thanks, and best regards,
  Stefano

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

From: Stefano Lattarini <stefano.lattarini <at> gmail.com>
To: 11524 <at> debbugs.gnu.org
Cc: Dagobert Michelsen <dam <at> opencsw.org>, David Fang <fang <at> csl.cornell.edu>,
 Mostafa <mostafa_working_away <at> yahoo.com>, 15681 <at> debbugs.gnu.org,
 Automake List <automake <at> gnu.org>, Nicolas Joly <njoly <at> pasteur.fr>,
 16447 <at> debbugs.gnu.org, 14760 <at> debbugs.gnu.org, Thomas Jahns <jahns <at> dkrz.de>,
 14079 <at> debbugs.gnu.org
Subject: Declaring limited "bug bankruptcy" for Automake
Date: Sat, 20 Dec 2014 01:49:15 +0100

tags 11524 wontfix
tags 14079 wontfix
tags 14760 wontfix
tags 16447 wontfix
tags 15681 wontfix
close 11524
close 14079
close 14760
close 15681
close 16447
stop

Due to my lack of time to dedicate to Automake, I'm declaring
a limited bug bankruptcy on old bugs, in case they deal with
testsuite-only glitches on exotic platforms, or with minor
documentation glitches.  Apologies to the original reporters.

That said, if you have time, feel free to re-run the testsuite
on the master branch and open new bugs for any failure you
still see there.  Also make sure to add as much detail as
possible (e.g., the content of the relevant files for failed
tests, rather than just the content of the .log files
associated to the tests).

Thanks, and apologies,
  Stefano

Previous Next

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