www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.ldc - Linux -> Windows crosscompiler

reply Marvin =?utf-8?Q?G=C3=BClker?= via digitalmars-d-ldc writes:
Hi everyone,

I am mainly a Linux developer and find working on Windows rather
complicated. My most recent try confirmed that; I wanted to write a D
application using GraphicsMagick's C interface -- now I have a mixture
of compilers on my Windows machine (MinGW GCC, Msys2 GCC, MSVC, LDC,
DMD) and I still get linking errors.

That only for the context. Since I previously had good experience in
using a Linux -> Windows crosscompiler for regular C/C++ (MXE[1]) I thought
it could be possible to have something similar for D. Until now I have
been using dmd, but Internet research told me dmd cannot be built as a
crosscompiler. GDC appears to be a one-man show and is still pending
upstream GCC approval, so I decided to go with LDC.

Thus, is it possible to build an LDC crosscompiler that is hosted on
x86_64 Linux and targets i686/x86_64 Windows? If so, how? I didn't find
any information on the topic, people appeareantly only ever want to
target ARM (cell phones?), which is not what I am interested in.

Greetings
Marvin

[1]: http://mxe.cc

-- 
Blog: https://www.guelkerdev.de
PGP/GPG ID: F1D8799FBCC8BC4F
May 15 2017
next sibling parent reply Joakim <dlang joakim.fea.st> writes:
On Monday, 15 May 2017 at 09:27:36 UTC, Marvin Gülker wrote:

 Hi everyone,

 I am mainly a Linux developer and find working on Windows 
 rather complicated. My most recent try confirmed that; I wanted 
 to write a D application using GraphicsMagick's C interface -- 
 now I have a mixture of compilers on my Windows machine (MinGW 
 GCC, Msys2 GCC, MSVC, LDC, DMD) and I still get linking errors.


Are you mixing object files produced by different D compilers?  
That won't work, you need to compile all your D code with a 
single D compiler.


 That only for the context. Since I previously had good 
 experience in
 using a Linux -> Windows crosscompiler for regular C/C++ 
 (MXE[1]) I thought
 it could be possible to have something similar for D. Until now 
 I have
 been using dmd, but Internet research told me dmd cannot be 
 built as a
 crosscompiler. GDC appears to be a one-man show and is still 
 pending
 upstream GCC approval, so I decided to go with LDC.


It can be done with dmd, but it would require some work on the 
compiler itself.


 Thus, is it possible to build an LDC crosscompiler that is 
 hosted on x86_64 Linux and targets i686/x86_64 Windows? If so, 
 how? I didn't find any information on the topic, people 
 appeareantly only ever want to target ARM (cell phones?), which 
 is not what I am interested in.


Of course, by default ldc is a cross-compiler for all other 
platforms it officially supports.  You simply need to pass the 
right llvm triple to ldc, similar to how it's done for the ARM 
cross-compiler.

The bigger issue is getting the cross-compiled stdlib and a 
cross-linker, that will link for Windows but run on linux.  You 
can probably just take the pre-built stdlib from the ldc for 
Windows package, but you're on your own for finding a 
cross-linker.  Maybe lld would work?

http://lld.llvm.org
May 15 2017
parent reply Marvin =?utf-8?Q?G=C3=BClker?= via digitalmars-d-ldc writes:
On Mon, May 15, 2017 at 05:37:30PM +0000, Joakim via digitalmars-d-ldc wrote:

 Are you mixing object files produced by different D compilers?  That won't
 work, you need to compile all your D code with a single D compiler.


I'm sorry if I was unclear. No, I don't do that. I have, for the
attempts on native Windows, however tried mixing MinGW/MSYS2 GCC object
files for C code with LDC ones for D code. And I have tried mixing MSVC
object files with LDC ones for D code. The latter worked, but
GraphicsMagick fails to compile with MSVC 2017, and MSVC 2015 is only
crashing for me. I also tried mixing MinGW/MSYS2 GCC object files for C
code with DMD object files for D code, but haven't yet gotten around to
trying it with MSVC C object files since MSVC has stopped working for me
meanwhile.

As a non-Windows dev, this is a quite frustrating experience for me. The
most annoying thing is that whatever one does with the MSVC setup
installer, it takes really, really, really long. It doesn't do anything
under an hour. Why is it distributed as an ISO file that I have to burn
to a DVD first? That slows things further down... Since a few weeks, I
finally have an acceptable Internet connection (was a max 16MBit aDSL
line before), so at least downloading this insane amount of data went
acceptably fast.

