Place __muloti4 in a separate object file

[tmiasko]

libc++ defines __muloti4 builtin llvm.org/PR30643. When referenced and
linked before compiler builtins, it will likely lead to a link failure,
since all Rust implemented builtins are currently placed in a single
object file.

Workaround the issue by using a C implementation when enabled.

[alexcrichton]

I would personally prefer to not pick up more of a C dependency where we don't already have it. I don't think that this is also isolated to just this one symbol, so I think that if this wants to be fixed it should be fixed at the rustc level to place each function into its own object file.

[tmiasko]

In the context of libc++ it is isolated to a single symbol https://github.com/llvm/llvm-project/blob/master/libcxx/src/filesystem/int128_builtins.cpp

But more generally this would definitely need a different solution, one that is compatible with Rust implementations.

[alexcrichton]

Yes most other compiler-rt-like implementations have one-symbol-per-file. The Rust compiler has the rough ability to do this but we'd have to teach it to do so specially for the compiler-builtins crate (we already have a magical attribute which hooks into some custom settings like visibility)

[metajack]

Is this what we're running into here? tikv/rust-rocksdb#461

We'd love a suggestion on how to work around this.

[tmiasko]

FWIW my point was that libc++ defines only this one intrinsic (not just that it is separate):

$ nm --format=posix --defined-only --extern-only /usr/lib/llvm-9/lib/libc++.a | grep '^__' | sort | uniq
__clang_call_terminate W 0 b
__muloti4 T 0 124

More generally, exposing per source module partitioning outside incremental mode might be enough to address this.

[alexcrichton]

@tmiasko oh wow that is pretty odd, and unfortunate since libc++ typically comes before compiler-rt which is why I think we haven't run into this specifically before (but we have run into this in various capacities over time).

@metajack I don't know of a workaround.