1299919 - Debug linux static analysis builds are finding the wrong preprocessor

Status: RESOLVED FIXED

(Firefox Build System :: General, defect)

Description

[Chris Manchester (limited bugmail, email directly)]

From the log:

11:00:59     INFO -  checking how to run the C preprocessor... /lib/cpp
11:01:00     INFO -  checking how to run the C++ preprocessor... /lib/cpp

From the config.log from that build:

configure:3051: checking how to run the C preprocessor
configure:3072: /usr/local/bin/python2.7 /builds/slave/try-l64-st-an-d-00000000000000/build/src/sccache/sccache.py /builds/slave/try-l64-st-an-d-00000000000000/build/src/clang/bin/clang -std=gnu99 -E  conftest.c >/dev/null 2>conftest.out
/builds/slave/try-l64-st-an-d-00000000000000/build/src/clang/bin/clang: /lib64/libz.so.1: no version information available (required by /builds/slave/try-l64-st-an-d-00000000000000/build/src/clang/bin/clang)
/builds/slave/try-l64-st-an-d-00000000000000/build/src/clang/bin/clang-3.8: /lib64/libz.so.1: no version information available (required by /builds/slave/try-l64-st-an-d-00000000000000/build/src/clang/bin/clang-3.8)
configure: failed program was:
#line 3066 "configure"
#include "confdefs.h"
#include <assert.h>
Syntax Error


It looks like AC_TRY_CPP will interpret stray output to stderr as a failure, so maybe the "/lib64/libz.so.1: no version information available" message is causing this.

Comment 1

[Chris Manchester (limited bugmail, email directly)]

glandium, any idea what's causing this? It looks like it's only happening on buildbot builds.

Comment 2

[Mike Hommey [:glandium]]

Our compilers are built on taskcluster. Taskcluster images use a slightly more recent version of centos 6 than buildbot. One of the differences it has is that zlib now has version information for symbols. So our compilers are built with knowledge of version information from the newer centos 6 in taskcluster, but run on a system that doesn't have those version information. That makes ld.so emit that warning, but still allow things to work. So, in practice, the warning is benign, but can have side effects on things looking at stderr.

An easy way out, here, is to upgrade the zlib package on the buildbot slaves. Another is to move the preprocessor check to python configure, and make it not check stderr, which is kind of a bad thing to do anyways. (and in fact, come to think of it, considering the set of compilers we support, we shouldn't even actually test it... in fact, we're already relying on $CC -E working for the compiler tests anyways)

Comment 3

[Mike Hommey [:glandium]]

Attachment: Bug 1299919 - Set CPP/CXXCPP from python configure.

Review commit: https://reviewboard.mozilla.org/r/76830/diff/#index_header
See other reviews: https://reviewboard.mozilla.org/r/76830/

Comment 4

[Mike Hommey [:glandium]]

Comment on attachment 8788280 [details]
Bug 1299919 - Set CPP/CXXCPP from python configure.

Review request updated; see interdiff: https://reviewboard.mozilla.org/r/76830/diff/1-2/

Comment 5

[Chris Manchester (limited bugmail, email directly)]

Comment on attachment 8788280 [details]
Bug 1299919 - Set CPP/CXXCPP from python configure.

https://reviewboard.mozilla.org/r/76830/#review76702

This seems like the right fix, thank you for patching this.

::: build/moz.configure/toolchain.configure:758
(Diff revision 2)
> +    # Set CPP/CXXCPP for both the build system and old-configure. We don't
> +    # to check this works for preprocessing, because we already relied on

Should be "We don't _need_ to check..."

Comment 6

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/mozilla-inbound/rev/aa63a2a40325
Set CPP/CXXCPP from python configure. r=chmanchester

Comment 7

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/mozilla-central/rev/aa63a2a40325