ccinfo: when providing ccinfo, optionally include libstd and alloc #624
Conversation
|
(I expect this to be broken, please don't review just yet.) |
durin42
force-pushed
the
extralibs
branch
3 times, most recently
from
9aee1d0
to
43f5664
Compare
|
(Still some more to sort out, please don't merge yet.) |
|
This looks reasonable so far. WDYT about also submitting your kludge cc_library? It is currently rustc version dependent, but we can make it work now, see how often it breaks, and we can get feedback on it from the community. It is also good to be able to show what we do now when discussing rust-lang/rust#73632 with folks. |
|
Still pending: a test, and I think this ends up providing the rust_lib libraries in the wrong order, causing linker problems. But close. More later today, I hope. |
durin42
force-pushed
the
extralibs
branch
2 times, most recently
from
c64fdfd
to
d0a304b
Compare
|
Progress, mostly: for some reason linking is failing to find the hello_from_rust symbol. The linker invocation looks vaguely okay, so I'll stop here for now. |
|
Okay, closer. Lingering problems:
I'm really stopping for the night this time. |
|
Looked into that linker failure more. As far as I can tell, that's a subtle incompatibility between the libcore Rust produces and libgcc (libcore is assuming compiler-rt) when doing 128 bit overflow checks. rust-lang/rust#8449 is related-ish, at least. It sounds to me like we need some work done in LLVM to make the overflow checks compatible with libgcc again, which will then have to percolate through the Rust ecosystem next time they pick up an LLVM release. Between that and the fact that MSVC can't seem to cope with the allocator library sources, I'm out of ideas for ways to test this in-tree. I can add a test that validates the presence of the libstd CcInfo on a simple rust_library, but that seems to be about it. Is that enough for folks to be happy? |
test/unit/native_deps/alloc_shims.c
Outdated
| #include <stddef.h> | ||
| #include <stdlib.h> | ||
|
|
||
| void* __rdl_alloc(size_t, size_t); |
There was a problem hiding this comment.
I'd put this file into generated rust toolchains for linux when cc rules detected clang, but let's do it in a followup PR.
|
Regarding testing, I'd be fine with excluding the failing test on windows (also mac?) CI tasks (.bazelci/presubmit.yml). For linux, this still doesn't work with gcc right? In that case I think we can add new tasks for clang on linux (CI workers should have clang installed, I'm not sure if they use libc++ though) |
The new attribute on RustToolchain is the label of a target that provides __rust_realloc et al, which allows ld(1) to use the .rlib files directly without needing to involve rustc in the linking step. This means Rust and C++ can be mixed in a cc_binary freely without needing any staticlib-type crates, which avoids problems if you have a cc_binary -> rust_library -> cc_library -> rust_library situation.
durin42
force-pushed
the
extralibs
branch
2 times, most recently
from
e93f789
to
799d8dd
Compare
This only works on clang today, and can only work on clang for the near-term. It's not clear how to write a clang-only test in this case, so we just give up for now. "I promise it works!" etc
…alloc (bazelbuild#624)" This reverts commit 802bcf9. Works around bazelbuild#635.
The new attribute on RustToolchain is the label of a target that
provides __rust_realloc et al, which allows ld(1) to use the .rlib
files directly without needing to involve rustc in the linking
step. This means Rust and C++ can be mixed in a cc_binary freely
without needing any staticlib-type crates, which avoids problems if
you have a cc_binary -> rust_library -> cc_library -> rust_library
situation.