Bug 15748 – inconsistent symbols generated by dmd vs ldc

test.d: --- module tests.stacktrace.test2.test; void test(){} --- $compiler -oflibfoo.a -lib -g test.d compiler=dmd: nm libfoo.a|grep _D5tests10stacktrace5test24testFZv warning: nm: no name list 00000000000002d4 S _D5tests10stacktrace5test24testFZv compiler=ldmd2: 0000000000000240 T __D5tests10stacktrace5test24testFZv several things differ: double '_' for ldmd2, single for dmd T (text section) for ldmd2 vs S for dmd I was actually trying to link a program compiled with dmd with a library compiled with ldc, and ran into: Undefined symbols for architecture x86_64: "_D5tests10stacktrace5test212__ModuleInfoZ", referenced from: _D5tests10stacktrace4test12__ModuleInfoZ in z02.o "_D5tests10stacktrace5test24testFZv", referenced from: __Dmain in z02.o Shouldn't this use case be supported ? Even if not 100%; would enable use cases involving fast compile times from dmd + fast code (for critical code) from ldc.

Single underscore is standard mangling for D symbols, most platforms take it literally, mac traditionally adds extra underscore to all symbols.

*** This issue has been marked as a duplicate of issue 8207 ***