Have been doing dev on my mac and greatly enjoying the superior codegen of ldc2.

Recently moved to linux to test and build prior to release (of scientific software) and noticed a difference across platforms.

On Mac, when an assert fails, I get a nice stack trace no matter whether dmd2 or ldc2.

On Linux, I only get a nice stack trace with dmd2, but not with ldc2:

```
module xyzzy;

void f()
{
	assert(0);
	return;
}
int main()
{
	f();
	return 1;
}
```

dmd:
core.exception.AssertError@tmp.d(5): Assertion failure
----------------
??:? _d_assertp [0x41c8ead0]
??:? void xyzzy.f() [0x41c8ea10]
??:? _Dmain [0x41c8ea1c]

ldc2:
core.exception.AssertError@tmp.d(5): Assertion failure
----------------
??:? [0x56164763cc80]
??:? [0x56164764167a]
??:? [0x56164762ea4d]
??:? [0x56164762b00c]
??:? [0x56164762a876]
??:? [0x56164762a888]
??:? [0x56164762e6ef]
??:? [0x56164762e5e7]
??:? [0x56164762a904]
??:? __libc_start_main [0x7fbfdb6e2b96]
??:? [0x56164762a769]


Adding debugging info (-g) helps a bit, resolving a couple of line numbers and __entrypoint.

Adding -link-defaultlib-debug further resolves the rest of the source files and line numbers (e.g. exception.d, dwarfeh.d, dmain2.d, runtime.d, etc.), but does not collapse the list as with DMD *OR* ldc2 on Mac OS.


Is my system misconfigured, or is this expected?  Why can I not resolve symbols?

Thanks, and thanks for such a great compiler. We are excited to be matching performance of C and C++ tools with idiomatic D and ldc2 =)

On Wednesday, 3 April 2019 at 06:19:19 UTC, James Blachly wrote:
> Is my system misconfigured, or is this expected?  Why can I not resolve symbols?

It's currently expected. See https://github.com/ldc-developers/ldc/issues/863#issuecomment-388589613 for some background info and how you can improve it with `-L-export-dynamic` (implicit for DMD).

> Thanks, and thanks for such a great compiler. We are excited to be matching performance of C and C++ tools with idiomatic D and ldc2 =)

Thx. :)