Repository navigation
Error cargo building std as a dylib #36501
Description
Activity
Looks good to me! (I hope once make is gone we can put things in their normal locations and the entire
[lib]section can be elided.)IIUC, we eventually want cargo to be smart enough to build deps (and later still, only public deps) as dylibs. This would be the decision of the bottom crate / builder not any library, so hacking rustbuild for now is a step in the right direction.
All these changes anticipate what I want to do once my RFC is merged, so keep 'em coming!
For this specific error, I wonder if perhaps a more targeted fix would suffice? It looks like it's because jemalloc isn't compiled which the the target the standard library is being compiled for assumes will exist.
Basically, on this line, we'd link
alloc_systemfor bothstage0andcfg(not(feature = "jemalloc")).This does have interesting implications, though, for jemalloc. Does mean that building std in a custom fashion is a bit harder.
mmm, how's that better? Custom
stds may indeed want jemalloc, and I don't see whatcrate-typegets us long term.The problem is that when the compiler builds a dylib it attempts to link the default dylib allocator. For many targets that's jemalloc, but jemalloc isn't compiled unless you enable a feature.
The problem is that when the compiler builds a dylib it attempts to link the default dylib allocator. For many targets that's jemalloc, but jemalloc isn't compiled unless you enable a feature.
(Alternatively, we could default to system alloc everywhere. Less C is always good in my book)
The "default dylib allocator" stuff is just a stopgap until we get general needs-provides, so I wouldn't sweat it.
@japaric eventually hopefully!
- added a commit that references this issue
on Dec 23, 2016 The problem is that when the compiler builds a dylib it attempts to link the default dylib allocator. For many targets that's jemalloc, but jemalloc isn't compiled unless you enable a feature.
I read this and was confused, so to elaborate for other readers - dylibs are partitioned into 'dylibs used as rust dependencies' and 'other dylibs'. The former (the definition being encountered here) use the same allocator as the current rust compiler will give to executables, typically jemalloc. The latter is basically always the system allocator. See
rust/src/librustc_metadata/creader.rs
Line 822 in ff591b6
-C prefer-dynamicis the way the former is indicated to rustc, and is (I think, more hazy here) detected in cargo by checking whether the crate is both a dylib and is not a member of the current workspace (i.e. is a dep somewhere).Oh, and (again, just for the record) I think the issue here is relatively easily solved if your
--targetis a .json - I believe you just need to set "exe_allocation_crate" as "alloc_system". Unfortunately I'm not aware of a way to override parts of targets on the fly (I'd be delighted if I'm wrong!), so it's harder otherwise.I think this is likely fixed with jemalloc now removed in #55238 so closing
Or should
cargo buildingstdonly produce a .rlib?Now that #35021 landed and compiler-rt intrinsics are built as part of the std crate dependencies,
one can (cross) compile binaries if the
alloc_system(oralloc_jemalloc),panic_unwindandstdcrates are listed under the crate Cargo.toml:if and only if the Cargo.toml of the std crate is modified as follows
[lib] name = "std" path = "lib.rs" -crate-type = ["dylib", "rlib"] [dependencies] alloc = { path = "../liballoc" }to not build a dylib. Without this change
cargo buildinghellofails with:during the compilation of the
stdcrate. (On that note, I'm sure why buildingstdas a dylibfails? Is it because rustc injects a
extern crate alloc_jemallocintostdsource when compilinga dylib but alloc_jemalloc is an optional dependency of
stdthat's not build (the feature isdisabled) in this example?)
I discussed this with @alexcrichton and we were wondering if we should modify the std crate to only
compile the rlib to make this case work out of the box. And then hack
bootstrapto force it to buildstdas dylib because it is needed to link rustc.cc @Ericson2314 I don't how/if this change would affect your Cargo+std RFC. (Probably not?)