Closed Bug 1495610 Opened Last year Closed 8 months ago

Unable to compile Mac shell


(Core :: Javascript: WebAssembly, defect, blocker)

Not set



Tracking Status
firefox64 --- fixed


(Reporter: gkw, Assigned: bbouvier)


(Blocks 1 open bug)



(2 files)

Attached file log
I noticed macOS shell builds starting failing on m-c rev 856103837d4d and then did a bisection.

(compile with --enable-debug --enable-more-deterministic and tested on macOS 10.13, will test on 10.14 later)

autobisectjs shows this is probably related to the following changeset:

The first bad revision is:
user:        Benjamin Bouvier
date:        Tue Sep 25 19:05:08 2018 +0200
summary:     Bug 1490948: Compile Cranelift on Nightlies except for Win32 static analysis builds; r=chmanchester

Benjamin/Chris, is bug 1490948 a likely regressor?


$ clang --version
Apple LLVM version 9.1.0 (clang-902.0.39.2)
Target: x86_64-apple-darwin17.7.0
Thread model: posix
InstalledDir: /Applications/

$ sw_vers 
ProductName:    Mac OS X
ProductVersion: 10.13.6
BuildVersion:   17G65
Flags: needinfo?(cmanchester)
Flags: needinfo?(bbouvier)
$ rustc --version
rustc 1.29.1 (b801ae664 2018-09-20)
Probably related to bug 1469027?

Well, after a whole bunch of upgrading to 10.14, Xcode 10, and getting LLVM 7.0 on, I can now compile successfully. I'm not sure which one is the hard requirement.

I'm going to recheck, clearing needinfo?s for now.
Flags: needinfo?(cmanchester)
Flags: needinfo?(bbouvier)
> getting LLVM 7.0 on

(via Homebrew)
Oh no, perhaps I made a mistake. It isn't compiling and now I'm confused. My configure command is:

'CC="clang "' 'CXX="clang++ "' 'AUTOCONF=/usr/local/Cellar/autoconf213/2.13/bin/autoconf213' 'AR=ar' 'sh' './configure' '--target=x86_64-apple-darwin15.6.0' '--disable-xcode-checks' '--disable-jemalloc' '--enable-debug' '--enable-more-deterministic' '--with-ccache' '--enable-gczeal' '--enable-debug-symbols' '--disable-tests'
Flags: needinfo?(bbouvier)
I'm going to take a look right now, thanks for the report!
In the meanwhile, you can disable cranelift with --disable-cranelift (on the configure line) and it should allow you to compile again.
Flags: needinfo?(bbouvier)
See Also: → 1495669
Attached patch fix.patchSplinter Review
Gary, does this patch fix the MacOS build for you?
Assignee: nobody → bbouvier
Attachment #9013573 - Flags: review?(nfroyd)
Attachment #9013573 - Flags: feedback?(nth10sd)
Attachment #9013573 - Flags: review?(nfroyd) → review+
Comment on attachment 9013573 [details] [diff] [review]

