allowing fallback to clang on freebsd when needed #26185
Conversation
|
r? @brson (rust_highfive has picked a reviewer for you, use r? to override) |
|
This fixes #26183. |
|
I'm confused. My test machine doesn't have GCC installed, and the build passes for me with my original change. I thought the configure script already used clang when available, but didn't look at the mechanism since it worked for me. |
|
That being said, I don't think doing something FreeBSD-specific for this is appropriate: if a system doesn't have gcc, configure should try using clang, regardless of the host OS. |
|
@wca No, it doesn't. See here: http://buildbot.rust-lang.org/builders/auto-bsd-64-opt/builds/5214/steps/configure/logs/stdio The buildbot has been failing since your commit on June 3rd. I ran into this because I'm investigating the Bitrig build break caused by the recent __morestack cleanup. So I wanted to build on FreeBSD to see if it is broken there too but the configure step wouldn't finish, so I fixed it 👍 |
|
@wca you're right about trying clang if gcc doesn't exist, but currently the only way to get clang is through forcing it. I suppose after the os-specific blocks, I could add a general test for gcc and enable forcing clang if clang exists. |
|
Yes, that would be better. It follows the spirit of the error log from the buildbot: "either clang or gcc is required", too. |
|
I can't think of any specific reason we've never done that general fallback to clang, but I do worry that if we did we could end up using clang in 'unsupported' configurations, since e.g. people rarely build with clang on Linux. @alexcrichton Do you have opinions about whether the build should automatically fall back from gcc to clang on all platforms? |
|
I just changed the PR to be a generic fallback to clang if gcc is unavailable. It seems to work on my FreeBSD box that only has clang. |
|
@wca BTW, the __morestack cleanup broke the FreeBSD build too. I'll fix it with OpenBSD and Bitrig. |
|
@bors r+ Well after this patch I've read through a bunch of the build system code for detecting and invoking C compilers and I'm totally mortified. What a mess :( I can't tell if this change actually changes all invocations of the C compiler or not. It looks to me like it only changes how we build LLVM and on most platforms we just invoke |
|
📌 Commit e3747d1 has been approved by |
|
@brson Unfortunately, that kind of issue isn't all that uncommon. I submitted a pull request a few weeks ago for a servo crate build that had 'gcc' hardcoded as the C compiler command. I would think Cargo would handle & offer a library for invoking C and C++ compilers for crates. The usual environment variables (CC, CXX, CFLAGS, CXXFLAGS, LDFLAGS, and so forth) are a good mechanism for build-time configuration when an user wants something other than the auto-detected defaults. |
|
⌛ Testing commit e3747d1 with merge e32cce5... |
|
💔 Test failed - auto-linux-32-opt |
|
What kind of gcc doesn't like --version? |
|
hrm...let me see if I can devise a better test for gcc. |
|
@bors: retry |
|
@bors r+ |
|
📌 Commit 44d487d has been approved by |
On FreeBSD machines without GCC installed, the configure script will now fall back to using clang.
On FreeBSD machines without GCC installed, the configure script will now fall back to using clang.