This week's experiment build gdc with tls disabled.

[David Nadlinger]

On Friday, 20 December 2013 at 10:54:56 UTC, Iain Buclaw wrote:
> As for module discovery, we already generate this in the GDC 
> backend,
> which makes it then the job of runtime to pick-up, sort and run 
> the
> ctors on all modules:
>
> @attribute("constructor")
> void __modinit()
> {
>   extern (C) __gshared ModuleReference* _Dmodule_ref;
>   static private ModuleReference __mymod = 
> ModuleReference(null, minfo);
>
>   __mymod.next = _Dmodule_ref;
>   _Dmodule_ref = &__mymod;
> }
>
>
>
> Unless I'm missing something in how module discovery is 
> supposed to
> work, this could be instead amended to:
>
> @attribute("constructor")
> void __modinit()
> {
>   extern (C) void __register_module(ModuleInfo *);
>
>   __register_module(&minfo);
> }
>
> So that any lazily loaded modules would be recorded to an 
> existing
> list and trigger a run-once ctor run.

The _Dmodule_ref approach is virtually the same as we have been 
doing in LDC up to now. The problem with regard to runtime 
loading of shared libraries is that you need to run certain code 
(i.e. the current _d_dso_registry in DMD's/LDC's druntime) when 
you know that you have collected all the modules. You can't do 
this from a .ctor, because if you also use them for constructing 
the module list, you'd need to call the registry function in the 
last .ctor to run. And at least if you don't know the order in 
which they are written to the executable, you can't know that.

It might be possible to work around this requirement by rewriting 
the druntime internals to perform all the collision checking, 
etc. one-by-one, but I didn't investigate this in more detail.

David