Hello, are there any specific requirements for linking with MSVC .lib?

I am trying a somewhat naive approach:

- build C library separately with VS (generates "mylib\x64\Release\mylib.lib")
- specify `libs "mylib\\x64\\Release\\mylib"` in dub.sdl
- use `extern(C)` declaration in one of D modules
- run regular `dub build -a x86_64`

It fails with this linker error:

lld-link: error: unknown file type: x64\Release\wrapper.obj

Is there anything I am missing? I am not too familiar with Windows build process in general.

On Friday, 15 March 2019 at 13:32:04 UTC, Mihails wrote:
> Hello, are there any specific requirements for linking with MSVC .lib?

Nope, none at all. LDC itself used to be built as a mix of VS .lib and D code for a while (nowadays we use clang).

> It fails with this linker error:
>
> lld-link: error: unknown file type: x64\Release\wrapper.obj

I guess there's something wrong with your dub config. You can use `-v` in the dub cmdline to see the LDC command lines.

On Friday, 15 March 2019 at 14:19:01 UTC, kinke wrote:
> I guess there's something wrong with your dub config. You can use `-v` in the dub cmdline to see the LDC command lines.

You can check full build verbose log here https://dev.azure.com/mihails-strasuns/github/_build/results?buildId=259 and dub.sdl here https://github.com/mihails-strasuns/dc/blob/7z-lib/dub.sdl

Can't spot anything meaningful in the build log myself :(

On Saturday, 16 March 2019 at 12:03:03 UTC, Mihails wrote:
> Can't spot anything meaningful in the build log myself :(

Me neither, so I cloned your repo and checked it locally.

1) It works in a VS command prompt, i.e., when using the MS linker and libs. The failure is related to the 'internal' toolchain with LLD and the MinGW-based libs.
2) The 'unknown file type .obj' error is apparently related to the used /GL (whole-program optimization) compile option. LLD doesn't support link.exe's /LTCG switch for link-time code generation.
3) After removing /GL, there are linker errors wrt. __security_cookie etc., as the MinGW-based libs don't contain these. This requires disabling the security checks via /GS-. Linking then finally works.
4) I recommend using /ZI (omit default library name) and /MT (static release runtime) so that the C(++) libs link without warnings against D code, regardless of the used -mscrtlib option.

Seems to have helped. Thanks! No way I would figure out this stuff out myself :)

On Saturday, 16 March 2019 at 14:27:55 UTC, kinke wrote:
> On Saturday, 16 March 2019 at 12:03:03 UTC, Mihails wrote:
>> Can't spot anything meaningful in the build log myself :(
>
> Me neither, so I cloned your repo and checked it locally.


Hm, there seems to be one more issue now - it does link but resulting program fails during `dub test` with an unrelated stack trace:

std.exception.ErrnoException@D:\a\1\s\ldc\ldc2-1.14.0-windows-x64\bin\..\import\std\stdio.d(2977): Enforcement failed (Bad file descriptor)
----------------
0x00007FF771B15369 in std.exception.bailOut!(ErrnoException) at D:\a\1\s\ldc\ldc2-1.14.0-windows-x64\import\std\exception.d(516)
0x00007FF771B151F3 in std.exception.enforce!(ErrnoException).enforce!int at D:\a\1\s\ldc\ldc2-1.14.0-windows-x64\import\std\exception.d(437)
0x00007FF771B1506E in std.stdio.File.LockingTextWriter.put!string at D:\a\1\s\ldc\ldc2-1.14.0-windows-x64\import\std\stdio.d(2977)
0x00007FF771B14F46 in std.stdio.writeln!string at D:\a\1\s\source\dc\compilers\common.d(3901)
0x00007FF771B1F47D in dub_test_root.D main at C:\Users\VSSADM~1\AppData\Local\Temp\dub_test_root_37814547_9f10_4067_8666_bf46365d753b.d(19)
0x00007FF771B3B5AD in void rt.dmain2._d_run_main(int, char**, extern (C) int function(char[][])*).runAll()
0x00007FF771B3B44E in d_run_main
0x00007FF771B1FCD7 in __entrypoint.main at D:\a\1\s\__entrypoint.d(8)
0x00007FF771B6FA8A in mainCRTStartup
0x00007FF812D684D4 in BaseThreadInitThunk
0x00007FF81523E851 in RtlUserThreadStart
Program exited with code 1

Actual exported C function is not executed here - just making it referenced from a dead code of main app is sufficient.

Could there be some code corruption caused by wrong linker flags?

On Tuesday, 19 March 2019 at 16:52:35 UTC, Mihails wrote:
> Could there be some code corruption caused by wrong linker flags?

I tested it with v1.15.0-beta1 before; I've just rechecked with v1.14.0 - tests run fine in both a VS command prompt and a naked cmd.exe. FWIW, I'm using VS 2017 v15.9.7 with the aforementioned modifications for both C projects.

On Tuesday, 19 March 2019 at 20:23:18 UTC, kinke wrote:
> On Tuesday, 19 March 2019 at 16:52:35 UTC, Mihails wrote:
>> Could there be some code corruption caused by wrong linker flags?
>
> I tested it with v1.15.0-beta1 before; I've just rechecked with v1.14.0 - tests run fine in both a VS command prompt and a naked cmd.exe. FWIW, I'm using VS 2017 v15.9.7 with the aforementioned modifications for both C projects.

Interesting - it started to work after I changed the build script to run through vcvarsall.bat but was failing in "default" environment despite linking successfully. Probably won't bother trying to figure it out but Windows build process is.. weird.

On Wednesday, 20 March 2019 at 10:22:04 UTC, Mihails wrote:
> Interesting - it started to work after I changed the build script to run through vcvarsall.bat but was failing in "default" environment despite linking successfully. Probably won't bother trying to figure it out but Windows build process is.. weird.

A look into README.txt should help understanding the difference. In short: in order to be independent from the MS toolchain (and their restrictive license), we ship with MSVCRT import libs based on the MinGW-w64 lib definitions and use them, together with LLD as linker, by default. So these libs are kind of reverse-engineered and not the real deal. :)