Breakage due to changing jemalloc symbol names

[brson]

We recently unprefixed the jemalloc symbols, which causes breakage when you link to them.

[bluss]

it's expected (the change is tagged relnotes). It also affects people that used JE_MALLOC_CONF to tune jemalloc options.

[nagisa]

Presence of certain symbols (used by rust runtime/standard library) shouldn’t be covered by our stability policy IMO, because otherwise I could just link_name to backtrace_print and we’re are never getting rid of libbacktrace in every rust binary by default, for example.

EDIT. pretty much what @SimonSapin said.
EDIT 2. if not clear, my point, and opinion, is: this bug is inactionable.

[nikomatsakis]

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?

[alexcrichton]

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 alloc_jemalloc crate in an unstable API, not through various symbol names that tie our hands even more than before.

We got clear perf wins from unprefixing jemalloc symbols on Linux, I'd personally prefer to not lose that.

[SimonSapin]

FWIW, we ended up with a build script that parses rustc -vV and makes the crate link to different symbols based on the Rust version number and commit date: https://github.com/servo/heapsize/blob/98d4019e/build.rs

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 extern fn hack at all: #32075

[nikomatsakis]

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.