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
