• Mihails (12/12) Mar 15 2019 Hello, are there any specific requirements for linking with MSVC
• kinke (5/9) Mar 15 2019 Nope, none at all. LDC itself used to be built as a mix of VS
• Mihails (4/6) Mar 16 2019 You can check full build verbose log here
• kinke (16/17) Mar 16 2019 Me neither, so I cloned your repo and checked it locally.
• Mihails (2/2) Mar 18 2019 Seems to have helped. Thanks! No way I would figure out this
• Mihails (29/32) Mar 19 2019 Hm, there seems to be one more issue now - it does link but
• kinke (5/7) Mar 19 2019 I tested it with v1.15.0-beta1 before; I've just rechecked with
• Mihails (5/12) Mar 20 2019 Interesting - it started to work after I changed the build script
• kinke (7/12) Mar 20 2019 A look into README.txt should help understanding the difference.

Mihails <a a.a> writes:

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.

kinke <noone nowhere.com> writes:

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.

Mihails <a a.a> writes:

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 :(

kinke <noone nowhere.com> writes:

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.

Mihails <a a.a> writes:

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

Mihails <a a.a> writes:

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\..\impor
\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?

kinke <noone nowhere.com> writes:

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.

Mihails <a a.a> writes:

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.

kinke <noone nowhere.com> writes:

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. :)