Any references on how these statics are processed?

There's the reference on #[used], and the equivalent Clang attribute and GCC attribute.

But these are somewhat vague, perhaps intentionally so as this is very much a linker concept? I don't really have a good reference on linkers, the best I can do is reference this piece of source code in rustc that talks about a workaround for static libs, and the following section from the manual page for ld64:

A static library (aka static archive) is a collection of .o files with a table of contents that lists the global symbols in the .o files. ld will only pull .o files out of a static library if needed to resolve some symbol reference. Unlike traditional linkers, ld will continually search a static library while linking.

(Note that Rust .rlibs are internally archives / static libraries, and so the rules for static libaries apply to them as well).

Or if you have more specific questions about how things work then I can try to answer them, to the best of my ability?

I see. How about adding a test to show it work as expected? You can add a dylib crate that allocs in the root directory and then add a test crate that links both the dylib and jemalloc-sys. If it works as expected the test shoud be able to use jemalloc's free to dealloc the pointer from dylib.

Sorry for the delay.

I found the closest thing to a reference link, and have rewritten the docs around it to hopefully be clearer.

I have also added two tests:

1. malloc_and_libc_are_interoperable_when_overridden, which tests that the overriding actually works on macOS.
2. test-dylib, which tests that when linking a dylib, the symbol is correctly overridden. Note that I couldn't reproduce it with the current nightly, so something might have changed recently that makes this hack redundant nowadays? Unsure, though it doesn't hurt to have in any case.

Failed CI run of the first commit with just the tests: https://github.com/madsmtm/jemallocator/actions/runs/15490515399
Successful CI run after the second commit: https://github.com/madsmtm/jemallocator/actions/runs/15490429305

I got the test-dylib test to not work without this PR, have pushed that as the first commit instead.

Failed CI run: https://github.com/madsmtm/jemallocator/actions/runs/17785024568
Succesful CI run: https://github.com/madsmtm/jemallocator/actions/runs/17784954361

Better make it a new feature so that we can land it without a new minor version.

I'd argue this is more in the category "bugfix" rather than "feature"; the unprefixed_malloc_on_supported_platforms just plain didn't work on macOS before (unless you inserted these statics yourself like rustc), and now it does.

Or do you fear this will have a chance of breaking something for users?

unprefixed_malloc_on_supported_platforms just plain didn't work on macOS before

It actually works if unprefixed_malloc_on_supported_platforms is interpreted as its name instead of overriding system allocator. The symbol is still unprefixed on MacOS in the past and future.

Or do you fear this will have a chance of breaking something for users?

Yes, it's known not to override system allocator on MacOS.

Right. In the last commit, I've changed it to:

unprefixed_malloc_on_supported_platforms = []
override = ["unprefixed_malloc_on_supported_platforms"]

I've also made the statics only get emitted with that feature enabled.