I have concluded from that that D+C on Windows doesn't work for me,
mostly because MSVC doesn't.

I'm sorry if I am only complaining all the time. I'm an open-source
developer myself, so I know that users complain all the time about this
or that not fitting their exotic edgecase. I would have to work on LDC
to support MinGW if I wanted it to be otherwise, but given that I have
never worked on a compiler this is going to be difficult (and does not
fit my time constraints).


 It can be done with dmd, but it would require some work on the compiler
 itself.


Likewise.


 Of course, by default ldc is a cross-compiler for all other platforms it
 officially supports.  You simply need to pass the right llvm triple to ldc,
 similar to how it's done for the ARM cross-compiler.


See my reply to the other post; that worked indeed pretty seemless.


 The bigger issue is getting the cross-compiled stdlib and a cross-linker,
 that will link for Windows but run on linux.  You can probably just take the
 pre-built stdlib from the ldc for Windows package, but you're on your own
 for finding a cross-linker.  Maybe lld would work?


Likewise.

Greetings
Marvin

-- 
Blog: https://www.guelkerdev.de
PGP/GPG ID: F1D8799FBCC8BC4F
May 16 2017
parent reply Joakim <dlang joakim.fea.st> writes:
On Tuesday, 16 May 2017 at 07:40:59 UTC, Marvin Gülker wrote:

 On Mon, May 15, 2017 at 05:37:30PM +0000, Joakim via 
 digitalmars-d-ldc wrote:

 Are you mixing object files produced by different D compilers?
  That won't work, you need to compile all your D code with a 
 single D compiler.


 I'm sorry if I was unclear. No, I don't do that. I have, for 
 the attempts on native Windows, however tried mixing 
 MinGW/MSYS2 GCC object files for C code with LDC ones for D 
 code. And I have tried mixing MSVC object files with LDC ones 
 for D code. The latter worked, but GraphicsMagick fails to 
 compile with MSVC 2017, and MSVC 2015 is only crashing for me. 
 I also tried mixing MinGW/MSYS2 GCC object files for C code 
 with DMD object files for D code, but haven't yet gotten around 
 to trying it with MSVC C object files since MSVC has stopped 
 working for me meanwhile.


OK, sometimes mixing D compilers is the problem, so thought I'd 
mention it.


 As a non-Windows dev, this is a quite frustrating experience 
 for me. The most annoying thing is that whatever one does with 
 the MSVC setup installer, it takes really, really, really long. 
 It doesn't do anything under an hour. Why is it distributed as 
 an ISO file that I have to burn to a DVD first? That slows 
 things further down... Since a few weeks, I finally have an 
 acceptable Internet connection (was a max 16MBit aDSL line 
 before), so at least downloading this insane amount of data 
 went acceptably fast.


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


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

http://forum.dlang.org/post/hvdyyutbgehlefluvsup forum.dlang.org

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.


 I'm sorry if I am only complaining all the time. I'm an 
 open-source developer myself, so I know that users complain all 
 the time about this or that not fitting their exotic edgecase. 
 I would have to work on LDC to support MinGW if I wanted it to 
 be otherwise, but given that I have never worked on a compiler 
 this is going to be difficult (and does not fit my time 
 constraints).


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.


 The bigger issue is getting the cross-compiled stdlib and a 
 cross-linker, that will link for Windows but run on linux.  
 You can probably just take the pre-built stdlib from the ldc 
 for Windows package, but you're on your own for finding a 
 cross-linker.  Maybe lld would work?


 Likewise.


This is likely not so bad, you simply have to use -v to see the 
linker command ldc tries to invoke and replace it by manually 
running with lld instead, especially since it's only needed once 
for the final executable.
May 16 2017
next sibling parent reply Paolo Invernizzi <paolo.invernizzi gmail.com> writes:
On Tuesday, 16 May 2017 at 08:06:10 UTC, Joakim wrote:

 On Tuesday, 16 May 2017 at 07:40:59 UTC, Marvin Gülker wrote:

 [...]


 OK, sometimes mixing D compilers is the problem, so thought I'd 
 mention it.


 [...]


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


 [...]


 Sounds like it is the C that is the problem. ;) 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:

 http://forum.dlang.org/post/hvdyyutbgehlefluvsup forum.dlang.org

 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.


 [...]


 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.


 [...]


 This is likely not so bad, you simply have to use -v to see the 
 linker command ldc tries to invoke and replace it by manually 
 running with lld instead, especially since it's only needed 
 once for the final executable.


