You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Not sure if this is the right place to ask, but seems like a likely candidate.
Right now, if you link against alloc without having a global allocator, the linker fails with
no global memory allocator found but one is required; link to std or add `#[global_allocator]` to a static item that implements the GlobalAlloc trait
However, my use case of alloc is exclusively via the _in APIs; I'm only using (non-global) arena allocators.
I'm currently working around this by having a dummy global allocator, but this is not ideal for a couple reasons:
I might accidentally use the global alloc new API for some alloc type in a random codepath, and it won't fail until runtime
I might pull in a dependency that advertises no_std, but deep in its bowels it actually invokes the global allocator in a rarely-used codepath, causing a surprise panic at runtime. That's not hypothetical - it actually happened with one of my current project's dependencies and I had to fork it to remove any linkages against alloc.
Ideally, we would defer linker failure to the absolute last minute, so the compilation only fails if a global allocator is actually referenced in the linked binary, rather than pessimistically fail just because I'm pulling in alloc.
Is this on anyone's radar? I'm not sure if my use case (embedded programming with only non-global allocators) is representative - this might be kind of an uncommon failure mode when linking against alloc.
The text was updated successfully, but these errors were encountered:
If I don't have any global allocs, it links fine. If I add one, linking fails with note: rust-lld: error: undefined symbol: fake_dealloc_this_doesnt_exist
This makes me think that this might actually be an easier technical issue than I thought. Perhaps we can just eliminate whatever check is emitting the no global memory allocator found message and let the linker error out?
Not sure if this is the right place to ask, but seems like a likely candidate.
Right now, if you link against
alloc
without having a global allocator, the linker fails withHowever, my use case of
alloc
is exclusively via the_in
APIs; I'm only using (non-global) arena allocators.I'm currently working around this by having a dummy global allocator, but this is not ideal for a couple reasons:
new
API for somealloc
type in a random codepath, and it won't fail until runtimeno_std
, but deep in its bowels it actually invokes the global allocator in a rarely-used codepath, causing a surprisepanic
at runtime. That's not hypothetical - it actually happened with one of my current project's dependencies and I had to fork it to remove any linkages againstalloc
.Ideally, we would defer linker failure to the absolute last minute, so the compilation only fails if a global allocator is actually referenced in the linked binary, rather than pessimistically fail just because I'm pulling in
alloc
.Is this on anyone's radar? I'm not sure if my use case (embedded programming with only non-global allocators) is representative - this might be kind of an uncommon failure mode when linking against
alloc
.The text was updated successfully, but these errors were encountered: