Closed Bug 1526497 Opened 5 years ago Closed 5 years ago

Build errors during style crate compilation, with errors about features that are C++11 extensions

Categories

(Firefox Build System :: General, defect)

Product:
Firefox Build System
Component:
General
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(firefox67 fixed)

Status:
RESOLVED FIXED
Milestone:
mozilla67
Tracking Flags:
Tracking Status
firefox67 --- fixed

People

(Reporter: dholbert, Assigned: glandium)

References

Details

Attachments

(2 files)

log of a build with the error (and no sccache / ccache / icecc)
299.62 KB, text/plain
Details
Bug 1526497 - Always get clang information for bindgen.
47 bytes, text/x-phabricator-request
Details | Review

In my mozilla-inbound clone, starting today, I'm getting build failures when building the style crate (I think), with build errors like this:

$OBJ/dist/include/mozilla/fallible.h:56:20: warning: alias declarations are a C++11 extension [-Wc++11-extensions]
$OBJ/dist/include/mozilla/TypeTraits.h:50:10: error: unknown type name 'constexpr'
$OBJ/dist/include/mozilla/TypeTraits.h:50:21: error: expected ';' at end of declaration list
$OBJ/dist/include/mozilla/TypeTraits.h:51:11: error: unknown type name 'T'
$OBJ/dist/include/mozilla/TypeTraits.h:116:25: error: use of undeclared identifier 'char16_t'
$OBJ/dist/include/mozilla/TypeTraits.h:118:25: error: use of undeclared identifier 'char32_t'
$OBJ/dist/include/mozilla/TypeTraits.h:192:36: warning: variadic templates are a C++11 extension [-Wc++11-extensions]
$OBJ/dist/include/mozilla/TypeTraits.h:272:27: warning: rvalue references are a C++11 extension [-Wc++11-extensions]

I'm suspicious that this is us passing the wrong --std flag during compilation, or something like that.

I build with ccache, icecc, and sccache, so it's possible that one of those are a required component for triggering the issue (not sure yet). I'll post more as I've isolated the problem.

Right now I'm suspicious that bug 1524467 may've introduced this. I'm narrowing the guilty range using hg bisect, and I'm currently at this guilty-range:
https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=7e9ceabc7541&tochange=0ae4d42ca65b

Yeah, targeted builds seem to indicate that this issue starts with this cset (part 2 of bug 1524467):

https://hg.mozilla.org/integration/mozilla-inbound/rev/ead57b4507ac

A checkout updated to that commit (ead57b4507ac) hits this bustage, whereas one updated to the previous commit (649fc91aa4d3) completes successfully. I'm using clobber builds in both cases.

My mozconfig:

mk_add_options MOZ_OBJDIR=@TOPSRCDIR@/../obj
mk_add_options AUTOCLOBBER=1
ac_add_options --enable-linker=lld

ac_add_options --enable-debug --disable-optimize
ac_add_options --with-ccache
mk_add_options 'export CCACHE_PREFIX=icecc'
mk_add_options MOZ_MAKE_FLAGS="-j120"

What compiler version is this?

I've reproduced this on two different machines -- one with
clang version 9.0.0 (trunk 353426)
...the other with:
clang version 8.0.0 (trunk 348848)

(both recent-ish clang SVN versions, built locally from source)

Just to be clear, since you're using icecc and I'm assuming that you don't have a 120-core machine under your desk, are those clang versions the clang that bindgen is picking up for its bit of compilation? I guess icecc shouldn't come into play with bindgen issues, but...

(In reply to Nathan Froyd [:froydnj] from comment #5)

Just to be clear, since you're using icecc and I'm assuming that you don't have a 120-core machine under your desk, are those clang versions the clang that bindgen is picking up for its bit of compilation?

I don't know for sure, but I assume so. Unless bindgen uses the "./mach bootstrap --no-system-changes" provided clang... not sure.

(Correct, I don't have a 120-core machine. :) However, icecc does distribute the toolchain itself -- so regardless of whether the bindgen compilation happens locally or over icecc, it should be using the clang version that I referenced above. I have this clang version symlinked at /usr/bin/clang and clang++, so it's what gets invoked when you simply type "clang" or "clang++", and it's what icecc distributes to build nodes for my build job.)

The icecc stuff appears to be beside the point, though, because I just built without icecc/sccache/ccache, and I still hit the error. In other words, I commented out the last 3 lines of my mozconfig from comment 2, and I unset RUSTC_WRAPPER and commented out the line in my .bash_aliases file that normally sets it to sccache. And I still hit the issue.

I get the same error after adjusting my /usr/bin/clang & clang++ symlinks to point at Ubuntu "official" clang-7 binaries, too.

(and with no icecc/ccache/sccache involved)

This clang version reports itself as clang version 7.0.0-3 (tags/RELEASE_700/final) (when I ask for its --version)

What's the value of MOZ_LIBCLANG_PATH in objdir/config.status?

FWIW, I just built successfully after adjusting my /usr/bin/clang & clang++ symlinks to point at Ubuntu "official" clang-4 binaries -- clang version 4.0.1-10build1 (tags/RELEASE_401/final).

In that working build, config.status has 'MOZ_LIBCLANG_PATH': b'/usr/lib/llvm-4.0/lib'.

In a broken build on another machine (with clang-8), MOZ_LIBCLANG_PATH is actually also that same path, /usr/lib/llvm-4.0/lib'.

Here's a log of a build with the error, with no ccache/icecc/sccache, using a locally-built clang-8 version.

This is a build of revision https://hg.mozilla.org/integration/mozilla-inbound/rev/6370b90702b7

So the problem is the use of different versions of clang and libclang.

I guess. I think that's the build system's fault? (unless there's a system setting somewhere that I should be setting to tell us what version of libclang to use?)

Two additional facts:

  • my /usr/lib directory also has a "llvm-7" folder in it, alongside llvm-4.0. So I have multiple ubuntu-provided versions of libclang, but we seem to be using the older one.

  • My objdir config.status file also has this line:

'MOZ_CLANG_PATH': '/usr/lib/llvm-4.0/bin/clang',
...regardless of what version I'm using for my /usr/bin/clang symlink. I don't know if we use that MOZ_CLANG_PATH binary anywhere, though.

You can set --with-libclang-path and --with-clang-path manually. Configure should do a better job at picking clang for bindgen.

Assignee: nobody → mh+mozilla

Thanks! Trying that now.

(In the meantime, I think anyone who has e.g. clang 4 and clang 7 installed alongside each other may run into this, if they're building with clang 7 and aren't aware of those mozconfig options.)

(following up: yeah, with appropriate values for the mozconfig options in comment 13, I'm able to work around this. Hooray! Thanks.)

Blocks: 1526857

When the build system compiler is clang, and bindgen autodetection
actually finds a different clang via llvm-config, or a different clang
was given with --with-clang-path, we do want the proper flags to be
used for that clang, so we always get the right flags for that clang
instead of trying to shortcut.

Bug 1526857 will take care of making things more proper, while this is a
quick fix to unbreak builds in some unfortunately common kind of local
setups.

Pushed by mh@glandium.org:
https://hg.mozilla.org/integration/autoland/rev/2185356fb2af
Always get clang information for bindgen. r=ted
Pushed by ncsoregi@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/944a5d9d7f54
Manually set clang/libclang path for mingwclang builds. r=me CLOSED TREE
Blocks: 1524467

https://hg.mozilla.org/mozilla-central/rev/2185356fb2af
https://hg.mozilla.org/mozilla-central/rev/944a5d9d7f54

Status: NEW → RESOLVED
Closed: 5 years ago
status-firefox67: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla67
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: