digitalmars.D.bugs - [Issue 8133] New: regression(2.059): D shared lib on OSX fails in 2.059, worked in 2.058
- d-bugmail puremagic.com (49/49) May 23 2012 http://d.puremagic.com/issues/show_bug.cgi?id=8133
- d-bugmail puremagic.com (13/13) May 23 2012 http://d.puremagic.com/issues/show_bug.cgi?id=8133
- d-bugmail puremagic.com (9/11) May 23 2012 http://d.puremagic.com/issues/show_bug.cgi?id=8133
- d-bugmail puremagic.com (17/26) May 23 2012 http://d.puremagic.com/issues/show_bug.cgi?id=8133
- d-bugmail puremagic.com (10/22) May 23 2012 http://d.puremagic.com/issues/show_bug.cgi?id=8133
- d-bugmail puremagic.com (12/12) Jun 02 2012 http://d.puremagic.com/issues/show_bug.cgi?id=8133
http://d.puremagic.com/issues/show_bug.cgi?id=8133
Summary: regression(2.059): D shared lib on OSX fails in 2.059,
worked in 2.058
Product: D
Version: D2
Platform: All
OS/Version: Mac OS X
Status: NEW
Severity: regression
Priority: P2
Component: druntime
AssignedTo: nobody puremagic.com
ReportedBy: thelastmammoth gmail.com
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
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
D4core7runtime7Runtime10initializeFDFC6object9ThrowableZvZb ()
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
May 23 2012
d-bugmail puremagic.com
http://d.puremagic.com/issues/show_bug.cgi?id=8133
Jacob Carlborg <doob me.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |doob me.com
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.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
May 23 2012
http://d.puremagic.com/issues/show_bug.cgi?id=8133The 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. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
May 23 2012
http://d.puremagic.com/issues/show_bug.cgi?id=8133I 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. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------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.
May 23 2012
http://d.puremagic.com/issues/show_bug.cgi?id=8133I 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. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
May 23 2012
http://d.puremagic.com/issues/show_bug.cgi?id=8133
dawg dawgfoto.de changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
CC| |dawg dawgfoto.de
Resolution| |DUPLICATE
*** This issue has been marked as a duplicate of issue 7995 ***
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jun 02 2012