Make all static library exports contribute to dlls on Windows

[rikkimax]

Fixes: ldc-developers/ldc#4343

[rikkimax]

Looks like dmd-master failing isn't related to this PR.

[thewilsonator]

Any way to test this?

[rikkimax]

Any way to test this?

The last time I looked at the test suite it didn't run on Windows and it wouldn't be the simplest of test to write, since you'd need a static lib + DLL + something to verify symbols were exported.

Scream test might be the best we get, and people who use it will certainly scream quickly if it's not in.

[thewilsonator]

Scream test might be the best we get, and people who use it will certainly scream quickly if it's not in.

Lol, fair enough.

[kinke]

This was merged too soon; this can have undesired side effects like larger binaries and link-time regressions. We've had a similar regression just a few weeks back at work - some library containing a module depending on some 3rd-party lib only available on Linux, and that module (totally unused on Windows) forcefully being linked in suddenly causing lots of undefined symbol errors. The really bad thing here is that unlike default -fvisibility=public -dllimport=all, these linker flags cannot be overridden/prevented.

And there are other ways to work around this problem; -dllimport=all was designed for all other D library deps being DLLs. When really wanting to link other libs statically into the DLL (edit: a DLL compiled with -dllimport=all), a sourceLibrary would work best in terms of generated code (but suboptimal regarding build times). Compiling the static lib as single object via -singleobj would also work in almost all cases, but come with similar disadvantages as /WHOLEARCHIVE.

[rikkimax]

What we could do is add a build requirement to turn this behavior off for a given shared library. So if you need control you have it, but the default will still be it is most likely going to work.

[Geod24]

No test, no review, let's revert: #2616