-
Notifications
You must be signed in to change notification settings - Fork 13k
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
Breakage due to changing jemalloc symbol names #31780
Comments
it's expected (the change is tagged relnotes). It also affects people that used JE_MALLOC_CONF to tune jemalloc options. |
Presence of certain symbols (used by rust runtime/standard library) shouldn’t be covered by our stability policy IMO, because otherwise I could just EDIT. pretty much what @SimonSapin said. |
I'm inclined to think we can close this, but I'm curious to hear @brson's and @alexcrichton's opinion. One thing we could do is to re-export the old names, but I feel like we made no promise to export those particular names. It's clear that the breakage resulted from relying on impl details, but do we have a plan how one could gain access to Rust allocator in a stable-ish way? |
My feeling here is that we shouldn't provide any guarantees about these sorts of symbols. If we want to provide access to jemalloc internals we should do so through the We got clear perf wins from unprefixing jemalloc symbols on Linux, I'd personally prefer to not lose that. |
FWIW, we ended up with a build script that parses I don’t think the symbol change should be reverted, so this issue can probably be closed. A better way forward is to properly expose the functionality so we don’t need this |
I am going to close this. I'll tag with relnotes I guess in case we want to announce the change, but I think this is a clear case of depending on unstable ABIs. |
We recently unprefixed the jemalloc symbols, which causes breakage when you link to them.
The text was updated successfully, but these errors were encountered: