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

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.

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

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.

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

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

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

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

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

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