Hey all,

I'm trying to get DMD to compile in x64 under Wine but I'm having issues with:

"LLVM ERROR: Could not acquire a cryptographic context: Unknown error (0x80090017)
Stack dump:
0.      Program arguments: C:\D\dmd2\windows\bin\lld-link.exe /NOLOGO test.obj /DEFAULTLIB:phobos64 /OPT:NOICF /LIBPATH:C:\D\dmd2\windows\bin\.
.\lib64\mingw
Error: linker exited with status 1"


The file I'm trying to compile is simply a basic hello world with 1 writeln (compiles fine under Windows).

Compilation string is simply: "wine64 cmd.exe /c 'dmd -m64 .\test.d'".  It works fine if I remove "-m64".


I'm using DMD instead of LDC because the resulting x64 binary doesn't rely on vcruntime140.dll or any other DLLs like LDC does (unless someone knows how to remove this restriction in LDC).

Am I missing something?  It looks like the linker is trying to use cryptographic functions and fatal erroring?  Any tips?

On Tuesday, 29 December 2020 at 17:49:19 UTC, Raikia wrote:
> "LLVM ERROR: Could not acquire a cryptographic context: Unknown error (0x80090017)

I sometimes get this too, it seems to be a bug in wine.

I actually kept an old version of wine around where it works, and a new version side by side...

My old wine-2.6 works fine. My newer wine-5.18 does not and some web searches I did a while ago indicated this was a known regression upstream with them.....

On Tuesday, 29 December 2020 at 18:09:55 UTC, Adam D. Ruppe wrote:
> On Tuesday, 29 December 2020 at 17:49:19 UTC, Raikia wrote:
>> "LLVM ERROR: Could not acquire a cryptographic context: Unknown error (0x80090017)
>
> I sometimes get this too, it seems to be a bug in wine.
>
> I actually kept an old version of wine around where it works, and a new version side by side...
>
> My old wine-2.6 works fine. My newer wine-5.18 does not and some web searches I did a while ago indicated this was a known regression upstream with them.....

So interestingly, I actually got this to work by running "sudo wine" instead of just "wine".  No idea why wine needs root access on the underlying system for wine to operate properly but ok...



Now I'm running into an issue of not having libcmt in Wine so it dynamically links to msvcrt instead (and thus requires a dll on deployment).  Have you come across this before?

On Tuesday, 29 December 2020 at 19:39:14 UTC, Raikia wrote:
> So interestingly, I actually got this to work by running "sudo wine" instead of just "wine".  No idea why wine needs root access on the underlying system for wine to operate properly but ok...

weird. i should try that too later.

> Now I'm running into an issue of not having libcmt in Wine so it dynamically links to msvcrt instead (and thus requires a dll on deployment).  Have you come across this before?

I actually don't know since I haven't distributed a 64 bit exe anywhere except my own laptop which has it installed anyway.

i usually just do 32 bit builds which are pretty reliable.

On Tue, Dec 29, 2020 at 07:39:14PM +0000, Raikia via Digitalmars-d-learn wrote: [...]
> So interestingly, I actually got this to work by running "sudo wine" instead of just "wine".  No idea why wine needs root access on the underlying system for wine to operate properly but ok...
> 
> Now I'm running into an issue of not having libcmt in Wine so it dynamically links to msvcrt instead (and thus requires a dll on deployment).  Have you come across this before?

Haven't come across this myself, but I'd mention that if what you're interested in is to cross-compile from Posix to Windows, you should really consider using LDC instead, which has cross-compilation built-in, and the Windows version comes bundled with all the necessary libraries to compile and link a runnable executable without needing to download additional libraries (unless your own code uses additional libraries).

Some time ago I wanted to compile a Linux app for Windows user, so I tried using Wine with the Windows version of DMD.  It worked, but it was klunky, and prone to breakages like the ones you describe.  Eventually, I gave up and used LDC instead, and it's been working very well.  Here's my setup:

1) Install LDC, Linux version. Let's say for illustration purposes this is in /usr/local/ldc/linux.

2) Download and unpack LDC, Windows version. Let's say you put this in /usr/local/ldc/windows.

3) Edit ldc2.conf for the Linux version (probably in /usr/local/ldc/linux/etc/ldc2.conf), and add this block to the bottom of the file, so that LDC will find the right Windows libraries to link to:

	"(i686|x86_64)-.*-windows.msvc":
	{
	    switches = [
		"-defaultlib=phobos2-ldc,druntime-ldc",
		"-link-defaultlib-shared=false",
	    ];
	    lib-dirs = [
		"/usr/local/ldc/windows/lib",
	    ];
	};

4) Compile your program with:

	ldc2 -mtriple=x86_64-windows-msvc ... # rest of flags, files, etc.

This produces a Windows executable that you can run directly on Windows (or even in Wine) without any additional hassles.


T

-- 
Life would be easier if I had the source code. -- YHL

