Special behaviour for _Dmodule_ref and _d_run_main?

Denis Feklushkin feklushkin.denis at gmail.com
Mon May 11 12:30:49 UTC 2020


On Monday, 11 May 2020 at 12:14:23 UTC, kinke wrote:
> On Monday, 11 May 2020 at 12:00:40 UTC, Denis Feklushkin wrote:
>>> _Dmodule_ref shouldn't have been in use on x86(_64) Linux for 
>>> a few years now.
>>
>> LDC fork of druntime still uses it.
>
> It's not used for Linux; the legacy _Dmodule_ref linked list is 
> only used for unknown OS IIRC. There have been undefined 
> _Dmodule_ref symbol issues for WebAssembly too IIRC.
>
>> $ llvm-nm-9 -a libdruntime.a says that _Dmodule_ref and 
>> _Dmodule_ref is defined in libdruntime.a
>
> Just for completeness, what are you linking against, an LTO 
> druntime or a regular druntime?

Linking against LTO libdruntime.a

>
> Unknown OS isn't on my priorities list,

The lack of an operating system, more precisely :-)

> especially not if there's only LTO troubles, so you'll probably 
> have to look into this yourself if you wanna get it working 
> with LTO.

There is some special behavior for libdruntime during linking?

_d_run_main and _Dmodule_ref placed not in core.internal.* 
(unlike of core.internal.entrypoint._d_cmain, for example), so it 
looks like there shouldn't be any problems... but problems is 
here.



More information about the digitalmars-d-ldc mailing list