-
Notifications
You must be signed in to change notification settings - Fork 12.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Build with pure LLVM toolchain on Linux #65051
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. |
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. |
…unwind to fix optimized i386
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.
|
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 build
will 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: