Build with pure LLVM toolchain on Linux #65051
Labels
A-LLVM
Area: Code generation parts specific to LLVM. Both correctness bugs and optimization-related issues.
C-feature-request
Category: A feature request, i.e: not implemented / a PR.
T-bootstrap
Relevant to the bootstrap subteam: Rust's build system (x.py and src/bootstrap)
Comments
|
Configure llvm with Alternatively, use link option Since clang 9,
|
|
Thanks for the answer, Obviously, my LLVM and clang compiler are already built with those options and that's why by default clang++ will link to libc++, libunwind and use compiler-rt by default without any switches. See: What I suspect is that -lgcc_s is probably "hardcoded" in the bootstrap tools and forced while re-building rustc with this bootstrap itself. |
Correct, IIRC gcc libs were hardcoded in multiple places in the past (don't really know about how it currently is). Line 25 in ad7c55e |
|
For the moment, I'm fooling the build process by creating a fake libgcc_s.so which simply contains: It's a bit hackish but I went further into the build process now. |
csmoe
added
the
T-bootstrap
jonas-schievink
added
A-LLVM
|
I got further in the build with the fake libgcc_s.so file and the proposal to change gcc_s in lib.rs file from libunwind. But it looks like something is still not linked to LLVM's libunwind because after stage1 I get: |
|
@markand could you paste here output of |
|
There are lot of missing symbols. It clearly isn't linked to libunwind as readelf shows. |
This is expected, at least when it comes to missing Rust libraries. You'd have to set
I'd expect it to be linked at this point but I can be wrong. IIRC libunwind doesn't provide I haven't been playing with non-trunk LLVM for a bit but I recall there were issues around libc++abi and libunwind. Hoping that @MaskRay will confirm or deny my guess. |
|
Thanks again for the quick answer, libunwind.so has |
|
Hello, This is the list of built libraries that have undefined symbols to LLVM's libunwind, I've tried adding |
|
I have an theory. |
|
Yes it is pulled by libc++.so. In fact we have the following input file (FreeBSD does something similar with compiler-rt). I have not seen the |
|
So the LDFLAGS didn't work and I've also rebuilt clang with the option to use libunwind by default with no luck. So I've rebuilt musl library to force inclusion of libunwind symbols into it. A bit hackish but I went further... Once I get a native rustc I'll revert my custom libc.so. Now it fails because of an unmatched function definition. Is rust 1.37 compatible with llvm 9? I'll try with rust 1.38 instead. |
LLVM 9 support was added in version 1.38. |
|
I've finally built a version using a patched version of my musl. Now it builds fine itself with my native compiler. Thanks for the help, though I think something should be changed to bootstrap Rust easier when “non traditional” toolchains are used but I have no knowledge in rust internals to help unfortunately. |
ekrich
referenced
this issue
in scala-native/scala-native
Aug 17, 2021
…unwind to fix optimized i386
paulalesius
added a commit
to paulalesius/guix-rust
that referenced
this issue
Oct 9, 2022
rust-lang/rust#65051 Signed-off-by: Paul Alesius <paul@unnservice.com>
|
Any updates on this? I still have to follow the fix mentioned above which is obviously not a great solution. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Hello,
I'm creating a Linux distribution that does not use GCC and use LLVM/Clang and their libraries by default (libc++, libc++abi, compiler-rt and libunwind). No libstdc++ or gcc installed. The distribution is based on musl as well.
I'd like to build rust with that pure LLVM toolchain and since nobody did that before I'm having few issues and unable to find many resource on this topic. Alpine Linux also build with musl but they still use GCC instead.
What I've tried:
The config.toml:
./x.py buildwill abort not finding -lgcc_s (which unsurprisingly, does not exist).What should I do to force linking against libunwind, libc++abi rather than GCC equivalents?
The text was updated successfully, but these errors were encountered: