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