I successfully cross compiled a simple "hello world" application 
on my Mac using something like:

    ldc2 -c -mtriple=x86_64-pc-windows-msvc main.d
    LIB=vc/lib lld-link main.obj ldc2_win/lib64/phobos2-ldc.lib 
ldc2_win/lib64/druntime-ldc.lib vc/lib/msvcrt.lib

where I've copied a bunch of libraries in vc/lib, like the 
mscvrt.lib, shell32.lib etc, coming out from a previous wine 
attempt to use the microsoft linker in a dockerised environment.

/Paolo
May 16 2017
next sibling parent reply Marvin =?utf-8?Q?G=C3=BClker?= via digitalmars-d-ldc writes:
On Tue, May 16, 2017 at 08:22:04AM +0000, Paolo Invernizzi via
digitalmars-d-ldc wrote:

 I successfully cross compiled a simple "hello world" application on my Mac
 using something like:
 
    ldc2 -c -mtriple=x86_64-pc-windows-msvc main.d
    LIB=vc/lib lld-link main.obj ldc2_win/lib64/phobos2-ldc.lib
 ldc2_win/lib64/druntime-ldc.lib vc/lib/msvcrt.lib
 
 where I've copied a bunch of libraries in vc/lib, like the mscvrt.lib,
 shell32.lib etc, coming out from a previous wine attempt to use the
 microsoft linker in a dockerised environment.


Very nice. Thank you for the information; so lld does work. I have no
doubts it will do it on Linux as well.

Greetings
Marvin

-- 
Blog: https://www.guelkerdev.de
PGP/GPG ID: F1D8799FBCC8BC4F
May 16 2017
parent Paolo Invernizzi <paolo.invernizzi gmail.com> writes:
On Tuesday, 16 May 2017 at 08:53:32 UTC, Marvin Gülker wrote:

 On Tue, May 16, 2017 at 08:22:04AM +0000, Paolo Invernizzi via 
 digitalmars-d-ldc wrote:

 I successfully cross compiled a simple "hello world" 
 application on my Mac using something like:
 
    ldc2 -c -mtriple=x86_64-pc-windows-msvc main.d
    LIB=vc/lib lld-link main.obj ldc2_win/lib64/phobos2-ldc.lib
 ldc2_win/lib64/druntime-ldc.lib vc/lib/msvcrt.lib
 
 where I've copied a bunch of libraries in vc/lib, like the 
 mscvrt.lib, shell32.lib etc, coming out from a previous wine 
 attempt to use the microsoft linker in a dockerised 
 environment.


 Very nice. Thank you for the information; so lld does work. I 
 have no doubts it will do it on Linux as well.

 Greetings
 Marvin


Just a little change, I've used libcmt.lib and not msvcrt.lib...

/P
May 16 2017
prev sibling parent reply kinke <noone nowhere.com> writes:
On Tuesday, 16 May 2017 at 08:22:04 UTC, Paolo Invernizzi wrote:

 I successfully cross compiled a simple "hello world" 
 application on my Mac using something like:

    ldc2 -c -mtriple=x86_64-pc-windows-msvc main.d
    LIB=vc/lib lld-link main.obj ldc2_win/lib64/phobos2-ldc.lib 
 ldc2_win/lib64/druntime-ldc.lib vc/lib/msvcrt.lib

 where I've copied a bunch of libraries in vc/lib, like the 
 mscvrt.lib, shell32.lib etc, coming out from a previous wine 
 attempt to use the microsoft linker in a dockerised environment.


This is being automated as part of integrating LLD into LDC. 
Here's how you'll be able to cross-compile and -link from any 
host to 32/64-bit MSVC targets: 
https://github.com/ldc-developers/ldc/pull/2142#issuecomment-304472412
May 27 2017
next sibling parent Marvin =?utf-8?Q?G=C3=BClker?= via digitalmars-d-ldc writes:
Hi,

On Sat, May 27, 2017 at 11:33:26PM +0000, kinke via digitalmars-d-ldc wrote:

 This is being automated as part of integrating LLD into LDC. Here's how
 you'll be able to cross-compile and -link from any host to 32/64-bit MSVC
 targets:
 https://github.com/ldc-developers/ldc/pull/2142#issuecomment-304472412