I think not:

   Compiling env_logger v0.5.6
   Compiling failure v0.1.2
   Compiling baldrdash v0.1.0 (file:///Users/fuzz6/trees/mozilla-central/js/src/wasm/cranelift)
error: failed to run custom build command for `baldrdash v0.1.0 (file:///Users/fuzz6/trees/mozilla-central/js/src/wasm/cranelift)`
process didn't exit successfully: `/Users/fuzz6/shell-cache/js-dbg-64-dm-clang-darwin-1495610-c6_diff-dc442e733db1-7cda6e1eb528/objdir-js/js/src/rust/debug/build/baldrdash-e7fa88dc438eb2d9/build-script-build` (exit code: 101)
--- stdout

--- stderr
/usr/local/Cellar/llvm/7.0.0/lib/clang/7.0.0/include/inttypes.h:30:15: fatal error: 'inttypes.h' file not found
/usr/local/Cellar/llvm/7.0.0/lib/clang/7.0.0/include/inttypes.h:30:15: fatal error: 'inttypes.h' file not found, err: true
thread 'main' panicked at 'Unable to generate baldrapi.h bindings: ()', libcore/
stack backtrace:
   0:        0x10bc9e30f - std::sys::unix::backtrace::tracing::imp::unwind_backtrace::h8f55de8450e228eb
                               at libstd/sys/unix/backtrace/tracing/
   1:        0x10bc8dbfa - std::sys_common::backtrace::print::hba2509af7942751e
                               at libstd/sys_common/
                               at libstd/sys_common/
   2:        0x10bca3043 - std::panicking::default_hook::{{closure}}::h4acff16463eacf92
                               at libstd/
   3:        0x10bca2dcc - std::panicking::default_hook::h6c30345eb076443e
                               at libstd/
   4:        0x10bca3737 - <std::panicking::begin_panic::PanicPayload<A> as core::panic::BoxMeUp>::get::h9b8965cb3b79231e
                               at libstd/
   5:        0x10bca32dc - std::panicking::continue_panic_fmt::ha430a2f10a3dda0e
                               at libstd/
   6:        0x10bca31c8 - std::panicking::try::do_call::h075d1fe7e0e0cdba
                               at libstd/
   7:        0x10bce4c71 - core::ptr::drop_in_place::h021858e9b22839b9
                               at libcore/
   8:        0x10ba2fd17 - core::result::unwrap_failed::h4e09a1dee565328d
                               at /Users/travis/build/rust-lang/rust/src/libcore/
   9:        0x10ba3222b - <core::result::Result<T, E>>::expect::h34772cd531a69b47
                               at /Users/travis/build/rust-lang/rust/src/libcore/
  10:        0x10ba34063 - build_script_build::main::h1ceb2912d8e465bc
                               at js/src/wasm/cranelift/
  11:        0x10ba34755 - std::rt::lang_start::{{closure}}::h620df08abbbf324d
                               at /Users/travis/build/rust-lang/rust/src/libstd/
Attachment #9013573 - Flags: feedback?(nth10sd) → feedback-
This is, please run `xcode-select --install`.
(In reply to Nathan Froyd [:froydnj] from comment #8)
> This is, please run
> `xcode-select --install`.

Thanks, Nathan. You're right, that's bug 1487552, but I had already run `xcode-select --install`.

I had to manually run the package at /Library/Developer/CommandLineTools/Packages/macOS_SDK_headers_for_macOS_10.14 to get things to compile.

Benjamin, once I've done this, the compilation works with or without your patch. I'm not sure what's next, fwiw it could be resolved as a dupe of that one? Or invalid? Sorry for the confusion once again.
Flags: needinfo?(bbouvier)
Yeah, I don't think it'll hurt, and it might help another bug that looked like a duplicate. Anyways, this is making the flags more consistent with what we're using for Servo, so I'll try to land it.
Flags: needinfo?(bbouvier)
Pushed by
Add bindgen arguments to build Cranelift on MacOS X; r=froydnj
Closed: Last year
Resolution: --- → FIXED
Target Milestone: --- → mozilla64
It happens to me as well. I have called `xcode-select --install`, but I still need to run the package at /Library/Developer/CommandLineTools/Packages/macOS_SDK_headers_for_macOS_10.14 manually to make the compilation work.
(In reply to Daosheng Mu[:daoshengmu] from comment #13)
> It happens to me as well. I have called `xcode-select --install`, but I
> still need to run the package at
> /Library/Developer/CommandLineTools/Packages/macOS_SDK_headers_for_macOS_10.
> 14 manually to make the compilation work.

I had the same problem after upgrading to macOS Mojave and this solved it for me too.
I ran into this issue as well, and it took me a long time to find this thread.

It'd be wonderful if the error message included either a link to this thread, or a comment saying to run that package. Perhaps:

.expect("Unable to generate baldrapi.h bindings. If you are on MacOS, make sure to run `xcode-select --install` and install `/Library/Developer/CommandLineTools/Packages/macOS_SDK_headers_for_macOS_*.pkg`");

(or maybe match on the result, and on Err do platform detection, and only panic with the relevant message when on macos)
Or, like, have the bootstrap script do it (I just ran into the exact same problem).
I also ran into this exact same problem. Ashley's solution to run `xcode-select --install` and installing the `macOS_SDK_headers_for_macOS_*.pkg` was the solution to my problem. I too think this should be provided to the user as a solution to this problem or be done automatically by bootstrap.

I am new to Bugzilla, for running the package at /Library/Developer/CommandLineTools/Packages/macOS_SDK_headers_for_macOS_10.14.
Could you guys give me some hint about the command, or it just is open run the package at /Library/Developer/CommandLineTools/Packages/macOS_SDK_headers_for_macOS_10.14

This problem seems to appear for me every time Xcode is updated, so I'm making the bug title easier to find, based on the error message.

Summary: Unable to compile Mac shell → Unable to compile Mac shell AKA 'inttypes.h' file not found

This is not fixed. Happened to me today.

Resolution: FIXED → ---

Even though this bug included a patch, it didn't fix the issue, which is presented in bug 1487552. Duplicating to make it clear that this bug isn't the right place for this discussion, bug 1487552 is.

Closed: Last year8 months ago
Resolution: --- → DUPLICATE
Summary: Unable to compile Mac shell AKA 'inttypes.h' file not found → Unable to compile Mac shell
Duplicate of bug: 1487552
You need to log in before you can comment on or make changes to this bug.