cmake fails TryCompile test on precise/armel due to incorrect gcc option parsing

Bug #887377 reported by Colin Watson on 2011-11-07
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
gcc
New
Medium
cmake (Ubuntu)
High
Colin Watson
gcc-4.6 (Ubuntu)
Medium
Unassigned

Bug Description

https://launchpadlibrarian.net/84642263/buildlog_ubuntu-precise-armel.cmake_2.8.5-1ubuntu2_FAILEDTOBUILD.txt.gz

Here's the relevant build output:

 25/193 Test #25: TryCompile ..................................***Failed 15.44 sec
Internal cmake changing into directory: /build/buildd/cmake-2.8.5/Build/Tests/TryCompile
Error: cmake execution failed
The C compiler identification is GNU
The CXX compiler identification is GNU
Check for working C compiler: /usr/bin/gcc
Configuring
Check for working C compiler: /usr/bin/gcc -- works
Detecting C compiler ABI info
Configuring
Detecting C compiler ABI info - done
Check for working CXX compiler: /usr/bin/c++
Configuring
Check for working CXX compiler: /usr/bin/c++ -- works
Detecting CXX compiler ABI info
Configuring
Detecting CXX compiler ABI info - done
Configuring
Configuring
Configuring
Configuring
All Tests passed, ignore all previous output.
Configuring
Compiler supports ansi for
Configuring
Compiler supports ansi for
use the module now
Compiler supports ansi for
Testing try_compile project mode
Configuring
Configuring
Configuring
Configuring
Performing Test C_BUILD_SHOULD_FAIL
Configuring
Performing Test C_BUILD_SHOULD_FAIL - Failed
Performing Test C_BUILD_SHOULD_WORK
Configuring
Performing Test C_BUILD_SHOULD_WORK - Success
Performing Test C_RUN_SHOULD_FAIL
Configuring
Performing Test C_RUN_SHOULD_FAIL - Failed
Performing Test C_RUN_SHOULD_WORK
Configuring
Performing Test C_RUN_SHOULD_WORK - Success
Performing Test CXX_BUILD_SHOULD_FAIL
Configuring
Performing Test CXX_BUILD_SHOULD_FAIL - Failed
Performing Test CXX_BUILD_SHOULD_WORK
Configuring
Performing Test CXX_BUILD_SHOULD_WORK - Success
Performing Test CXX_RUN_SHOULD_FAIL
Configuring
Performing Test CXX_RUN_SHOULD_FAIL - Failed
Performing Test CXX_RUN_SHOULD_WORK
Configuring
Performing Test CXX_RUN_SHOULD_WORK - Success
Performing Test C_BOGUS_FLAG
Configuring
Performing Test C_BOGUS_FLAG - Success
CMake Error at CMakeLists.txt:12 (MESSAGE):
  Failing test succeeded:CHECK_C_COMPILER_FLAG() succeeded, but should have
  failed
Call Stack (most recent call first):
  CMakeLists.txt:223 (TEST_FAIL)

Performing Test CXX_BOGUS_FLAG
Configuring
Performing Test CXX_BOGUS_FLAG - Success
CMake Error at CMakeLists.txt:12 (MESSAGE):
  Failing test succeeded:CHECK_CXX_COMPILER_FLAG() succeeded, but should have
  failed
Call Stack (most recent call first):
  CMakeLists.txt:228 (TEST_FAIL)

Performing Test C_STRICT_PROTOTYPES
Configuring
Performing Test C_STRICT_PROTOTYPES - Success
Configuring
Checking prototype remove for TEST_REMOVE_PROTO - True
Configuring
Configuring incomplete, errors occurred!

I've distilled this down to the following test case:

  $ gcc ---
  gcc: fatal error: no input files
  compilation terminated.

The correct output, on an i386 system with the same version of gcc-4.6 (4.6.2-2ubuntu1), is:

  $ gcc ---
  gcc: error: unrecognized option ‘---’
  gcc: fatal error: no input files
  compilation terminated.