This looks promising. Thank you for the work and the instructions! As
for redistributing the MS libs, I think the best solution is to "simply"
ask Microsoft and get an approval from their legal department.

Obviously, the alternate solution is to rely on the open-source
GCC/MinGW/MSYS2 toolchain for crosscompilation, which is not going to
cause a licensing problem. I understand that this does not work with the
current state of affairs, but I wanted to mention it for completeness.

Greetings
Marvin

-- 
Blog: https://www.guelkerdev.de
PGP/GPG ID: F1D8799FBCC8BC4F
May 28 2017
prev sibling next sibling parent reply David Nadlinger via digitalmars-d-ldc <digitalmars-d-ldc puremagic.com> writes:
Hi Marvin,

On 28 May 2017, at 8:12, Marvin Gülker via digitalmars-d-ldc wrote:

 Obviously, the alternate solution is to rely on the open-source
 GCC/MinGW/MSYS2 toolchain for crosscompilation, which is not going to
 cause a licensing problem. I understand that this does not work with 
 the
 current state of affairs, but I wanted to mention it for completeness.


This is correct. mingw-w64 is actually how we used to target Win64 
before we had MSVC support; fixing Phobos to work with it again wouldn't 
be too much of a hassle. However, it turns out that the vast majority of 
developers prefer using the MSVC toolchain on Windows, apart from 
directly porting *nix code using Cygwin, so it wasn't a priority to 
maintain so far.

However, if you are seriously interested in cross-compiling to Win64, 
you might indeed find it easiest to resurrect the mingw-w64 port (so you 
can easily build a cross-toolchain for C as well). The most 
time-consuming bit would probably just be setting up CI support for it 
to make sure it doesn't regress.

Best,
David
May 29 2017
parent reply kinke <noone nowhere.com> writes:
On Monday, 29 May 2017 at 16:00:24 UTC, David Nadlinger wrote:

 Hi Marvin,

 On 28 May 2017, at 8:12, Marvin Gülker via digitalmars-d-ldc 
 wrote:

 Obviously, the alternate solution is to rely on the open-source
 GCC/MinGW/MSYS2 toolchain for crosscompilation, which is not 
 going to
 cause a licensing problem. I understand that this does not 
 work with the
 current state of affairs, but I wanted to mention it for 
 completeness.


 This is correct. mingw-w64 is actually how we used to target 
 Win64 before we had MSVC support; fixing Phobos to work with it 
 again wouldn't be too much of a hassle. However, it turns out 
 that the vast majority of developers prefer using the MSVC 
 toolchain on Windows, apart from directly porting *nix code 
 using Cygwin, so it wasn't a priority to maintain so far.

 However, if you are seriously interested in cross-compiling to 
 Win64, you might indeed find it easiest to resurrect the 
 mingw-w64 port (so you can easily build a cross-toolchain for C 
 as well). The most time-consuming bit would probably just be 
 setting up CI support for it to make sure it doesn't regress.


I have no idea about GDC support for Windows, but using GDC when 
targeting the GNU toolchain on Windows would be a more natural 
choice IMO. It'd surely be nice if LDC could target windows-gnu 
again, but it's not on my priority list. :]
May 29 2017
parent reply David Nadlinger via digitalmars-d-ldc <digitalmars-d-ldc puremagic.com> writes:
On 29 May 2017, at 19:51, kinke via digitalmars-d-ldc wrote:

 I have no idea about GDC support for Windows


There is none. (Well, depending on the definition of course, but it's no 
better than currently almost-working LDC/mingw-w64.)


 using GDC when targeting the GNU toolchain on Windows would be a more 
 natural choice IMO.


Why would you think so? Apart from the first letter in the name, there 
shouldn't be any reason making LDC a less natural choice for mingw-w64.

  — David
May 30 2017
parent kinke <noone nowhere.com> writes:
On Tuesday, 30 May 2017 at 09:58:57 UTC, David Nadlinger wrote:

 On 29 May 2017, at 19:51, kinke via digitalmars-d-ldc wrote:

 using GDC when targeting the GNU toolchain on Windows would be 
 a more natural choice IMO.


 Why would you think so? Apart from the first letter in the 
 name, there shouldn't be any reason making LDC a less natural 
 choice for mingw-w64.


