allocation functions exported when they shouldn't be

[retep998]

Only the first two functions in that list should be there, the rest don't belong there.
Using x86_64-pc-windows-msvc.

cc @alexcrichton

[alexcrichton]

All the symbols starting with __ are exported because they are #[no_mangle] pub extern and the rust_begin_unwind symbol is exported because it's a "weak lang item". The compiler automatically exports all #[no_mangle] pub extern functions, regardless of whether they're lang items or not (as they typically have ABI implications). This is not an MSVC-specific issue, it plagues all platforms.

The solution here would likely be to not tag these functions with #[no_mangle] pub extern but instead have them specially recognized to the compiler as not part of the public ABI but just an implementation detail of various compiler structures (e.g. allocators and panic runtimes).

[nagisa]

Right, so I hit this issue the hard way:

note: liballoc_system-8102e29f.rlib(alloc_system-8102e29f.0.o) : error LNK2005: __rust_deallocate already defined in other_rustc_built.dll.lib(other_rustc_built.dll)

On the MSVC .dll the symbol is plain exported: you can link to it, load via GetProcAddress, it has entry address etc.

On unix-like platforms, on the other hand, the symbol in question is undefined (i.e. imported):

0000000000000000       F *UND*  0000000000000000              __rust_deallocate

as it should be.

[alexcrichton]

I've updated the title of this bug to indicate that it's not just Windows nor is it just cdylib.

The solution I mentioned before may not be too hard to implement. I believe that the logic which decides to export these functions (for LTO at least) is here, and we probably can just add a whitelist of symbols that shouldn't be exported because they're just internal implementation details when compiling with LTO.

cc @froydnj
cc https://bugzilla.mozilla.org/show_bug.cgi?id=1288173

[alexcrichton]

Also note that this "whitelist" should also consider symbols like:

• rust_eh_personality
• rust_eh_personality_catch
• rust_begin_unwind

It's basically the same thing there where once we have LTO none of them need to actually get exported all the way, just linked up.

[c3st7n]

I'd be interested in looking at this if I could get a mentor.

[alexcrichton]

@c3st7n sure! If you need any help or pointers to get start just let me know