Bug 8133 – regression(2.059): D shared lib on OSX fails in 2.059, worked in 2.058

The simplest possible shared lib in D (see details below) worked in 2.058 but fails in 2.059. I submitted a related (lib instead of dylib) bug report (Issue 7995) which was fixed by pull request #205 from jacob-carlborg/7995. However the code fragment below (shared lib) still fails even after applying that fix (which was pushed to master). cat main.c: extern int fun(); int main(){return fun();} cat fun.d: module fun; static import core.runtime; extern (C) export int fun() { core.runtime.Runtime.initialize(); return 0; } dmd -shared fun.d -oflibfun.dylib gcc -o main main.c -L. -lfun gdb ./main Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: 13 at address: 0x0000000000000000 0x000000010000ce6c in __tls_get_addr () (gdb) where #0 0x000000010000ce6c in __tls_get_addr () #1 0x000000010000bddb in thread_attachThis () #2 0x000000010000bc6c in thread_init () #3 0x000000010000d36a in gc_init () #4 0x0000000100014035 in rt_init () #5 0x000000010000a5f7 in D4core7runtime7Runtime10initializeFDFC6object9ThrowableZvZb () #6 0x0000000100003ead in fun () #7 0x0000000100000f1f in main ()

That was revert, for some reason. I never got a good explanation from Walter: https://github.com/D-Programming-Language/druntime/pull/205#issuecomment-5675090 The 2.059 release has the same behavior as the latest commit with the pull request applied so I don't understand what Walter is talking about.

(In reply to comment #1) > The 2.059 release has the same behavior as the latest commit with the pull > request applied so I don't understand what Walter is talking about. That should have been: Walter's example from the comment to the pull request has the same behavior using the 2.059 release as the latest commit with the pull request applied.

(In reply to comment #2) > (In reply to comment #1) > > > The 2.059 release has the same behavior as the latest commit with the pull > > request applied so I don't understand what Walter is talking about. > > That should have been: > > Walter's example from the comment to the pull request has the same behavior > using the 2.059 release as the latest commit with the pull request applied. I see. Indeed the fix you had supplied did fix both Issue 7995 and this current Issue 8133 (I had pulled in the meantime the master which reverted to before your fix). It would be really great if Walter could accept your pull request once again as it is a real blocker not to be able to build shared libs. I also don't really understand his concern in his comment. Perhaps you could bug him again? A unittest with such test cases would prevent further regressions. Also, I really think it should be made clear on the dlang website in release notes what is currently supported in each version. For example, diverse forums complain that support for shared libs on OSX is not working yet with the D runtime, but 2.058 or your fix seem to support those.

(In reply to comment #3) > I see. Indeed the fix you had supplied did fix both Issue 7995 and this current > Issue 8133 (I had pulled in the meantime the master which reverted to before > your fix). > > It would be really great if Walter could accept your pull request once again as > it is a real blocker not to be able to build shared libs. I also don't really > understand his concern in his comment. Perhaps you could bug him again? A > unittest with such test cases would prevent further regressions. I've done that. Apparently the exit status program was incorrect. I'll give it another shot. > Also, I really think it should be made clear on the dlang website in release > notes what is currently supported in each version. For example, diverse forums > complain that support for shared libs on OSX is not working yet with the D > runtime, but 2.058 or your fix seem to support those. No, shared libraries are still not completely supported on Posix. There's problem with module constructs, exception handling tables and TLS data.

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