Same backend as the MinGW C(++) compiler, so ABI issues etc. 
should be harder to come by. Although I admittedly gained some 
more confidence wrt. ABI coverage in the full testsuite. ;)
May 30 2017
prev sibling next sibling parent Marvin =?utf-8?Q?G=C3=BClker?= via digitalmars-d-ldc writes:
On Mon, May 29, 2017 at 05:00:24PM +0100, David Nadlinger via digitalmars-d-ldc
wrote:

 However, if you are seriously interested in cross-compiling to Win64, you
 might indeed find it easiest to resurrect the mingw-w64 port (so you can
 easily build a cross-toolchain for C as well). The most time-consuming bit
 would probably just be setting up CI support for it to make sure it doesn't
 regress.


I will come back to the topic at some point, including investigation of
GDC, but as I said earlier I currently don't have enough spare time
available. Still, thank you all for the pretty informative discussion in
this thread, I've learned quite a bit about the LDC universe.

Greetings
Marvin

-- 
Blog: https://www.guelkerdev.de
PGP/GPG ID: F1D8799FBCC8BC4F
May 29 2017
prev sibling parent David Nadlinger via digitalmars-d-ldc <digitalmars-d-ldc puremagic.com> writes:
Hi Marvin,

On 30 May 2017, at 7:36, Marvin Gülker via digitalmars-d-ldc wrote:

 […] as I said earlier I currently don't have enough spare time
 available.


In the time it took you to participate in this thread, you could have 
probably fixed mingw-w64 support. It really isn't a lot of work. ;)


 Still, thank you all for the pretty informative discussion in
 this thread, I've learned quite a bit about the LDC universe.


You're very welcome! Keep us posted if you have any further questions.

  — David
May 30 2017
prev sibling parent reply Marvin =?utf-8?Q?G=C3=BClker?= via digitalmars-d-ldc writes:
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:
 
 http://forum.dlang.org/post/hvdyyutbgehlefluvsup forum.dlang.org
 
 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.

Greetings
Marvin

[1]: https://secretchronicles.org/en/

-- 
Blog: https://www.guelkerdev.de
PGP/GPG ID: F1D8799FBCC8BC4F
May 16 2017
parent Joakim <dlang joakim.fea.st> writes:
On Tuesday, 16 May 2017 at 08:49:36 UTC, Marvin Gülker wrote:

 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'm on a faster connection now, 15-20 Mbps or so, but that's only 
since six months ago.


 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.


Again, mostly C that's the issue.  Of course, ldc not officially 
supporting MingGW anymore affects the particular C library you're 
trying to use.


 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:
 
 http://forum.dlang.org/post/hvdyyutbgehlefluvsup forum.dlang.org
 
 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 think it's included with the Windows SDK I used too, but I 
guess that won't help you with the SLN either.
May 16 2017
prev sibling parent reply kinke <noone nowhere.com> writes:
On Monday, 15 May 2017 at 09:27:36 UTC, Marvin Gülker wrote:

 Hi everyone,

 I am mainly a Linux developer and find working on Windows 
 rather complicated. My most recent try confirmed that; I wanted 
 to write a D application using GraphicsMagick's C interface -- 
 now I have a mixture of compilers on my Windows machine (MinGW 
 GCC, Msys2 GCC, MSVC, LDC, DMD) and I still get linking errors.

 That only for the context. Since I previously had good 
 experience in
 using a Linux -> Windows crosscompiler for regular C/C++ 
 (MXE[1]) I thought
 it could be possible to have something similar for D. Until now 
 I have
 been using dmd, but Internet research told me dmd cannot be 
 built as a
 crosscompiler. GDC appears to be a one-man show and is still 
 pending
 upstream GCC approval, so I decided to go with LDC.

 Thus, is it possible to build an LDC crosscompiler that is 
 hosted on x86_64 Linux and targets i686/x86_64 Windows? If so, 
 how? I didn't find any information on the topic, people 
 appeareantly only ever want to target ARM (cell phones?), which 
 is not what I am interested in.

 Greetings
 Marvin

 [1]: http://mxe.cc


It should indeed be possible today. For LDC, MinGW was once 
supported but isn't anymore [although fixing that shouldn't be 
that hard]. We chose to focus on the 'native' path on Windows, 
centered around Microsoft's Visual C++ (its C runtime and its 
toolchain). So if you are fine with that, all you basically need 
is

