Closed LunarLambda closed 5 years ago
Can you build a checkout of LLVM following their instructions on your system? If not this is probably an upstream bug we can't do much about...
I did successfully* build a checkout of LLVM on my system
cd ~/projects
git clone --depth 1 https://github.com/llvm/llvm-project llvm
cd llvm/llvm
mkdir build
cd build
cmake ..
cmake --build . -j4
*: This ended up taking much much longer than I expected, it's at 97% and my machine is suffering immensely. But I think if I leave it overnight it'll finish.
I was however informed that Rust actually has its own fork of LLVM, so I will try building that tomorrow, as it's approaching midnight here.
I'll report back, but the bottom line is that unmodified LLVM does indeed build.
Hm, interesting. Presumably our detection and threading through of the C++ STL is wrong then.
I checked out https://github.com/rust-lang/llvm-project/tree/rustc/9.0-2019-07-12 instead, and built with the exact same commands as before.
I don't think I need to go through the entire build again, but it does appear to be working just fine.
I also tested the binaries produced by last night's LLVM build to make sure they actually work, and they do.
The error with x.py happens when configuring LLVM, not when actually compiling it, so I think this is issue is on our side.
Yeah, I agree this is probably a bug somewhere in rustbuild. Unfortunately I'd guess that it's pretty hard to reproduce the exact conditions you have; however, we'd most likely be willing to take a PR. The problem most likely lies in src/bootstrap/native.rs, somewhere around here: https://github.com/rust-lang/rust/blob/2b78e10ac1454d2d4190c575f6ece03f484ac398/src/bootstrap/native.rs#L427-L436.
Hmm, I can take a look but I'm not sure I'll be able to find anything. This is/was my first time trying to build Rust from source (my original plan was to submit a pr to the stdlib, actually...)
All I can say is that cmake is looking for libstdc++ 4.8 or up, but doesn't recognize my installed libstdc++ 6.0 for some reason.
I'll see if I can find anything tonight.
How can I trigger a rebuild when modifying that file? Does x.py handle it?
On Sun, Aug 11, 2019, 17:05 Mark Rousskov notifications@github.com wrote:
Yeah, I agree this is probably a bug somewhere in rustbuild. Unfortunately I'd guess that it's pretty hard to reproduce the exact conditions you have; however, we'd most likely be willing to take a PR. The problem most likely lies in src/bootstrap/native.rs, somewhere around here: https://github.com/rust-lang/rust/blob/2b78e10ac1454d2d4190c575f6ece03f484ac398/src/bootstrap/native.rs#L427-L436 .
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/rust-lang/rust/issues/63417?email_source=notifications&email_token=AJI55IQJVH3NFYHCG3ZECZLQEATBZA5CNFSM4IKV745KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD4BCRPA#issuecomment-520235196, or mute the thread https://github.com/notifications/unsubscribe-auth/AJI55IRYPX2XGKOVMRF3L6DQEATBZANCNFSM4IKV745A .
Since LLVM isn't building presumably it'll just work, otherwise, rm -r build/x86_64-unknown-linux-gnu/llvm
should work.
I can't really find anything wrong with the snippet you linked
FWIW I ran it again with backtrace enabled:
Finished release [optimized] target(s) in 14m 29s
Copying stage0 rustc from stage0 (x86_64-unknown-linux-gnu -> x86_64-unknown-linux-gnu / x86_64-unknown-linux-gnu)
Building LLVM for x86_64-unknown-linux-gnu
running: "cmake" "/home/luna/shared/projects/rust/src/llvm-project/llvm" "-DLLVM_ENABLE_ASSERTIONS=ON" "-DLLVM_TARGETS_TO_BUILD=AArch64;ARM;Hexagon;MSP430;Mips;NVPTX;PowerPC;RISCV;Sparc;SystemZ;WebAssembly;X86" "-DLLVM_EXPERIMENTAL_TARGETS_TO_BUILD=" "-DLLVM_INCLUDE_EXAMPLES=OFF" "-DLLVM_INCLUDE_TESTS=OFF" "-DLLVM_INCLUDE_DOCS=OFF" "-DLLVM_INCLUDE_BENCHMARKS=OFF" "-DLLVM_ENABLE_ZLIB=OFF" "-DWITH_POLLY=OFF" "-DLLVM_ENABLE_TERMINFO=OFF" "-DLLVM_ENABLE_LIBEDIT=OFF" "-DLLVM_ENABLE_Z3_SOLVER=OFF" "-DLLVM_PARALLEL_COMPILE_JOBS=4" "-DLLVM_TARGET_ARCH=x86_64" "-DLLVM_DEFAULT_TARGET_TRIPLE=x86_64-unknown-linux-gnu" "-DLLVM_OCAML_INSTALL_PATH=usr/lib/ocaml" "-DLLVM_LINK_LLVM_DYLIB=ON" "-DLLVM_ENABLE_LIBXML2=OFF" "-DLLVM_VERSION_SUFFIX=-rust-1.38.0-dev-f2b0c6766" "-DPYTHON_EXECUTABLE=/usr/bin/python2.7" "-DCMAKE_INSTALL_MESSAGE=LAZY" "-DCMAKE_C_COMPILER=clang" "-DCMAKE_CXX_COMPILER=clang++" "-DCMAKE_C_FLAGS=-ffunction-sections -fdata-sections -fPIC --target=x86_64-unknown-linux-gnu" "-DCMAKE_CXX_FLAGS=-ffunction-sections -fdata-sections -fPIC --target=x86_64-unknown-linux-gnu -static-libstdc++" "-DCMAKE_INSTALL_PREFIX=/home/luna/shared/projects/rust/build/x86_64-unknown-linux-gnu/llvm" "-DCMAKE_BUILD_TYPE=Release"
-- Could NOT find Z3: Found unsuitable version "0.0.0", but required is at least "4.7.1" (found Z3_LIBRARIES-NOTFOUND)
CMake Error at cmake/modules/CheckCompilerVersion.cmake:83 (message):
libstdc++ version must be at least 4.8.
Call Stack (most recent call first):
cmake/config-ix.cmake:13 (include)
CMakeLists.txt:618 (include)
-- Configuring incomplete, errors occurred!
See also "/home/luna/shared/projects/rust/build/x86_64-unknown-linux-gnu/llvm/build/CMakeFiles/CMakeOutput.log".
See also "/home/luna/shared/projects/rust/build/x86_64-unknown-linux-gnu/llvm/build/CMakeFiles/CMakeError.log".
thread 'main' panicked at '
command did not execute successfully, got: exit code: 1
build script failed, must exit now', /home/luna/.cargo/registry/src/github.com-1ecc6299db9ec823/cmake-0.1.38/src/lib.rs:813:5
stack backtrace:
0: backtrace::backtrace::libunwind::trace
at /cargo/registry/src/github.com-1ecc6299db9ec823/backtrace-0.3.29/src/backtrace/libunwind.rs:88
1: backtrace::backtrace::trace_unsynchronized
at /cargo/registry/src/github.com-1ecc6299db9ec823/backtrace-0.3.29/src/backtrace/mod.rs:66
2: std::sys_common::backtrace::_print
at src/libstd/sys_common/backtrace.rs:47
3: std::sys_common::backtrace::print
at src/libstd/sys_common/backtrace.rs:36
4: std::panicking::default_hook::{{closure}}
at src/libstd/panicking.rs:200
5: std::panicking::default_hook
at src/libstd/panicking.rs:214
6: std::panicking::rust_panic_with_hook
at src/libstd/panicking.rs:477
7: std::panicking::continue_panic_fmt
at src/libstd/panicking.rs:384
8: std::panicking::begin_panic_fmt
at src/libstd/panicking.rs:339
9: cmake::fail
at /home/luna/.cargo/registry/src/github.com-1ecc6299db9ec823/cmake-0.1.38/src/lib.rs:813
10: cmake::run
at /home/luna/.cargo/registry/src/github.com-1ecc6299db9ec823/cmake-0.1.38/src/lib.rs:791
11: cmake::Config::build
at /home/luna/.cargo/registry/src/github.com-1ecc6299db9ec823/cmake-0.1.38/src/lib.rs:629
12: <bootstrap::native::Llvm as bootstrap::builder::Step>::run
at src/bootstrap/native.rs:304
13: bootstrap::builder::Builder::ensure
at src/bootstrap/builder.rs:1285
14: bootstrap::compile::build_codegen_backend
at src/bootstrap/compile.rs:749
15: <bootstrap::compile::CodegenBackend as bootstrap::builder::Step>::run
at src/bootstrap/compile.rs:706
16: bootstrap::builder::Builder::ensure
at src/bootstrap/builder.rs:1285
17: <bootstrap::compile::CodegenBackend as bootstrap::builder::Step>::make_run
at src/bootstrap/compile.rs:667
18: bootstrap::builder::StepDescription::maybe_run
at src/bootstrap/builder.rs:183
19: bootstrap::builder::StepDescription::run
at src/bootstrap/builder.rs:207
20: bootstrap::builder::Builder::run_step_descriptions
at src/bootstrap/builder.rs:560
21: bootstrap::builder::Builder::execute_cli
at src/bootstrap/builder.rs:550
22: bootstrap::Build::build
at src/bootstrap/lib.rs:456
23: bootstrap::main
at src/bootstrap/bin/main.rs:18
24: std::rt::lang_start::{{closure}}
at /rustc/178aa66119c5bf7c6f2f0bf1551319e54b86ea93/src/libstd/rt.rs:64
25: std::rt::lang_start_internal::{{closure}}
at src/libstd/rt.rs:49
26: std::panicking::try::do_call
at src/libstd/panicking.rs:296
27: __rust_maybe_catch_panic
at src/libpanic_unwind/lib.rs:82
28: std::panicking::try
at src/libstd/panicking.rs:275
29: std::panic::catch_unwind
at src/libstd/panic.rs:394
30: std::rt::lang_start_internal
at src/libstd/rt.rs:48
31: std::rt::lang_start
at /rustc/178aa66119c5bf7c6f2f0bf1551319e54b86ea93/src/libstd/rt.rs:64
32: main
33: __libc_start_main
34: _start
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
finished in 1.245
failed to run: /home/luna/shared/projects/rust/build/bootstrap/debug/bootstrap build --stage 0
Build completed unsuccessfully in 0:15:17
I don't really know how to approach this issue right now
Which files are responsible for running CheckCompilerVersion, which is mentioned in the CMake error? (CMake Error at cmake/modules/CheckCompilerVersion.cmake:83
)
Yeah, I'm also at a loss. AFAICT, the check is happening as a normal part of the LLVM build...
The test that fails in particular is LLVM_LIBSTDCXX_MIN
The particular test says:
Test for libstdc++ version of at least 4.8 by checking for _ZNKSt17bad_function_call4whatEv.
The bizarre thing is that
I ran nm -D /usr/lib64/libstdc++.so | grep _ZNKSt17bad_function_call4whatEv
And it matches!
00000000000c8510 T _ZNKSt17bad_function_call4whatEv
And that test is behind a elseif(NOT LLVM_ENABLE_LIBCXX)
gate
And my config.toml has
[llvm]
use-libcxx = true
So this flag in particular seems to not get passed correctly.
And looking around the same file, this test is only ever run to begin with if(CMAKE_CXX_COMPILER_ID STREQUAL "Clang")
.
So I guess I'll make a fresh checkout and set everything to compile with gcc/g++ instead?
And it is building. So for some reason
A: the use-libcxx flag does not get passed on correctly B: the LLVM_LIBSTDCXX_MIN test in https://github.com/rust-lang/llvm-project/blob/rustc/9.0-2019-07-12/llvm/cmake/modules/CheckCompilerVersion.cmake#L53-L84, which only runs when compiling with Clang, fails inexplicably.
I'm at a loss, but it's compiling now, so... hooray?
I think this should still be looked into, as there is almost definitely some kind of bug here. Although it may be an upstream bug, I'm not sure anymore.
The error was:
fatal error: 'iosfwd' file not found
#include <iosfwd>
^~~~~~~~
Just making sure, does it work when use-libcxx = true
is commented out or set to false?
To use libc++ on Solus you need llvm-devel
package among the others.
Clang has few tricks to detect system libstdc++ and that should work just fine but CMake sometimes get confused when compilation options are changed and mixes old config with the new one.
Aw shucks, I think I missed that package. Though, the value of use-libcxx
didn't seem to matter, as it was setting cc/cxx to clang/clang++ on the
first build (prior to setting use-libcxx
) that caused the issue.
So, I'm guessing Clang looks for the libc++ headers regardless if it's
actually linking to it or not? Which would seem odd to me, but that might
be the case.
I'll give it another go tomorrow, maybe this was all a big goof on my part,
in which case I'm very sorry for the confusion caused.
Also yes, as I said above I did a clean checkout earlier and compiled strictly with gcc/g++/libstdc++ and it worked fine. It's likely I fudged up with the missing header package, will try tomorrow.
My only defense is that the error message was wildly misleading in what the actual issue was. I had seen the include error but given I had a working set of headers that Clang was happy to use in test programs I wrote I marked it off as CMake being weird, not making the connection that the test failed because it didn't compile.
On Mon, Aug 12, 2019, 00:40 Mateusz Mikuła notifications@github.com wrote:
The error was:
fatal error: 'iosfwd' file not found
include
^~~~~~~~
Just making sure, does it work when use-libcxx = true is commented out or set to false? To use libc++ on Solus you need llvm-devel package among the others.
Clang has few tricks to detect system libstdc++ and that should work just fine but CMake sometimes get confused when compilation options are changed and mixes old config with the new one.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/rust-lang/rust/issues/63417?email_source=notifications&email_token=AJI55IUFMYVD2RX3ZL3V7I3QECIPPA5CNFSM4IKV745KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD4BKJTQ#issuecomment-520266958, or mute the thread https://github.com/notifications/unsubscribe-auth/AJI55IVLI6PTVQ3LAF52MJTQECIPPANCNFSM4IKV745A .
Scratch most of that, I do have llvm-devel installed.
Unfortunately rebuilding LLVM also requires throwing out the entire stage 0 artifacts, which take ~30 minutes to download / build on my system
It seems to be some kind of issue with clang's command line options. specifically, I'm not sure if -stdlib=libc++
is being passed correctly.
So, I'm guessing Clang looks for the libc++ headers regardless if it's actually linking to it or not? Which would seem odd to me, but that might be the case.
No, that would break almost everything.
I'll into this issue in a few days when I'm back home.
How can I verify LLVM is actually being built with ilbc++ (use-libcxx = true
)
CMake's output doesn't tell me anything, and doesn't mention -stdlib=libc++
in CMAKE_CXX_FLAGS or similar vars.
Edit: I interrupted the build and checked a random exe with ldd, in this case $RUST_CHECKOUT/build/x86_64-unknown-linux-gnu/llvm/build/bin/FileCheck
and it has linked to libstdc++
, not libc++
. I'm currently still using gcc/g++ to build LLVM, is use-libcxx
not supported? config.toml.example
doesn't say anything about it. (It mentions "host compiler", so I guess clang only...)
Hmm. Trying to compile LLVM with Clang at all seems to fail, with the test we've mentioned before, completely regardless of use-libcxx
, the error stays the same.
After some manual testing, the error with Clang occurs because --target=x86_64-unknown-linux-gnu
changes the default header search paths
Without --target
:
#include <...> search starts here:
/usr/bin/../lib64/gcc/x86_64-solus-linux/8/../../../../include/c++/8
/usr/bin/../lib64/gcc/x86_64-solus-linux/8/../../../../include/c++/8/x86_64-solus-linux
/usr/bin/../lib64/gcc/x86_64-solus-linux/8/../../../../include/c++/8/backward
/usr/lib64/clang/8.0.0/include
/usr/include
End of search list.
With --target
:
#include <...> search starts here:
/usr/lib64/clang/8.0.0/include
/usr/include
End of search list.
Neither directories in the latter case contain C++ headers, which are in the following directories for me:
/usr/include/c++/8 <-- libstdc++ /usr/include/c++/v1 <-- libc++
Adding the appropriate include directory via [llvm] cxxflags = "-I{dir}"
causes configuration and subsequent building to succeed. This seems hackish, but should do as a temporary solution.
I don't know if we should handle this specific behavior, or simply add a disclaimer somewhere.
Libcxx doesn't work with GCC.
Regarding Clang search directories with target argument it looks like a bug. I don't know if it's Clang or Solus bug.
I looked but Clang has no concrete documentation on the searching behavior, and scouting the source code hasn't yielded anything yet
I guess it's a Solus bug in that x86_64-solus-linux
and x86_64-unknown-linux-gnu
aren't compatible triples. I guess GCC is more permissive in this regard? In testing Clang didn't like targets like x86_64-unknown-linux
either.
So, guess I'm closing this unless anyone else would like to make a suggestion?
I will check it when I'm back home in a 3 days.
I'll keep this open then.
On Mon, Aug 12, 2019, 21:48 Mateusz Mikuła notifications@github.com wrote:
I will check it when I'm back home in a 3 days.
— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub https://github.com/rust-lang/rust/issues/63417?email_source=notifications&email_token=AJI55IUSTTEH5BKQMZNIB3DQEG473A5CNFSM4IKV745KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD4DT5DY#issuecomment-520568463, or mute the thread https://github.com/notifications/unsubscribe-auth/AJI55IXCKI5PP4IHH4RCMHDQEG473ANCNFSM4IKV745A .
Sorry for the delay, I was a bit busy. Here is output from Clang 8.0.1 on Arch Linux:
$ clang++ -E -x c++ - -v < /dev/null
...
#include <...> search starts here:
/usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/9.1.0/../../../../include/c++/9.1.0
/usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/9.1.0/../../../../include/c++/9.1.0/x86_64-pc-linux-gnu
/usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/9.1.0/../../../../include/c++/9.1.0/backward
/usr/local/include
/usr/lib/clang/8.0.1/include
/usr/include
End of search list.
...
$ clang++ --target=x86_64-unknown-linux-gnu -E -x c++ - -v < /dev/null
...
#include <...> search starts here:
/usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/9.1.0/../../../../include/c++/9.1.0
/usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/9.1.0/../../../../include/c++/9.1.0/x86_64-pc-linux-gnu
/usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/9.1.0/../../../../include/c++/9.1.0/backward
/usr/local/include
/usr/lib/clang/8.0.1/include
/usr/include
End of search list.
...
So yeah, seems it's Solus issue and you should report it on https://dev.getsol.us
Alright. Closing this. Sorry for the goose chase! ^^;
I got the same problem
@Edeae833 on which OS?
In
config.toml
, under[target.x86_64-unknown-linux-gnu]
, one can setcc
andcxx
to configure the C/C++ compiler used for building LLVM.When using clang/clang++, regardless of whether
use-libcxx
is set under[llvm]
, theLLVM_LIBSTDCXX_MIN
compile test fails due to a #include error.The error happens because passing
--target=x86_64-unknown-linux-gnu
to clang/clang++ changes the default header search paths. See https://github.com/rust-lang/rust/issues/63417#issuecomment-520510331My system uses LLVM 8.0.0 Release. (
clang version 8.0.0 (tags/RELEASE_800/final) | Target: x86_64-solus-linux
)Original Issue Text: