www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.ldc - Linking with MSVC built static library

reply 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.
Mar 15
parent reply 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.
Mar 15
parent reply 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 :(
Mar 16
parent reply 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.
Mar 16
next sibling parent Mihails <a a.a> writes:
Seems to have helped. Thanks! No way I would figure out this 
stuff out myself :)
Mar 18
prev sibling parent reply 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?
Mar 19
parent reply 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.
Mar 19
parent reply 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.
Mar 20
parent 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. :)
Mar 20