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.
5 participants
On FreeBSD machines without GCC installed, the configure script will now fall back to using clang.