Closed Bug 1299919 Opened 5 years ago Closed 5 years ago
Debug linux static analysis builds are finding the wrong preprocessor
58 bytes, text/x-review-board-request
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.
glandium, any idea what's causing this? It looks like it's only happening on buildbot builds.
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 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..."
Attachment #8788280 - Flags: review?(cmanchester) → review+
Pushed by email@example.com: https://hg.mozilla.org/integration/mozilla-inbound/rev/aa63a2a40325 Set CPP/CXXCPP from python configure. r=chmanchester
You need to log in before you can comment on or make changes to this bug.