[REG2.068.0-rc1] Issue 14871 - Linker errors with 2.068.0-rc1

[9rnsr]

https://issues.dlang.org/show_bug.cgi?id=14871

Place module helpers in COMDAT sections again

This PR overrides the change in #4858.

[9rnsr]

The breaking change in release candidate version has actually introduced complaint with the frustration.

[MartinNowak]

One problem with this approach is that it still has edge cases.
For example when you compile a few objects separately and put them in an archive (that's a makefile build mode, see here), the linker will pull a "random" object out of the archive. So it doesn't completely fix Issue 14828.
FWIW the only other valid fix is to emit those helpers into every object file that uses them. That way there will never be undefined helper references. It means you'd have to change the multiobj pass to attach additional symbols to a function.

[dnadlinger]

Those "random object" issues have been quite a bit of trouble for LDC in the past (in a slightly different situation related to templates), because for us one of the modules that happened to be selected quite often was std.net.curl. This of course created the familiar linking hell even for programs that were not actually using curl.

[9rnsr]

Ah... I finally understand the issue that you concern. I didn't consider the situation to construct a library file from by collecting the generated object files by dmd -c, so I usually use only dmd.
Indeed the constructed library file will contain comdat module helpers randomly, then linker will pull random object files for them. The unstable behavior would be problematic.

So it doesn't completely fix Issue 14828.

But the sentence is not still understandable to me. The comdat module helpers essentially won't cause duplicated symbols. Do you mean issue 14748 (unintentional binary size bloating)?

[9rnsr]

@MartinNowak Could you please answer my question?

[9rnsr]

@MartinNowak Ping. I'm waiting you in order to close this PR.

[WalterBright]

I'll close it.