On 6 June 2015 at 18:33, Iain Buclaw <ibuc...@gdcproject.org> wrote: > On 6 June 2015 at 18:18, Dan Olson via D.gnu <d.gnu@puremagic.com> wrote: > >> "Iain Buclaw via D.gnu" <d.gnu@puremagic.com> writes: >> >> > On 5 June 2015 at 08:40, Dan Olson via D.gnu <d.gnu@puremagic.com> >> > wrote: >> >> >> >> Sorry for a long chain on OSX. But one last unresolved symbol from >> > make >> >> check-d: "_d_osx_image_init". Is it just a placeholder or is it >> > hidden >> >> somewhere. Does gdc still need the code to set setup gc scanning? >> > How >> >> is TLS on OSX? - if not ready, would emutls work? >> >> -- >> >> Dan >> > >> > I hope I'm not shying you away by saying, this is what someone needs >> > to find out. >> > >> > I'd first suggest to build gcc only and test what is outputted. Use a >> > test program such as __thread int tls; and a main program that sets >> > it's value to 0xdeadbeef then build with -S and check if the output >> > shows calls to emutls like functions. >> > >> > GDC already has GC support for emutls, so the interesting part is if >> > GCC does native tls on osx. >> >> GCC with vanilla configure is generating emutls calls for OSX. >> > > So, we can safely remove all references to _d_osx_image_init from > rt.memory, but keep the second version(OSX) as you don't want a static > assert. ;-) >
But just to self reflect on that, maybe in it's place inline the old memory_osx but with TLS sections/handling removed: https://github.com/D-Programming-GDC/GDC/blob/0907d30b8a45036a7497d284d3210b899122cce6/libphobos/libdruntime/rt/memory_osx.d Is probably something like this: http://dpaste.dzfl.pl/e55824cab9c3