On Tuesday, 29 December 2020 at 20:29:15 UTC, H. S. Teoh wrote:
> On Tue, Dec 29, 2020 at 07:39:14PM +0000, Raikia via Digitalmars-d-learn wrote: [...]
>> So interestingly, I actually got this to work by running "sudo wine" instead of just "wine".  No idea why wine needs root access on the underlying system for wine to operate properly but ok...
>> 
>> Now I'm running into an issue of not having libcmt in Wine so it dynamically links to msvcrt instead (and thus requires a dll on deployment).  Have you come across this before?
>
> Haven't come across this myself, but I'd mention that if what you're interested in is to cross-compile from Posix to Windows, you should really consider using LDC instead, which has cross-compilation built-in, and the Windows version comes bundled with all the necessary libraries to compile and link a runnable executable without needing to download additional libraries (unless your own code uses additional libraries).
>
> Some time ago I wanted to compile a Linux app for Windows user, so I tried using Wine with the Windows version of DMD.  It worked, but it was klunky, and prone to breakages like the ones you describe.  Eventually, I gave up and used LDC instead, and it's been working very well.  Here's my setup:
>
> 1) Install LDC, Linux version. Let's say for illustration purposes this is in /usr/local/ldc/linux.
>
> 2) Download and unpack LDC, Windows version. Let's say you put this in /usr/local/ldc/windows.
>
> 3) Edit ldc2.conf for the Linux version (probably in /usr/local/ldc/linux/etc/ldc2.conf), and add this block to the bottom of the file, so that LDC will find the right Windows libraries to link to:
>
> 	"(i686|x86_64)-.*-windows.msvc":
> 	{
> 	    switches = [
> 		"-defaultlib=phobos2-ldc,druntime-ldc",
> 		"-link-defaultlib-shared=false",
> 	    ];
> 	    lib-dirs = [
> 		"/usr/local/ldc/windows/lib",
> 	    ];
> 	};
>
> 4) Compile your program with:
>
> 	ldc2 -mtriple=x86_64-windows-msvc ... # rest of flags, files, etc.
>
> This produces a Windows executable that you can run directly on Windows (or even in Wine) without any additional hassles.
>
>
> T

Thanks for that!  That certainly helped, but when running the program on a fresh Windows install, I still get the error "The program can't start because vcruntime140.dll is missing from your computer".  In my (limited) experience, I think its because it is using msvcrt (which is dynamically linked) instead of libcmt (which is static).  If I try to specify libcmt like:

ldc2 -mscrtlib=libcmt -mtriple=x86_64-windows-msvc .\file.d

I get:


ldc2: /build/ldc-vElToV/ldc-1.24.0/driver/linker-msvc.cpp:40: void {anonymous}::addMscrtLibs(bool, std::vector<std::__cxx11::basic_string<char> >&): Assertion `mscrtlibName.contains_lower("vcruntime")' failed.
/lib/x86_64-linux-gnu/libLLVM-11.so.1(_ZN4llvm3sys15PrintStackTraceERNS_11raw_ostreamE+0x1f)[0x7f103b705e7f]
/lib/x86_64-linux-gnu/libLLVM-11.so.1(_ZN4llvm3sys17RunSignalHandlersEv+0x22)[0x7f103b7041b2]
/lib/x86_64-linux-gnu/libLLVM-11.so.1(+0xbd1355)[0x7f103b706355]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x14140)[0x7f103ab04140]
/lib/x86_64-linux-gnu/libc.so.6(gsignal+0x141)[0x7f103a639c41]
/lib/x86_64-linux-gnu/libc.so.6(abort+0x123)[0x7f103a623537]
/lib/x86_64-linux-gnu/libc.so.6(+0x2540f)[0x7f103a62340f]
/lib/x86_64-linux-gnu/libc.so.6(+0x345c2)[0x7f103a6325c2]
ldc2(_Z19linkObjToBinaryMSVCN4llvm9StringRefERKSt6vectorINSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEESaIS7_EE+0x2405)[0x55990ec775b5]
ldc2(_Z15linkObjToBinaryv+0x6b0)[0x55990ec6f710]
ldc2(_Z13mars_mainBodyR5ParamR5ArrayIPKcES5_+0x1719)[0x55990ea4b149]
ldc2(_Z7cppmainv+0x1c88)[0x55990ec7a6d8]
ldc2(_D2rt6dmain212_d_run_main2UAAamPUQgZiZ6runAllMFZv+0x4c)[0x55990edd811c]
ldc2(_d_run_main2+0x198)[0x55990edd7f38]
ldc2(_d_run_main+0x8e)[0x55990edd7d8e]
ldc2(main+0x22d)[0x55990e965c9d]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xea)[0x7f103a624cca]
ldc2(_start+0x2a)[0x55990e967e6a]
Aborted

On Tuesday, 29 December 2020 at 21:13:59 UTC, Raikia wrote:
> That certainly helped, but when running the program on a fresh Windows install, I still get the error "The program can't start because vcruntime140.dll is missing from your computer".  In my (limited) experience, I think its because it is using msvcrt (which is dynamically linked) instead of libcmt (which is static).

The static MS libs cannot be redistributed by 3rd parties thanks to their license, that's why LDC and DMD only come with MinGW-based import libraries depending on an installed MSVC++ runtime. [DMD works with (default) -m32 because that uses Walter's DigitalMars C runtime.]