www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - dlib 0.19.1 seems to be failing linking with ldc2

reply jeff thompson <jeff.thompson.sd gmail.com> writes:
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-316AB5B187D20C1F6AFBA
96E604908D\test.exe : fatal error LNK1120: 1 unresolved externals

Anyone else seeing this?
Jul 31 2020
next sibling parent jeff thompson <jeff.thompson.sd gmail.com> writes:
Also this is on x86_x64 box and the 2019 MSVC toolchain
Jul 31 2020
prev sibling parent reply Dennis <dkorpel gmail.com> writes:
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-316AB5B187D20C1F6AFBA
96E604908D\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__T10FormatSpecTaZQpEQCtQC
12RoundingModeZQCa' | 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.
Jul 31 2020
parent reply jeff thompson <jeff.thompson.sd gmail.com> writes:
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-316AB5B187D20C1F6AFBA
96E604908D\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__T10FormatSpecTaZQpEQCtQC
12RoundingModeZQCa' | 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
Jul 31 2020
parent jeff thompson <jeff.thompson.sd gmail.com> writes:
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-316AB5B187D20C1F6AFBA
96E604908D\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__T10FormatSpecTaZQpEQCtQC
12RoundingModeZQCa' | 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
Aug 02 2020