Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Windows] Unresolved symbol in shared static this. #3916

Closed
skyline131313 opened this issue Feb 14, 2022 · 1 comment
Closed

[Windows] Unresolved symbol in shared static this. #3916

skyline131313 opened this issue Feb 14, 2022 · 1 comment

Comments

@skyline131313
Copy link

// Source/Game/Core/Math/package.d
module Game.Core.Math;
// Source/Game/Core/Random.d

module Game.Core.Random;

import std.random : Xorshift, unpredictableSeed;

import Game.Core.Math;


private __gshared Xorshift engine;

shared static this()
{
    engine = Xorshift(unpredictableSeed);
}

Output from the build:

ldmd2 -m64 -g -shared -I../Build/Imports/ -JText/ -JData/ -mscrtlib=msvcrt -of../Build/Bin/Windows/runtime_out.dll Source\Game\Core\Random.d Source\Game\Core\Math\package.d -L/LIBPATH:../Build/Lib/Windows/x64 -L/PDB:../Build/Obj/runtime-20220214-113857.pdb OpenAL32.lib vulkan-1.lib SDL2.lib imgui.lib libvorbis.lib libvorbisfile.lib

runtime_out.obj : error LNK2019: unresolved external symbol _D3std6random__T14XorshiftEngineTkVki128Vii11ViN8ViN19ZQBn6__initZ referenced in function _D4Game4Core6Random24_sharedStaticCtor_L11_C1FZv
..\Build\Bin\Windows\runtime_out.dll : fatal error LNK1120: 1 unresolved externals

Turning it to a function makes it compile and resolve successfully, also needs to include the math package as the bare minimum.

@kinke
Copy link
Member

kinke commented Feb 26, 2022

Thx; finally found some time to reproduce. Reduced (ldc2 -shared bla.d):

import std.random : Xorshift, unpredictableSeed;

private __gshared Xorshift engine;

shared static this()
{
    engine = Xorshift(unpredictableSeed);
}

It works with -linkonce-templates, and with -dllimport=defaultLibsOnly (and so with -fvisibility=hidden too). And when converting the module ctor to a regular function, as you mentioned.

kinke added a commit to kinke/ldc that referenced this issue Feb 28, 2022
…ndows

Instantiated data symbols were previously never dllimported with
`-dllimport=all`. So if the parent template instance wasn't
codegen'd into the binary directly, it remained undefined.

For `-dllimport=defaultLibsOnly`, the 'solution' to this problem
was to define-on-declare data symbols instantiated from druntime/
Phobos templates, making sure each binary defines all such symbols
it references.

In both cases, switch to an approach where we dllimport all
instantiated data symbols (or druntime/Phobos symbols only), and
dllexport them whenever defining them (so that other object files
or binaries can import them). This may lead to more 'importing
locally defined symbol' linker warnings, but may also lead to less
duplicates and possibly 'proper' sharing of instantiated globals
across the whole process.

This is superfluous and skipped with `-linkonce-templates`, as
that mode defines all referenced instantiated symbols in each
binary anyway, and so has already been a workaround.
kinke added a commit to kinke/ldc that referenced this issue Feb 28, 2022
…ndows

Instantiated data symbols were previously never dllimported with
`-dllimport=all`. So if the parent template instance wasn't
codegen'd into the binary directly, it remained undefined.

For `-dllimport=defaultLibsOnly`, the 'solution' to this problem
was to define-on-declare data symbols instantiated from druntime/
Phobos templates, making sure each binary defines all such symbols
it references.

In both cases, switch to an approach where we dllimport all
instantiated data symbols (or druntime/Phobos symbols only), and
dllexport them whenever defining them (so that other object files
or binaries can import them). This may lead to more 'importing
locally defined symbol' linker warnings, but may also lead to less
duplicates and possibly 'proper' sharing of instantiated globals
across the whole process.

This is superfluous and skipped with `-linkonce-templates`, as
that mode defines all referenced instantiated symbols in each
binary anyway, and so has already been a workaround.
kinke added a commit to kinke/ldc that referenced this issue Feb 28, 2022
…ndows

Instantiated data symbols were previously never dllimported with
`-dllimport=all`. So if the parent template instance wasn't
codegen'd into the binary directly, it remained undefined.

For `-dllimport=defaultLibsOnly`, the 'solution' to this problem
was to define-on-declare data symbols instantiated from druntime/
Phobos templates, making sure each binary defines all such symbols
it references.

In both cases, switch to an approach where we dllimport all
instantiated data symbols (or druntime/Phobos symbols only), and
dllexport them whenever defining them (so that other object files
or binaries can import them). This may lead to more 'importing
locally defined symbol' linker warnings, but may also lead to less
duplicates and possibly 'proper' sharing of instantiated globals
across the whole process.

This is superfluous and skipped with `-linkonce-templates`, as
that mode defines all referenced instantiated symbols in each
binary anyway, and so has already been a workaround.
@kinke kinke closed this as completed in f2a6fef Feb 28, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants