On Thursday, 17 September 2015 at 16:17:11 UTC, bitwise wrote:
On Thursday, 17 September 2015 at 10:12:57 UTC, Walter Bright
wrote:
On 9/16/2015 11:40 PM, ponce wrote:
On Wednesday, 16 September 2015 at 23:24:29 UTC, bitwise
wrote:
I was trying to solve this one myself, but the modifications
to DMD's backend
that are needed are out of reach for me right now.
If you're willing to build your own druntime, you may be
able to get by.
I'd prefer a solution that works with existing compilers, but
maybe building a
custom LDC is possible if I figure it out.
I seriously doubt this issue has anything to do with the
compiler's code generator back end. It's more likely the
problem is in druntime.
Based on previous posts you've made, it seems you already know
that Martin's solution involves having DMD's back end add linux
style ctors/dtors to the COMDAT section of every compiled D
file, so I'm not sure what you mean by this.
If a callback provided to _dyld_register_func_for_add_image
does not call sections_osx_onAddImage, then it must be called
somehow.
Bit
One solution which could work is to disallow static linking of
druntime on OSX completely....meaning, either don't even
distribute a static druntime for OSX, or make shared druntime the
default. This way, druntime would only ever be initialized once
per process. Knowing this, linux ctors/dtors could be added to
druntime to initialize it, eliminating the need to call
rt_init/rt_term before and after main(). Also, if druntime were
loaded into a C-hosted binary, druntime would automatically be
initialized by the ctors/dtors. Also, for the ctors/dtors, they
could be added to the druntime build, and wouldn't having to be
compiler generated.
I'm not sure about the difference in performance cost over static
vs shared druntime, but it seems that this is the way things are
done on OSX. If you look in /usr/lib/ on a mac, practically
everything is a shared lib.
Bit