So this is a GCC bug. I haven't tracked it down further than that yet.

Related branches

Colin Watson (cjwatson) wrote :

Oh, it's also worth mentioning that version 4.6.1-9ubuntu3 in oneiric works fine.

Colin Watson (cjwatson) wrote :

This spec line appears to validate all switches:

 %{mcpu=generic-*:-march=%*; :%{mcpu=*:-mcpu=%*} %{march=*:-march=%*}}

This is a reduced test case from a cmake test failure manifesting on Ubuntu ARM (https://bugs.launchpad.net/bugs/887377):

$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/i686-linux-gnu/4.6/lto-wrapper
Target: i686-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro 4.6.2-2ubuntu1' --with-bugurl=file:///usr/share/doc/gcc-4.6/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++,go --prefix=/usr --program-suffix=-4.6 --enable-shared --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.6 --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-plugin --enable-objc-gc --enable-targets=all --disable-werror --with-arch-32=i686 --with-tune=generic --enable-checking=release --build=i686-linux-gnu --host=i686-linux-gnu --target=i686-linux-gnu
Thread model: posix
gcc version 4.6.2 (Ubuntu/Linaro 4.6.2-2ubuntu1)
$ cat specs
*asm_cpu_spec:
 %{mcpu=generic-*:-march=%*; :%{mcpu=*:-mcpu=%*} %{march=*:-march=%*}}
$ gcc -specs=specs ---
gcc: fatal error: no input files
compilation terminated.
$ gcc ---
gcc: error: unrecognized option ‘---’
gcc: fatal error: no input files
compilation terminated.

cmake (which I'm not responsible for; I'm just trying to build it) has a facility to try to work out whether compiler options are valid, and apparently looks for "unrecognized option" on stderr. I'm not exactly a fan of matching human-readable error output like this, but this spec line currently has the side-effect of validating all switches, and I don't think that can possibly be its intent.

This spec line was added in this commit:

  http://gcc.gnu.org/viewcvs?view=revision&revision=178731

I think the `validate_switches' function should only mark matching switches as valid if `len' is non-zero.

Looking more closely, I wonder if the problem here is that `starred' isn't getting reset. This construction is effectively a switch statement, isn't it? I can't see why the presence of an `mcpu=generic-*` case ought to imply that the default case should be treated as starred. Perhaps `starred' should be reset upon encountering a ';' character?

Note that in 4.7 all options will be validated by the .opt machinery
(producing "gcc: error: unrecognized command line option '---'") by the
driver and only options passing that (and -Wno-* options) will then go
through the specs validation as well. This may break things depending on
the exact error message; it may also make this bug less significant
because fewer cases will be left to be caught by the check against specs.

Colin Watson (cjwatson) wrote :

We'll need to work around this in cmake.

Changed in cmake (Ubuntu):
assignee: nobody → Colin Watson (cjwatson)
importance: Undecided → High
status: New → Triaged
tags: added: ftbfs
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package cmake - 2.8.5-1ubuntu3

---------------
cmake (2.8.5-1ubuntu3) precise; urgency=low

  * Mark compiler flag tests as expected failures. These currently fail on
    ARM due to a compiler driver bug. Now that that bug has been analysed
    and reported, we aren't gaining anything by failing to build cmake since
    previous versions of cmake failed in exactly the same way, so let's
    ignore these failures for now (LP: #887377).
 -- Colin Watson <email address hidden> Wed, 09 Nov 2011 15:06:05 +0000

Changed in cmake (Ubuntu):
status: Triaged → Fix Released
Changed in gcc:
importance: Unknown → Medium
status: Unknown → New
Matthias Klose (doko) on 2012-02-23
Changed in gcc-4.6 (Ubuntu):
importance: Undecided → Medium
status: New → Confirmed

Created attachment 27259
Reset starred flag patch.

This patch seems to solve this problem. It has been tested on 4.6.3 (Linaro release) for ARM and showed no regressions.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.