1335302 - stylo: build-time bindgen doesn't work on mac

Status: RESOLVED FIXED

(Core :: CSS Parsing and Computation, defect, P3)

Description

[Bobby Holley (:bholley)]

Manish hit this too. We've both disabled build-time bindgen, but seems like someone should look into this. Ted or Nathan?

Comment 1

[Bobby Holley (:bholley)]

Attachment: log

failure log

Comment 2

[Xidorn Quan [:xidorn] UTC+10]

I work-around the compile errors by adding "--stdlib=libc++" and "--target=x86_64-apple-darwin" to clang_arg. This fixes the compile error, but the build script still fails for invalid memory reference...

Comment 3

[Xidorn Quan [:xidorn] UTC+10]

The callstack when the segment fail happens is:
  * frame #0: 0x0000000106513bec libclang.dylib`(anonymous namespace)::CXXNameMangler::mangleExpression(clang::Expr const*, unsigned int) + 50
    frame #1: 0x0000000106510c97 libclang.dylib`(anonymous namespace)::CXXNameMangler::mangleType(clang::QualType) + 2359
    frame #2: 0x000000010650fcda libclang.dylib`(anonymous namespace)::CXXNameMangler::mangleName(clang::NamedDecl const*) + 426
    frame #3: 0x000000010650dcc2 libclang.dylib`(anonymous namespace)::ItaniumMangleContextImpl::mangleCXXName(clang::NamedDecl const*, llvm::raw_ostream&) + 162
    frame #4: 0x0000000106637257 libclang.dylib`clang::index::CodegenNameGenerator::Implementation::writeFuncOrVarName(clang::NamedDecl const*, llvm::raw_ostream&) + 145
    frame #5: 0x000000010663693e libclang.dylib`clang::index::CodegenNameGenerator::Implementation::writeName(clang::Decl const*, llvm::raw_ostream&) + 170
    frame #6: 0x0000000106636a9f libclang.dylib`clang::index::CodegenNameGenerator::Implementation::getName(clang::Decl const*) + 105
    frame #7: 0x000000010663686d libclang.dylib`clang::index::CodegenNameGenerator::getName(clang::Decl const*) + 17
    frame #8: 0x000000010640ef4a libclang.dylib`clang_Cursor_getMangling + 170
    frame #9: 0x000000010515f4a2 build-script-build`clang_sys::clang_Cursor_getMangling(cursor=<unavailable>) + 98 at lib.rs:1374 [opt]
    frame #10: 0x0000000104f15b98 build-script-build`bindgen::clang::{{impl}}::mangling(self=<unavailable>) + 56 at clang.rs:72 [opt]
    frame #11: 0x0000000104f20707 build-script-build`bindgen::ir::function::cursor_mangling(cursor=0x00007fff5ad75438) + 55 at function.rs:101 [opt]
    frame #12: 0x0000000104f29eee build-script-build`bindgen::ir::var::{{impl}}::parse(cursor=<unavailable>, ctx=<unavailable>) + 1950 at var.rs:242 [opt]
    frame #13: 0x0000000104f2319a build-script-build`bindgen::ir::item::{{impl}}::parse(cursor=<unavailable>, parent_id=<unavailable>, ctx=0x00007fff5ad7f570) + 458 at item.rs:983 [opt]
    frame #14: 0x0000000104f541e1 build-script-build`bindgen::ir::comp::{{impl}}::from_ty::{{closure}}(cur=<unavailable>) + 2289 at comp.rs:728 [opt]
    frame #15: 0x0000000104f17601 build-script-build`bindgen::clang::visit_children<closure>(cur=<unavailable>, _parent=<unavailable>, data=<unavailable>) + 33 at clang.rs:515 [opt]
    frame #16: 0x000000010640376e libclang.dylib`clang::cxcursor::CursorVisitor::Visit(CXCursor, bool) + 364
    frame #17: 0x0000000106404e02 libclang.dylib`clang::cxcursor::CursorVisitor::handleDeclForVisitation(clang::Decl const*) + 316
    frame #18: 0x0000000106404ea3 libclang.dylib`clang::cxcursor::CursorVisitor::VisitDeclContext(clang::DeclContext*) + 107
    frame #19: 0x0000000106405784 libclang.dylib`clang::cxcursor::CursorVisitor::VisitCXXRecordDecl(clang::CXXRecordDecl*) + 188
    frame #20: 0x0000000106406400 libclang.dylib`clang::cxcursor::CursorVisitor::VisitClassTemplateDecl(clang::ClassTemplateDecl*) + 46
    frame #21: 0x000000010641b546 libclang.dylib`clang::declvisitor::Base<clang::declvisitor::make_ptr, clang::cxcursor::CursorVisitor, bool>::Visit(clang::Decl*) + 188
    frame #22: 0x0000000106403ff6 libclang.dylib`clang::cxcursor::CursorVisitor::VisitChildren(CXCursor) + 402
    frame #23: 0x000000010640d4bd libclang.dylib`clang_visitChildren + 353
    frame #24: 0x00000001051610ed build-script-build`clang_sys::clang_visitChildren(cursor=<unavailable>, visitor=<unavailable>, data=<unavailable>) + 109 at lib.rs:1374 [opt]
    frame #25: 0x0000000104f16882 build-script-build`bindgen::clang::{{impl}}::visit<closure>(self=<unavailable>, visitor=<unavailable>) + 98 at clang.rs:332 [opt]
    frame #26: 0x0000000104f1ab7d build-script-build`bindgen::ir::comp::{{impl}}::from_ty(potential_id=<unavailable>, ty=<unavailable>, location=<unavailable>, ctx=<unavailable>) + 1389 at comp.rs:532 [opt]
    frame #27: 0x0000000104f286ea build-script-build`bindgen::ir::ty::{{impl}}::from_clang_ty(potential_id=<unavailable>, ty=<unavailable>, location=<unavailable>, parent_id=<unavailable>, ctx=<unavailable>) + 6426 at ty.rs:638 [opt]
    frame #28: 0x0000000104f24d12 build-script-build`bindgen::ir::item::{{impl}}::from_ty_with_id(id=<unavailable>, ty=<unavailable>, location=<unavailable>, parent_id=<unavailable>, ctx=<unavailable>) + 1378 at item.rs:1170 [opt]
    frame #29: 0x0000000104f24797 build-script-build`bindgen::ir::item::{{impl}}::from_ty(ty=<unavailable>, location=<unavailable>, parent_id=<unavailable>, ctx=0x00007fff5ad7f570) + 119 at item.rs:1103 [opt]
    frame #30: 0x0000000104f232ab build-script-build`bindgen::ir::item::{{impl}}::parse(cursor=<unavailable>, parent_id=<unavailable>, ctx=0x00007fff5ad7f570) + 731 at item.rs:989 [opt]
    frame #31: 0x0000000104f2c129 build-script-build`bindgen::parse_one(ctx=<unavailable>, cursor=<unavailable>, parent=<unavailable>) + 153 at lib.rs:785 [opt]
    frame #32: 0x0000000104f532e0 build-script-build`bindgen::ir::module::{{impl}}::parse::{{closure}}::{{closure}}(cursor=<unavailable>) + 80 at module.rs:69 [opt]
    frame #33: 0x0000000104f17421 build-script-build`bindgen::clang::visit_children<closure>(cur=<unavailable>, _parent=<unavailable>, data=<unavailable>) + 33 at clang.rs:515 [opt]
    frame #34: 0x000000010640376e libclang.dylib`clang::cxcursor::CursorVisitor::Visit(CXCursor, bool) + 364
    frame #35: 0x0000000106404e02 libclang.dylib`clang::cxcursor::CursorVisitor::handleDeclForVisitation(clang::Decl const*) + 316
    frame #36: 0x0000000106404ea3 libclang.dylib`clang::cxcursor::CursorVisitor::VisitDeclContext(clang::DeclContext*) + 107
    frame #37: 0x000000010641b4ec libclang.dylib`clang::declvisitor::Base<clang::declvisitor::make_ptr, clang::cxcursor::CursorVisitor, bool>::Visit(clang::Decl*) + 98
    frame #38: 0x0000000106403ff6 libclang.dylib`clang::cxcursor::CursorVisitor::VisitChildren(CXCursor) + 402
    frame #39: 0x000000010640d4bd libclang.dylib`clang_visitChildren + 353
    frame #40: 0x00000001051610ed build-script-build`clang_sys::clang_visitChildren(cursor=<unavailable>, visitor=<unavailable>, data=<unavailable>) + 109 at lib.rs:1374 [opt]
    frame #41: 0x0000000104f1676a build-script-build`bindgen::clang::{{impl}}::visit<closure>(self=<unavailable>, visitor=<unavailable>) + 74 at clang.rs:332 [opt]
    frame #42: 0x0000000104f54d6b build-script-build`bindgen::ir::module::{{impl}}::parse::{{closure}}(ctx=<unavailable>) + 43 at module.rs:68 [opt]
    frame #43: 0x0000000104f1fe13 build-script-build`bindgen::ir::context::{{impl}}::with_module<closure>(self=0x00007fff5ad7f570, module_id=(__0 = 56865), cb=<unavailable>) + 83 at context.rs:1040 [opt]
    frame #44: 0x0000000104f2629e build-script-build`bindgen::ir::module::{{impl}}::parse(cursor=<unavailable>, ctx=0x00007fff5ad7f570) + 142 at module.rs:67 [opt]
    frame #45: 0x0000000104f230ca build-script-build`bindgen::ir::item::{{impl}}::parse(cursor=<unavailable>, parent_id=<unavailable>, ctx=0x00007fff5ad7f570) + 250 at item.rs:973 [opt]
    frame #46: 0x0000000104f2c129 build-script-build`bindgen::parse_one(ctx=<unavailable>, cursor=<unavailable>, parent=<unavailable>) + 153 at lib.rs:785 [opt]
    frame #47: 0x0000000104f532e0 build-script-build`bindgen::ir::module::{{impl}}::parse::{{closure}}::{{closure}}(cursor=<unavailable>) + 80 at module.rs:69 [opt]
    frame #48: 0x0000000104f17421 build-script-build`bindgen::clang::visit_children<closure>(cur=<unavailable>, _parent=<unavailable>, data=<unavailable>) + 33 at clang.rs:515 [opt]
    frame #49: 0x000000010640376e libclang.dylib`clang::cxcursor::CursorVisitor::Visit(CXCursor, bool) + 364
    frame #50: 0x0000000106404e02 libclang.dylib`clang::cxcursor::CursorVisitor::handleDeclForVisitation(clang::Decl const*) + 316
    frame #51: 0x0000000106404ea3 libclang.dylib`clang::cxcursor::CursorVisitor::VisitDeclContext(clang::DeclContext*) + 107
    frame #52: 0x000000010641b4ec libclang.dylib`clang::declvisitor::Base<clang::declvisitor::make_ptr, clang::cxcursor::CursorVisitor, bool>::Visit(clang::Decl*) + 98
    frame #53: 0x0000000106403ff6 libclang.dylib`clang::cxcursor::CursorVisitor::VisitChildren(CXCursor) + 402
    frame #54: 0x000000010640d4bd libclang.dylib`clang_visitChildren + 353
    frame #55: 0x00000001051610ed build-script-build`clang_sys::clang_visitChildren(cursor=<unavailable>, visitor=<unavailable>, data=<unavailable>) + 109 at lib.rs:1374 [opt]
    frame #56: 0x0000000104f1676a build-script-build`bindgen::clang::{{impl}}::visit<closure>(self=<unavailable>, visitor=<unavailable>) + 74 at clang.rs:332 [opt]
    frame #57: 0x0000000104f54d6b build-script-build`bindgen::ir::module::{{impl}}::parse::{{closure}}(ctx=<unavailable>) + 43 at module.rs:68 [opt]
    frame #58: 0x0000000104f1fe13 build-script-build`bindgen::ir::context::{{impl}}::with_module<closure>(self=0x00007fff5ad7f570, module_id=(__0 = 43307), cb=<unavailable>) + 83 at context.rs:1040 [opt]
    frame #59: 0x0000000104f2629e build-script-build`bindgen::ir::module::{{impl}}::parse(cursor=<unavailable>, ctx=0x00007fff5ad7f570) + 142 at module.rs:67 [opt]
    frame #60: 0x0000000104f230ca build-script-build`bindgen::ir::item::{{impl}}::parse(cursor=<unavailable>, parent_id=<unavailable>, ctx=0x00007fff5ad7f570) + 250 at item.rs:973 [opt]
    frame #61: 0x0000000104f2c129 build-script-build`bindgen::parse_one(ctx=<unavailable>, cursor=<unavailable>, parent=<unavailable>) + 153 at lib.rs:785 [opt]
    frame #62: 0x0000000104f532e0 build-script-build`bindgen::ir::module::{{impl}}::parse::{{closure}}::{{closure}}(cursor=<unavailable>) + 80 at module.rs:69 [opt]
    frame #63: 0x0000000104f17421 build-script-build`bindgen::clang::visit_children<closure>(cur=<unavailable>, _parent=<unavailable>, data=<unavailable>) + 33 at clang.rs:515 [opt]
    frame #64: 0x000000010640376e libclang.dylib`clang::cxcursor::CursorVisitor::Visit(CXCursor, bool) + 364
    frame #65: 0x0000000106404e02 libclang.dylib`clang::cxcursor::CursorVisitor::handleDeclForVisitation(clang::Decl const*) + 316
    frame #66: 0x0000000106404ea3 libclang.dylib`clang::cxcursor::CursorVisitor::VisitDeclContext(clang::DeclContext*) + 107
    frame #67: 0x000000010641b4ec libclang.dylib`clang::declvisitor::Base<clang::declvisitor::make_ptr, clang::cxcursor::CursorVisitor, bool>::Visit(clang::Decl*) + 98
    frame #68: 0x0000000106403ff6 libclang.dylib`clang::cxcursor::CursorVisitor::VisitChildren(CXCursor) + 402
    frame #69: 0x000000010640d4bd libclang.dylib`clang_visitChildren + 353
    frame #70: 0x00000001051610ed build-script-build`clang_sys::clang_visitChildren(cursor=<unavailable>, visitor=<unavailable>, data=<unavailable>) + 109 at lib.rs:1374 [opt]
    frame #71: 0x0000000104f1676a build-script-build`bindgen::clang::{{impl}}::visit<closure>(self=<unavailable>, visitor=<unavailable>) + 74 at clang.rs:332 [opt]
    frame #72: 0x0000000104f54d6b build-script-build`bindgen::ir::module::{{impl}}::parse::{{closure}}(ctx=<unavailable>) + 43 at module.rs:68 [opt]
    frame #73: 0x0000000104f1fe13 build-script-build`bindgen::ir::context::{{impl}}::with_module<closure>(self=0x00007fff5ad7f570, module_id=(__0 = 43306), cb=<unavailable>) + 83 at context.rs:1040 [opt]
    frame #74: 0x0000000104f2629e build-script-build`bindgen::ir::module::{{impl}}::parse(cursor=<unavailable>, ctx=0x00007fff5ad7f570) + 142 at module.rs:67 [opt]
    frame #75: 0x0000000104f230ca build-script-build`bindgen::ir::item::{{impl}}::parse(cursor=<unavailable>, parent_id=<unavailable>, ctx=0x00007fff5ad7f570) + 250 at item.rs:973 [opt]
    frame #76: 0x0000000104f2c129 build-script-build`bindgen::parse_one(ctx=<unavailable>, cursor=<unavailable>, parent=<unavailable>) + 153 at lib.rs:785 [opt]
    frame #77: 0x0000000104f53332 build-script-build`bindgen::parse::{{closure}}::{{closure}}(cursor=<unavailable>) + 66 at lib.rs:818 [opt]
    frame #78: 0x0000000104f17481 build-script-build`bindgen::clang::visit_children<closure>(cur=<unavailable>, _parent=<unavailable>, data=<unavailable>) + 33 at clang.rs:515 [opt]
    frame #79: 0x000000010640376e libclang.dylib`clang::cxcursor::CursorVisitor::Visit(CXCursor, bool) + 364
    frame #80: 0x0000000106404e02 libclang.dylib`clang::cxcursor::CursorVisitor::handleDeclForVisitation(clang::Decl const*) + 316
    frame #81: 0x0000000106404ea3 libclang.dylib`clang::cxcursor::CursorVisitor::VisitDeclContext(clang::DeclContext*) + 107
    frame #82: 0x0000000106404231 libclang.dylib`clang::cxcursor::CursorVisitor::VisitChildren(CXCursor) + 973
    frame #83: 0x000000010640d4bd libclang.dylib`clang_visitChildren + 353
    frame #84: 0x00000001051610ed build-script-build`clang_sys::clang_visitChildren(cursor=<unavailable>, visitor=<unavailable>, data=<unavailable>) + 109 at lib.rs:1374 [opt]
    frame #85: 0x0000000104f16caf build-script-build`bindgen::clang::{{impl}}::visit<closure>(self=<unavailable>, visitor=<unavailable>) + 63 at clang.rs:332 [opt]
    frame #86: 0x0000000104f54d35 build-script-build`bindgen::parse::{{closure}}(context=<unavailable>) + 21 at lib.rs:818 [opt]
    frame #87: 0x0000000104f1fd90 build-script-build`bindgen::ir::context::{{impl}}::with_module<closure>(self=0x00007fff5ad7f570, module_id=(__0 = 0), cb=<unavailable>) + 64 at context.rs:1040 [opt]
    frame #88: 0x0000000104f2c327 build-script-build`bindgen::parse(context=<unavailable>) + 455 at lib.rs:817 [opt]
    frame #89: 0x0000000104f2b80f build-script-build`bindgen::{{impl}}::generate(options=<unavailable>, span=<unavailable>) + 959 at lib.rs:682 [opt]
    frame #90: 0x0000000104f2afeb build-script-build`bindgen::{{impl}}::generate(self=<unavailable>) + 59 at lib.rs:431 [opt]
    frame #91: 0x0000000104e990ae build-script-build`build_script_build::build_gecko::bindings::write_binding_file::h808a234102ef1a26 + 302
    frame #92: 0x0000000104e9afb8 build-script-build`build_script_build::build_gecko::bindings::generate_structs::he970d29971a8ec2b + 7112
    frame #93: 0x0000000104e9ca6c build-script-build`build_script_build::build_gecko::generate::h8fb268a86eb6797d + 76
    frame #94: 0x00000001051a18db build-script-build`panic_unwind::__rust_maybe_catch_panic + 27 at lib.rs:97 [opt]
    frame #95: 0x00000001051a09f7 build-script-build`std::rt::lang_start [inlined] std::panicking::try<(),fn()> + 44 at panicking.rs:332 [opt]
    frame #96: 0x00000001051a09cb build-script-build`std::rt::lang_start [inlined] std::panic::catch_unwind<fn(),()> at panic.rs:351 [opt]
    frame #97: 0x00000001051a09cb build-script-build`std::rt::lang_start + 347 at rt.rs:57 [opt]
    frame #98: 0x0000000104e76a64 build-script-build`start + 52