a) an MS-compatible cross-linker (LLVM's lld),
b) druntime and Phobos compiled for Windows (you could just copy 
them from a Windows release package), and
c) a bunch of MS libs (WinSDK + Visual C++ ones)

while specifying something like `-mtriple=x86_64-pc-windows-msvc` 
in the LDC command line.
There's one catch though: you currently cannot specify an 
alternative external linker to be used for MSVC targets 
(`link.exe` is hardcoded), so you'd have to link manually or hack 
the LDC source. Generating static libs only is supported for any 
target starting with LDC 1.3.
Oh and lld isn't able to produce .pdb debuginfos at the moment. 
The plan is to integrate lld in LDC at some point, see 
https://github.com/ldc-developers/ldc/issues/2028.
May 15 2017
parent reply Marvin =?utf-8?Q?G=C3=BClker?= via digitalmars-d-ldc writes:
Hi,

On Mon, May 15, 2017 at 05:58:22PM +0000, kinke via digitalmars-d-ldc wrote:

 It should indeed be possible today. For LDC, MinGW was once supported but
 isn't anymore [although fixing that shouldn't be that hard]. We chose to
 focus on the 'native' path on Windows, centered around Microsoft's Visual
 C++ (its C runtime and its toolchain). So if you are fine with that,


Well, "fine" does not exactly fit it. I am impressed by the pure size of
the installation as such. It took over three hours to install MSVC
(kinda slow hard drive) on my Windows 7 system, and it now crashes on
startup with a COM exception whenever I open an SLN file. And all I want
is just a compiler+linker...


 all you basically need is
 
 a) an MS-compatible cross-linker (LLVM's lld),


That looks doable.


 b) druntime and Phobos compiled for Windows (you could just copy them from a
 Windows release package),


Okay. Ideally, of course, they could be crosscompiled as well.


 and
 c) a bunch of MS libs (WinSDK + Visual C++ ones)


Is there a list which libraries are required? Is it just those listed
when I run LDC with the "-v" switch?


 while specifying something like `-mtriple=x86_64-pc-windows-msvc` in the LDC
 command line.


I tried, and it correctly output an .obj file that file(1) classifies as
a COFF library file. Naturally, it does not do linking, most likely to
the problem you described here:


 There's one catch though: you currently cannot specify an alternative
 external linker to be used for MSVC targets (`link.exe` is hardcoded),


The command silently fails, i.e., it does not even print an error
message:

    % ldc2 -mtriple=i686-pc-windows-msvc hello.d
    % echo $?
    255

At least a short note that link(.exe) could not be found would be
appropriate I think.

As mentioned, the compilation as such appears to be successful and
results in an obj file to be created:

    % ls -hl
    insgesamt 16K
    -rw-r--r-- 1 user users   73 16. Mai 08:50 hello.d
    -rw-r--r-- 1 user users 8,4K 16. Mai 08:51 hello.obj
    % file hello.obj
    hello.obj: Intel 80386 COFF object file, not stripped, 29 sections,
    symbol offset=0x1124, 111 symbols

(hello.d is a simple hello world programme in D)


 so you'd have to link manually or hack the LDC source. Generating
 static libs only is supported for any target starting with LDC 1.3.


For reference, I used this ldc for my tests:

    % ldc2 -version
    LDC - the LLVM D compiler (1.2.0):
      based on DMD v2.072.2 and LLVM 3.9.1
      built with DMD64 D Compiler v2.072.2
      Default target: x86_64-pc-linux-gnu
      Host CPU: ivybridge
      http://dlang.org - http://wiki.dlang.org/LDC

      Registered Targets:
        amdgcn  - AMD GCN GPUs
        bpf     - BPF (host endian)
        bpfeb   - BPF (big endian)
        bpfel   - BPF (little endian)
        nvptx   - NVIDIA PTX 32-bit
        nvptx64 - NVIDIA PTX 64-bit
        r600    - AMD GPUs HD2XXX-HD6XXX
        x86     - 32-bit X86: Pentium-Pro and above
        x86-64  - 64-bit X86: EM64T and AMD64


 Oh and lld isn't able to produce .pdb debuginfos at the moment. The plan is
 to integrate lld in LDC at some point, see
 https://github.com/ldc-developers/ldc/issues/2028.


Will the integration of lld remove the dependency on MSVC's link.exe? In
that case, crosscompilation to Windows would probably be easier.

