Thread overview
dlib 0.19.1 seems to be failing linking with ldc2
Jul 31, 2020
jeff thompson
Jul 31, 2020
jeff thompson
Jul 31, 2020
Dennis
Jul 31, 2020
jeff thompson
Aug 03, 2020
jeff thompson
July 31, 2020
Hello

Im using dlib 0.19.1 with a project and compiling with ldc2 1.22 its failing with the error below. This works fine with the latest dmd version. My targetType is a static lib, only other dependencies are latest bindbc-glfw and bindbc-gl

Performing "debug" build using ldc2.exe for x86_64.
dlib ~master: target for configuration "library" is up to date.
sandbox ~master: building configuration "application"...
Linking...
dlib.lib(dlib.audio.io.wav.obj) : error LNK2019: unresolved external symbol _D4core8internal7switch___T14__switch_errorZQrFNaNbNiNfAyamZv referenced in function _D3std6format__T10printFloatTfTaZQrFNaNfNkAafSQBsQBr__T10FormatSpecTaZQpEQCtQCs12RoundingModeZQCa
dlib.lib(dlib.filesystem.local.obj) : error LNK2001: unresolved external symbol _D4core8internal7switch___T14__switch_errorZQrFNaNbNiNfAyamZv
.dub\build\application-debug-windows-x86_64-ldc_2092-316AB5B187D20C1F6AFBA496E604908D\test.exe : fatal error LNK1120: 1 unresolved externals

Anyone else seeing this?
July 31, 2020
Also this is on x86_x64 box and the 2019 MSVC toolchain


July 31, 2020
On Friday, 31 July 2020 at 14:17:14 UTC, jeff thompson wrote:
> dlib.lib(dlib.audio.io.wav.obj) : error LNK2019: unresolved external symbol _D4core8internal7switch___T14__switch_errorZQrFNaNbNiNfAyamZv referenced in function _D3std6format__T10printFloatTfTaZQrFNaNfNkAafSQBsQBr__T10FormatSpecTaZQpEQCtQCs12RoundingModeZQCa
> dlib.lib(dlib.filesystem.local.obj) : error LNK2001: unresolved external symbol _D4core8internal7switch___T14__switch_errorZQrFNaNbNiNfAyamZv
> .dub\build\application-debug-windows-x86_64-ldc_2092-316AB5B187D20C1F6AFBA496E604908D\test.exe : fatal error LNK1120: 1 unresolved externals


The first thing you want to do is demangle the symbols so you know what they really are.
You can use the tool `ddemangle` for that:
```
echo '_D3std6format__T10printFloatTfTaZQrFNaNfNkAafSQBsQBr__T10FormatSpecTaZQpEQCtQCs12RoundingModeZQCa' | ddemangle
```

You'll find that this symbol is missing:

pure nothrow @nogc @safe void core.internal.switch_.__switch_error!().__switch_error(immutable(char)[], ulong)

And it's used in this function:

pure @safe char[] std.format.printFloat!(float, char).printFloat(return char[], float, std.format.FormatSpec!(char).FormatSpec, std.format.RoundingMode)

The switch_error function is called when none of the cases of a `final switch` apply. There is a final switch in std.format.printFloat:
https://github.com/ldc-developers/phobos/blob/c43cafe53746a07dee8fa9e00d3a2256c7f05506/std/format.d#L7096

So why is the compiler not emitting the final switch error template function? I am not sure, it could be a bug, or maybe you have some funky dub settings. You might be able to work around this by defining a final switch in you own code somewhere, or explicitly defining the function.

```
pragma(mangle, "_D4core8internal7switch___T14__switch_errorZQrFNaNbNiNfAyamZv")
void switchError(string file, ulong line) {
    assert(0, file);
}
```

I hope someone else with more familiarity of how template symbols are emitted can find the root of this problem and give a proper fix.

