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.


Reply via email to