Thank you both for your suggestions. I may fiddle with the topic further
by investigating lld, but if it is about to be integrated into LDC
anyway, I may also just wait for that to happen. I however realised that
there is an additional problem; I would have to crosscompile my C
dependencies as well, targetting MSVC. That is not possible as of now to
my knowledge. One can crosscompile targetting MinGW (MXE does a great
job here), but not targetting MSVC. Even if it would be, I bet that
people's build systems do not cover that case and thereby cause a lot of
work on each dependant project's build system for me, which I don't have
the time for.

Greetings
Marvin

-- 
Blog: https://www.guelkerdev.de
PGP/GPG ID: F1D8799FBCC8BC4F
May 16 2017
parent reply kinke <kinke gmx.net> writes:
On Tuesday, 16 May 2017 at 07:16:37 UTC, Marvin Gülker wrote:

 I however realised that there is an additional problem; I would 
 have to crosscompile my C dependencies as well, targetting 
 MSVC. That is not possible as of now to my knowledge. One can 
 crosscompile targetting MinGW (MXE does a great job here), but 
 not targetting MSVC. Even if it would be, I bet that people's 
 build systems do not cover that case and thereby cause a lot of 
 work on each dependant project's build system for me, which I 
 don't have the time for.


Yeah, that's what I meant by whether you are fine with the 
toolchain. clang does an excellent job at compiling gcc-style 
code (incl. pragmas and special attributes) for MSVC; I used it a 
few years back to compile parts of the MinGW C runtime itself. 
Just saying that it would be possible. ;)
May 16 2017
parent reply Marvin =?utf-8?Q?G=C3=BClker?= via digitalmars-d-ldc writes:
On Tue, May 16, 2017 at 07:49:53AM +0000, kinke via digitalmars-d-ldc wrote:

 Yeah, that's what I meant by whether you are fine with the toolchain.


Heh. After running MSVC Setup's "Repair" program (which, again, took an
hour or so) Visual Studio now starts. And then closes with the message
"Your evaluation time span has expired" (although I never even used
it). I don't think I'm going to feel familiar with MSVC at any point in
time. What a crude world Windows is.


 clang does an excellent job at compiling gcc-style code (incl. pragmas
 and special attributes) for MSVC; I used it a few years back to
 compile parts of the MinGW C runtime itself. Just saying that it would
 be possible. ;)


Yeah, I know, it's possible :-). It's just a question of how much time I
want to investigate. But honestly, for this one programme I want to run
on Windows, it will take less time if I write it in C/C++ and
crosscompile it with MXE (or compile it natively with MSYS2), even if D
is a nicer language. If I find fun in developing on LDC, that's
something different, but as only an intermediate goal I'm not willing to
investigate that much.

Greetings
Marvin

-- 
Blog: https://www.guelkerdev.de
PGP/GPG ID: F1D8799FBCC8BC4F
May 16 2017
parent Mike Parker <aldacron gmail.com> writes:
On Tuesday, 16 May 2017 at 08:25:46 UTC, Marvin Gülker wrote:

 On Tue, May 16, 2017 at 07:49:53AM +0000, kinke via 
 digitalmars-d-ldc wrote:

 Yeah, that's what I meant by whether you are fine with the 
 toolchain.


 Heh. After running MSVC Setup's "Repair" program (which, again, 
 took an hour or so) Visual Studio now starts. And then closes 
 with the message "Your evaluation time span has expired" 
 (although I never even used it). I don't think I'm going to 
 feel familiar with MSVC at any point in time. What a crude 
 world Windows is.


The Community Edition (both 2015 and 2017) can be used in 
perpetuity if you have a Microsoft account.

For reference, here's how object file compatibility works on 
Windows between the different C & D compilers:

* Don't mix any C objects compiled with MinGW with any D compiler 
other than GDC. You'll generally want to ensure the version of 
MinGW you use matches that backing GDC.

* MSVC-generated object files will work with LDC and with DMD, 
but you have to use either -m64 or -m32mscoff when compiling your 
D source using DMD.

* Vanilla DMD (which defaults to -m32) uses OPTLINK to link and 
therefore expects object files to be in OMF format. MSVC and 
MinGW output COFF, so objects they produce will need to be 
converted to OMF when linking with your D stuff (and you still 
may wind up with linker errors or compatibility problems). You'll 
generally want to compile your C files with DMC in this scenario.
May 16 2017