Linux -> Windows crosscompiler

Marvin G├╝lker via digitalmars-d-ldc digitalmars-d-ldc at
Tue May 16 01:49:36 PDT 2017

On Tue, May 16, 2017 at 08:06:10AM +0000, Joakim via digitalmars-d-ldc wrote:
> How fast is your connection now?  I've been using two connections between
> 2-8 Mbps until recently, so even 16 Mbps seems fast to me. :)

That's indeed fairly slow; the >5 GiB download of MSVC would take very
long on that connection. I'm on 100 MBit/s now (at least they
say...). With such downloads I'm quite happy about that now.

> > I have concluded from that that D+C on Windows doesn't work for me,
> > mostly because MSVC doesn't.
> Sounds like it is the C that is the problem. ;)

Yep. GraphicsMagick wants to be built via a VisualStudio SLN file, and
appearently doesn't work with Visual Studio 2017, because Microsoft
changed some default values on the linker. Visual Studio 2015 has
decided to not let me use it (see my other reply), so all I can do now
is compile it with MinGW/MSYS2's GCC (which worked out of the
box). However, that one in turn does not include GraphicsMagick's
dependencies; copying them out of the MinGW system was possible
(renaming the .a files to .lib), but linking in things like libgomp
fails again (I would have been surprised if linking in GCC internals
with the MSVC linker worked anyway). Then, one shouldn't have to copy
around these files and rename them anyway; it's hackish. In total, I
have invested nearly three days into the issue now, and as much as I
like the D language, I am coming to a point where I conclude that it's
simply not worth further pursueing that. Just doing C/C++ is easier.

Suggestion for LDC: Accept .a files instead of rejecting them only based
on the file extension. Renaming them to .lib usually makes things work
as the MSVC linker link.exe understands them. That would at least
prevent the copy+rename procedure.

(.a is the extension used for static libraries on Unixish systems, and
is used by MinGW/MSYS2 as well)

Next thing I should probably do is report a bug against GraphicsMagick
that it doesn't built with MSVC 2017, but I am too frustrated with the
issue at the moment and they use SourceForge, which I don't want to sign
up at as they recently decided to include Malware into popular
open-source programme's installers.

> An alternative to Visual
> Studio is to download a Windows SDK that included the compiler and linker,
> like the Windows 7.1 SDK that I used years ago:
> I don't know if they still include the compiler/linker in later versions of
> the Windows SDK, maybe one of the newer ones would work too.

That certainly is an interesting suggestion, but since GraphicsMagick
insists on using an SLN file when compiling for MSVC, I don't see how I
could work around installing a full-blown Visual Studio. Once upon a
time, there was an nmake programme that was used for easy commandline
compilation of MSVC projects, but it appears to have become unpopular
(although it is still included in Visual Studio I saw).

> I don't know that you'd have to work on the compiler itself, as ldc used to
> support MinGW at one point.  My guess is that you'd just have to update some
> MinGW stuff in druntime, but I haven't looked at it.

As I explained in my other reply, I could certainly do that, but only as
a project of its own, not as an intermediate step while aiming for
simply developing an ordinary Windows application. I have withdrawn from
my main open-source project[1] recently due to time constraints, and I'm
not able to replace that with another open-source project at the moment.




More information about the digitalmars-d-ldc mailing list