(Mangling again? Ah, dear libclang, why do you like to crash on getting mangling name so much :/)

Comment 4

[Xidorn Quan [:xidorn] UTC+10]

Filed rust-bindgen issue for this crash: https://github.com/servo/rust-bindgen/issues/462

Comment 5

[Xidorn Quan [:xidorn] UTC+10]

The crash I mentioned in comment 3 is because of "--stdlib=libc++". libclang has a bug on parsing its own header, it seems.

Without that, it wouldn't crash. The issue here is that, bindgen gives wrong search paths, and there is no C++11 headers in that path. Supposely clang-sys invokes the system builtin clang rather than the clang installed by homebrew or else.

This can be workaround by "export CLANG_PATH=/usr/local/opt/llvm/bin/clang" before calling "./mach build".

IIRC, mach is supposed to provide CLANG_PATH environment variable to cargo build, so the question is why it doesn't work as expected. It is probably a question for Nathan, then.

Comment 6

[Xidorn Quan [:xidorn] UTC+10]

I was wrong in comment 5. It doesn't work with CLANG_PATH specified either. The clang path is correct, which indicates that CLANG_PATH from mach script does its work as expected.

It seems the path of clang is correct, the version of clang is correct, but the path it returns is wrong... I have no idea why...

Comment 7

