search

rust-lang / rust

Empowering everyone to build reliable and efficient software.
https://www.rust-lang.org
Other
98.03k stars 12.68k forks source link

Building LLVM with Clang fails #63417

Closed LunarLambda closed 5 years ago

LunarLambda commented 5 years ago

In config.toml, under [target.x86_64-unknown-linux-gnu], one can set cc and cxx to configure the C/C++ compiler used for building LLVM.

When using clang/clang++, regardless of whether use-libcxx is set under [llvm], the LLVM_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-520510331

My system uses LLVM 8.0.0 Release. (clang version 8.0.0 (tags/RELEASE_800/final) | Target: x86_64-solus-linux)

Original Issue Text:

I am currently trying to build rust on a Solus 4 machine.

The error happens in stage 0 when building LLVM, where it complains about an incompatible version of libstdc++, even if use-libcxx = true is set under [llvm].

Dependencies (g++ clang++ python make cmake curl git):

g++ (Solus) 8.3.1 20190320
clang version 8.0.0 (tags/RELEASE_800/final)
Python 2.7.16
GNU Make 4.2.1
cmake version 3.15.1
curl 7.65.3 (x86_64-solus-linux-gnu) libcurl/7.65.3 OpenSSL/1.0.2r zlib/1.2.11 libssh2/1.7.0_DEV nghttp2/1.36.0
git version 2.22.0

x.py build --stage 0 output:

Updating only changed submodules
Submodules updated in 0.02 seconds
    Finished dev [unoptimized] target(s) in 0.09s
Building stage0 std artifacts (x86_64-unknown-linux-gnu -> x86_64-unknown-linux-gnu)
    Finished release [optimized] target(s) in 0.11s
Copying stage0 std from stage0 (x86_64-unknown-linux-gnu -> x86_64-unknown-linux-gnu / x86_64-unknown-linux-gnu)
Building stage0 test artifacts (x86_64-unknown-linux-gnu -> x86_64-unknown-linux-gnu)
    Finished release [optimized] target(s) in 0.08s
Copying stage0 test from stage0 (x86_64-unknown-linux-gnu -> x86_64-unknown-linux-gnu / x86_64-unknown-linux-gnu)
Building stage0 compiler artifacts (x86_64-unknown-linux-gnu -> x86_64-unknown-linux-gnu)
    Finished release [optimized] target(s) in 0.10s
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" "-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
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace.
  finished in 0.027
failed to run: /home/luna/shared/projects/rust/build/bootstrap/debug/bootstrap build --stage 0
Build completed unsuccessfully in 0:00:01

config.toml and build/x86_64-unknown-linux-gnu/llvm/build/CMakeFiles/CMakeOutput.log: https://gist.github.com/LunarLambda/9b6674731bb1d8f123bca143d546d94e

I would like to avoid having to setup an Ubuntu/Debian system or having to compile GCC 4.8 manually just to build Rust. Any help is appreciated

Mark-Simulacrum commented 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...

LunarLambda commented 5 years ago

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.

Mark-Simulacrum commented 5 years ago

Hm, interesting. Presumably our detection and threading through of the C++ STL is wrong then.

LunarLambda commented 5 years ago

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.

Mark-Simulacrum commented 5 years ago

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.

LunarLambda commented 5 years ago

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 .

Mark-Simulacrum commented 5 years ago

Since LLVM isn't building presumably it'll just work, otherwise, rm -r build/x86_64-unknown-linux-gnu/llvm should work.

LunarLambda commented 5 years ago

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)

Mark-Simulacrum commented 5 years ago

Yeah, I'm also at a loss. AFAICT, the check is happening as a normal part of the LLVM build...

LunarLambda commented 5 years ago

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?

LunarLambda commented 5 years ago

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.

mati865 commented 5 years ago

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.

LunarLambda commented 5 years ago

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 .

LunarLambda commented 5 years ago

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.

mati865 commented 5 years ago

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.

LunarLambda commented 5 years ago

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.

LunarLambda commented 5 years ago

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.

mati865 commented 5 years ago

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.

LunarLambda commented 5 years ago

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?

mati865 commented 5 years ago

I will check it when I'm back home in a 3 days.

LunarLambda commented 5 years ago

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 .

mati865 commented 5 years ago

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

LunarLambda commented 5 years ago

Alright. Closing this. Sorry for the goose chase! ^^;

ghost commented 4 years ago

I got the same problem

mati865 commented 4 years ago

@Edeae833 on which OS?