Thread overview
dlib 0.19.1 seems to be failing linking with ldc2
6 days ago
Dennis
6 days ago
jeff thompson
4 days ago
jeff thompson
July 31
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
Also this is on x86_x64 box and the 2019 MSVC toolchain


6 days ago
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.

6 days ago
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
4 days ago
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