[Xidorn Quan [:xidorn] UTC+10]

After some investigation, it eventually turns out that it is because of MACOSX_DEPLOYMENT_TARGET environment variable passed from mach. When MACOSX_DEPLOYMENT_TARGET <= 10.8, clang would return
> /usr/include/c++/4.2.1
> /usr/include/c++/4.2.1/backward
as the search path for C++, unless -stdlib=libc++ is explicitly specified. There is no C++11 headers in these directories.

If that environment variable does not present or >= 10.9, clang would return the path of its own headers, which includes everything we need.

Given that we've removed support for OS X 10.6~10.8, we can probably lift this variable to 10.9 directly, so that we would not need any special handling for bindgen.

Comment 8

[Xidorn Quan [:xidorn] UTC+10]

Nathan, WDYT?

Comment 9

[Nathan Froyd [:froydnj]]

(In reply to Xidorn Quan [:xidorn] (UTC+10) from comment #8)
> Nathan, WDYT?

Upgrading MACOSX_DEPLOYMENT_TARGET would be a fine idea, as our default is 10.7.  But that gets into issues of updating the Mac automation builders (bug 1270217), which AIUI is non-trivial.

Is there some way of injecting -stdlib=libc++ into bindgen/clang-sys instead?  That would at least match what we force in our configury.

Ted, do you remember if there were/are issues getting >=10.9 SDKs on the cross builders?

Comment 10

[(not currently active) Ted Mielczarek]

That's bug 1270217, it's blocked by the fact that our OS X build machines are still running 10.7 currently. That won't get fixed until we migrate all of our Mac builds to taskcluster (bug 1267425 etc).

Comment 11

[(not currently active) Ted Mielczarek]

bug 1324892 covers updating the SDK.

Comment 12

[Bobby Holley (:bholley)]

(In reply to Ted Mielczarek [:ted.mielczarek] from comment #10)
> That's bug 1270217, it's blocked by the fact that our OS X build machines
> are still running 10.7 currently. That won't get fixed until we migrate all
> of our Mac builds to taskcluster (bug 1267425 etc).

What's the timeframe for that? If it's likely to happen before the end of Q2 (which is our target for turning on --enable-stylo on nightly), could we just make --enable-stylo imply MACOSX_DEPLOYMENT_TARGET=10.9, which would only impact local developer builds?

Comment 13

[Nathan Froyd [:froydnj]]

(In reply to Bobby Holley (:bholley) (busy with Stylo) from comment #12)
> (In reply to Ted Mielczarek [:ted.mielczarek] from comment #10)
> > That's bug 1270217, it's blocked by the fact that our OS X build machines
> > are still running 10.7 currently. That won't get fixed until we migrate all
> > of our Mac builds to taskcluster (bug 1267425 etc).
> 
> What's the timeframe for that? If it's likely to happen before the end of Q2
> (which is our target for turning on --enable-stylo on nightly), could we
> just make --enable-stylo imply MACOSX_DEPLOYMENT_TARGET=10.9, which would
> only impact local developer builds?

Note that you can add --enable-macos-target=10.9 (or what have you) to the mozconfig if you're on mac.  This is not quite as convenient as having configure do it for you, but it is a short-term workaround.

Comment 14

[Emilio Cobos Álvarez (:emilio)]

Also what about just setting the env var during binding generation? Does that work?

Comment 15

[Bobby Holley (:bholley)]

(In reply to Nathan Froyd [:froydnj] from comment #13)
> Note that you can add --enable-macos-target=10.9 (or what have you) to the
> mozconfig if you're on mac.  This is not quite as convenient as having
> configure do it for you, but it is a short-term workaround.

This doesn't seem to fix it.

Comment 16

[Nathan Froyd [:froydnj]]

(In reply to Bobby Holley (:bholley) (busy with Stylo) from comment #15)
> (In reply to Nathan Froyd [:froydnj] from comment #13)
> > Note that you can add --enable-macos-target=10.9 (or what have you) to the
> > mozconfig if you're on mac.  This is not quite as convenient as having
> > configure do it for you, but it is a short-term workaround.
> 
> This doesn't seem to fix it.

Ah, right.  We'd probably need to set it during binding generation, as Emilio suggests in comment 14.

Comment 17

[Bobby Holley (:bholley)]

If somebody writes a patch I can test it.

Comment 18

[Nathan Froyd [:froydnj]]

Attachment: export MACOSX_DEPLOYMENT_TARGET during cargo build

This really shouldn't be necessary because of:

https://dxr.mozilla.org/mozilla-central/source/config/config.mk#378

but who knows?

Comment 19

[Xidorn Quan [:xidorn] UTC+10]

I don't think the patch would be useful... because this happens because of the presenting of this environment variable, so setting it to the same thing shouldn't have any effect.

If upgrading it to 10.9 is nontrivial, I think the next easiest thing might be setting it to empty for cargo.

Comment 20

[Xidorn Quan [:xidorn] UTC+10]

I think I have a minimum reproducible example for the bindgen crash, and I probably know where the problem is... but I don't have clear idea how to fix it. Anyway, the problem is clear now.

Comment 21

[Xidorn Quan [:xidorn] UTC+10]

I've verified that, with servo/rust-bindgen#466 applied, build-time bindgen now works on macOS with the additional line in .mozconfig:
> ac_add_options --enable-macos-target=10.9

That said, if bug 1270217 is expected to get fixed soonish, we don't need any change other than upgrading the vendored bindgen to a version with that fixed.

Comment 22

[Bobby Holley (:bholley)]

Comment on attachment 8832238 [details] [diff] [review]
export MACOSX_DEPLOYMENT_TARGET during cargo build

Thanks for sorting that out xidorn!

Nathan, see comment 12.

Comment 23

[Bobby Holley (:bholley)]

(I filed bug 1336228 for the bindgen update).

Comment 24

[Nathan Froyd [:froydnj]]

Attachment: enable proper OS X deployment target for stylo builds; r=chmanchester,f=bholley

This patch addresses problems arising from several decisions that make
sense in isolation:

* We compile Gecko with a MACOSX_DEPLOYMENT_TARGET of 10.7, largely
  because upgrading our Mac builders with a newer Xcode etc. is rather
  difficult, and our cross-compilation infrastructure isn't quite ready
  for prime time;

* Despite this, we compile Gecko with -stdlib=libc++ to enable using a
  C++11-compliant standard library;

* Given a deployment target of 10.7, clang, invoked via bindgen, opts to
  use libstdc++ as the C++ standard library;

* bindgen then has issues finding some of the C++11-era standard library
  headers that we use.  Even if it didn't, if we tried exporting
  standard library data structures across the C++/Rust boundary, we
  would be in for a world of pain later on when the inevitable
  mismatches occur.

The easiest fix for now is to force a MACOSX_DEPLOYMENT_TARGET of 10.9
when compiling with stylo (and thus using bindgen).  This change forces
bindgen-invoked clang to use the correct C++ standard library.  While
this change wouldn't be suitable for automated infrastructure
builds (see first bullet, above), we're not currently building Stylo on
or for OS X machines in automation, and we expect to have the
cross-compilation issues sorted out by the time we would care about
building Stylo for OS X in automation.  All we care about here is
unblocking local Stylo developers on OS X.

Asking for feedback from two Mac developers that I know of working on Stylo; if
anybody else wants to test it out and report back, that would be great.  The
patch doesn't seem to blow up on my local Linux box, at least.

Comment 25

[Nathan Froyd [:froydnj]]

I think the patch addresses the ni?

Comment 26

[Emilio Cobos Álvarez (:emilio)]

Isn't the bindgen crash fixed already, shouldn't -stdlib=libc++ be enough now?

Comment 27

[Nathan Froyd [:froydnj]]

(In reply to Emilio Cobos Álvarez [:emilio] from comment #26)
> Isn't the bindgen crash fixed already, shouldn't -stdlib=libc++ be enough
> now?

I guess that would be sufficient, if we can do that solely in bindgen.

Comment 28

[Bobby Holley (:bholley)]

Comment on attachment 8833998 [details] [diff] [review]
enable proper OS X deployment target for stylo builds; r=chmanchester,f=bholley

(In reply to Nathan Froyd [:froydnj] from comment #27)
> (In reply to Emilio Cobos Álvarez [:emilio] from comment #26)
> > Isn't the bindgen crash fixed already, shouldn't -stdlib=libc++ be enough
> > now?
> 
> I guess that would be sufficient, if we can do that solely in bindgen.

I thought there were multiple issues here though? It's not clear to me from xidorn's investigation whether -stdlib=libc++ is sufficient.

Passing the f? over to him for now. I'm happy to retest once incubator picks up the bindgen fix.

Comment 29

[Xidorn Quan [:xidorn] UTC+10]

If we add -stdlib=libc++, it is probably better to add --target=x86_64-apple-darwin in addition, to disable the search path fixup bindgen applies (which I want to kill, because I don't see good reason to keep that hacky thing...) otherwise there would be two sets of stdlib headers in the search path, which may lead to unpredictable issues.

Given that Gecko uses -stdlib=libc++, and this argument affects the search path, I'd slightly prefer we add this argument (with disabling the fixup in bindgen via adding --target or something) to keep thing sync with Gecko's config, even though using higher version of macosx target also fixes this issue.

Comment 30

[Xidorn Quan [:xidorn] UTC+10]

Comment on attachment 8833998 [details] [diff] [review]
enable proper OS X deployment target for stylo builds; r=chmanchester,f=bholley

Review of attachment 8833998 [details] [diff] [review]:
-----------------------------------------------------------------

As I mentioned in comment 29, I think it is probably better to add clang args to build_gecko.rs to keep it more sync with Gecko's config, so probably no Gecko side change is necessary.

Comment 31

[Xidorn Quan [:xidorn] UTC+10]

Submitted https://github.com/servo/servo/pull/15414 for change in Servo side.

Comment 32

[Chris Peterson [:cpeterson]]

Xidorn, is any more work needed to fix build-time bindgen on Mac in mozilla-central?

Comment 33

[Xidorn Quan [:xidorn] UTC+10]

I don't think there is anything else need for build-time bindgen to work on Mac. We can close this bug as FIXED.

Feel free to reopen if anyone still fail to build with build-time bindgen on Mac.