July 31, 2020
On Friday, 31 July 2020 at 20:07:26 UTC, Dennis wrote:
> On Friday, 31 July 2020 at 14:17:14 UTC, jeff thompson wrote:
>> dlib.lib(dlib.audio.io.wav.obj) : error LNK2019: unresolved external symbol _D4core8internal7switch___T14__switch_errorZQrFNaNbNiNfAyamZv referenced in function _D3std6format__T10printFloatTfTaZQrFNaNfNkAafSQBsQBr__T10FormatSpecTaZQpEQCtQCs12RoundingModeZQCa
>> dlib.lib(dlib.filesystem.local.obj) : error LNK2001: unresolved external symbol _D4core8internal7switch___T14__switch_errorZQrFNaNbNiNfAyamZv
>> .dub\build\application-debug-windows-x86_64-ldc_2092-316AB5B187D20C1F6AFBA496E604908D\test.exe : fatal error LNK1120: 1 unresolved externals
>
>
> The first thing you want to do is demangle the symbols so you know what they really are.
> You can use the tool `ddemangle` for that:
> ```
> echo '_D3std6format__T10printFloatTfTaZQrFNaNfNkAafSQBsQBr__T10FormatSpecTaZQpEQCtQCs12RoundingModeZQCa' | ddemangle
> ```
>
> You'll find that this symbol is missing:
>
> pure nothrow @nogc @safe void core.internal.switch_.__switch_error!().__switch_error(immutable(char)[], ulong)
>
> And it's used in this function:
>
> pure @safe char[] std.format.printFloat!(float, char).printFloat(return char[], float, std.format.FormatSpec!(char).FormatSpec, std.format.RoundingMode)
>
> The switch_error function is called when none of the cases of a `final switch` apply. There is a final switch in std.format.printFloat:
> https://github.com/ldc-developers/phobos/blob/c43cafe53746a07dee8fa9e00d3a2256c7f05506/std/format.d#L7096
>
> So why is the compiler not emitting the final switch error template function? I am not sure, it could be a bug, or maybe you have some funky dub settings. You might be able to work around this by defining a final switch in you own code somewhere, or explicitly defining the function.
>
> ```
> pragma(mangle, "_D4core8internal7switch___T14__switch_errorZQrFNaNbNiNfAyamZv")
> void switchError(string file, ulong line) {
>     assert(0, file);
> }
> ```
>
> I hope someone else with more familiarity of how template symbols are emitted can find the root of this problem and give a proper fix.

Thanks! From looking at it, isn't happening in dlib.lib(dlib.audio.io.wav.obj)? Also this is with a test program with nothing but an empty main and a dependency on dlib 0.19.1. I  guess ill post something in their github since it does compile and link with dmd
August 03, 2020
On Friday, 31 July 2020 at 22:26:26 UTC, jeff thompson wrote:
> On Friday, 31 July 2020 at 20:07:26 UTC, Dennis wrote:
>> On Friday, 31 July 2020 at 14:17:14 UTC, jeff thompson wrote:
>>> dlib.lib(dlib.audio.io.wav.obj) : error LNK2019: unresolved external symbol _D4core8internal7switch___T14__switch_errorZQrFNaNbNiNfAyamZv referenced in function _D3std6format__T10printFloatTfTaZQrFNaNfNkAafSQBsQBr__T10FormatSpecTaZQpEQCtQCs12RoundingModeZQCa
>>> dlib.lib(dlib.filesystem.local.obj) : error LNK2001: unresolved external symbol _D4core8internal7switch___T14__switch_errorZQrFNaNbNiNfAyamZv
>>> .dub\build\application-debug-windows-x86_64-ldc_2092-316AB5B187D20C1F6AFBA496E604908D\test.exe : fatal error LNK1120: 1 unresolved externals
>>
>>
>> The first thing you want to do is demangle the symbols so you know what they really are.
>> You can use the tool `ddemangle` for that:
>> ```
>> echo '_D3std6format__T10printFloatTfTaZQrFNaNfNkAafSQBsQBr__T10FormatSpecTaZQpEQCtQCs12RoundingModeZQCa' | ddemangle
>> ```
>>
>> You'll find that this symbol is missing:
>>
>> pure nothrow @nogc @safe void core.internal.switch_.__switch_error!().__switch_error(immutable(char)[], ulong)
>>
>> And it's used in this function:
>>
>> pure @safe char[] std.format.printFloat!(float, char).printFloat(return char[], float, std.format.FormatSpec!(char).FormatSpec, std.format.RoundingMode)
>>
>> The switch_error function is called when none of the cases of a `final switch` apply. There is a final switch in std.format.printFloat:
>> https://github.com/ldc-developers/phobos/blob/c43cafe53746a07dee8fa9e00d3a2256c7f05506/std/format.d#L7096
>>
>> So why is the compiler not emitting the final switch error template function? I am not sure, it could be a bug, or maybe you have some funky dub settings. You might be able to work around this by defining a final switch in you own code somewhere, or explicitly defining the function.
>>
>> ```
>> pragma(mangle, "_D4core8internal7switch___T14__switch_errorZQrFNaNbNiNfAyamZv")
>> void switchError(string file, ulong line) {
>>     assert(0, file);
>> }
>> ```
>>
>> I hope someone else with more familiarity of how template symbols are emitted can find the root of this problem and give a proper fix.
>
> Thanks! From looking at it, isn't happening in dlib.lib(dlib.audio.io.wav.obj)? Also this is with a test program with nothing but an empty main and a dependency on dlib 0.19.1. I
>  guess ill post something in their github since it does compile and link with dmd

Ok so the scenario is a dub project A that has a dependency on another dub project B who is using dlib. Compiling project A with the dependency with ldc produces the error