Subject: bug#11524: ping on automake bug#11524

From: Dagobert Michelsen <[email-masked]>
Date: Mon, 26 Nov 2012 12:44:47 +0100

Hi Stefano,
Am 26.11.2012 um 12:38 schrieb Stefano Lattarini <[email-masked]>:

> 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