linking obj files compiled with LDC2 1.20.0 on Win64

[Steven Schveighoffer]

On 3/24/20 10:28 AM, realhet wrote:
> On Sunday, 22 March 2020 at 20:20:17 UTC, Steven Schveighoffer wrote:
>> Make sure you don't have any stale objects left over in your project 
>> from the older build. Build everything clean from scratch.
>>
> 
> After narrowing the problem, I fixed all warnings, and deprecations, and 
> I have only one linker error now:
> 
> Compiler command line (LDC 1.20.0 Win64):
> ldmd2 -vcolumns -c -op -allinst -Ic:\D\libs\ -m64 -mcpu=athlon64-sse3 
> -mattr=+ssse3 -release -O -inline -boundscheck=off 
> c:\D\libs\jsonizer\exceptions.d
> 
> Linker command line:
> link /LIBPATH:c:\D\ldc2\lib64 /OUT:c:\D\libs\het\hdmd\hdmd.exe 
> /MACHINE:X64 kernel32.lib user32.lib legacy_stdio_definitions.lib ***All 
> the required obj files*** druntime-ldc.lib phobos2-ldc.lib msvcrt.lib
> 
> Linker response (after demangling):
> Microsoft (R) Incremental Linker Version 14.23.28105.4
> Copyright (C) Microsoft Corporation.  All rights reserved.
> 
> ---------------------------------------------
> 
> exceptions.obj : error LNK2019: unresolved external symbol
> 
> pure nothrow @nogc @safe void 
> std.format.hasToString!(std.json.JSONValue, char).__lambda2().S.put(char)
> 
> referenced in function
> 
> pure nothrow @nogc @safe void 
> std.range.primitives.put!(std.format.hasToString!(std.json.JSONValue, 
> char).__lambda2().S, char).put(ref 
> std.format.hasToString!(std.json.JSONValue, char).__lambda2().S, char)
> 
> ---------------------------------------------
> 
> I've searched for the hasToString template, but this seems way too 
> complicated for me.
> This nested lambda template thing o.O

Ugh, this is a template constraint. There's no reason to see it in 
compiled code.

> 
> Here is the source code for the exceptions.obj file: 
> https://github.com/rcorre/jsonizer/blob/master/src/jsonizer/exceptions.d
> 
> These are caused by some format() calls, I don't know why it is a 
> problem now and it's totally OK with a 2017 version.
> 
> This nested std.range.primitives.put is weird for me. Maybe it's a bug 
> because by the -CompileAllTemplateInstances flag? (That's not the normal 
> use, I know: I comile all the objs, and while I work, I only compile the 
> ones that changed (recursively ofc), and finally link. It's much faster 
> this way on a 8 core machine.).

I think this might be part of the problem. It's still a bug in the 
compiler, but this unusual way of compiling might be bringing it out. 
Most likely either the mangling is changed when compiling the 
dependency, or the symbol is being incorrectly referenced or incorrectly 
excluded.

If this were Linux, I'd start using nm to search the object files for 
the symbol that is missing (like search for symbols defining 
hasToString), and see if it possibly might be mangled in a different 
way. I'm not sure what tools there are on Windows to do this.

-Steve