Build fails with LDC(x86) on Windows.

[kntroh]

Because LDC uses Microsoft's linker, the flags for OPTLINK cause problems.

[jacob-carlborg]

DMD can use the same tool chain as well. There's a version identifier CRuntime_DigitalMars that might be possible to use.

[kntroh]

The problem in this case is that the flags for OPTLINK get in the way when using ldc2 with dub.
If we don't use OPTLINK, we shouldn’t specify these flags, but if a condition is platform="x86", the flags are always specified even when using LDC.

[jacob-carlborg]

The problem in this case is that the flags for OPTLINK get in the way when using ldc2 with dub.

I understand. The same problem happens with DMD when targeting x86 COFF, i.e. using the -m32mscoff flag. Just using platform="x86" is not accurate. The platform conditions, such as platform="x86", are based on version identifiers. I don't know if all of them are supported.

BTW, since DMD 2.086.0 [1] Dub will (only Dub not DMD) default to using the -m32mscoff. Might be better to remove these flags?

[1] https://dlang.org/changelog/2.086.0.html#dmd-mscoff-default

[kntroh]

I understand. The same problem happens with DMD when targeting x86 COFF, i.e. using the -m32mscoff flag. Just using platform="x86" is not accurate. The platform conditions, such as platform="x86", are based on version identifiers. I don't know if all of them are supported.

You are right. From what I found out, it looks like we can use platform="x86_omf" from dmd 2.094 maybe. But I can't use it at the moment. May need a different configuration before dmd 2.093 and after 2.094.
Ideally, the following would be the correct configuration:

lflags `+$DWT_PACKAGE_DIR\org.eclipse.swt.win32.win32.x86\lib\` platform="x86_omf"
lflags `/exet:nt/su:console:4.0` platform="x86_omf"

platform=x86-dmd is a compromise.

BTW, since DMD 2.086.0 [1] Dub will (only Dub not DMD) default to using the -m32mscoff. Might be better to remove these flags?

Even after dmd 2.086, with --arch=x86, OPTLINK is always used. COFF is used only with --arch=x86_64. So, we need these flags now.
I couldn't find a way to use -m32mscoff from dub. Is there one?

[jacob-carlborg]

Even after dmd 2.086, with --arch=x86, OPTLINK is always used

What if you don't pass the --arch flag at all? Is it common to pass the --arch flag on Windows? I more or less never used the --arch flag on other platforms.

I couldn't find a way to use -m32mscoff from dub. Is there one?

I think the flag is --arch=x86_mscoff.

[kntroh]

What if you don't pass the --arch flag at all? Is it common to pass the --arch flag on Windows? I more or less never used the --arch flag on other platforms.

Currently, if we don't specify the --arch, dub on Windows works the same way as --arch=x86_64.

I think the flag is --arch=x86_mscoff.

It seems that x86_mscoff is adds at the same time as x86_omf. It didn't work with dmd 2.093.1.

[jacob-carlborg]

Currently, if we don't specify the --arch, dub on Windows works the same way as --arch=x86_64

Ah, right.

It seems that x86_mscoff is adds at the same time as x86_omf. It didn't work with dmd 2.093.1.

Unfortunately my Windows VMs currently don't work so I can't test it for myself but according to this [1], the x86_mscoff architecture was added four years ago.

[1] dlang/dub@4654f17

[kntroh]

Unfortunately my Windows VMs currently don't work so I can't test it for myself but according to this [1], the x86_mscoff architecture was added four years ago.

Oops, maybe I made a typo or something, I was mistaken. I just tried it and it worked.
But, the flag specified in x86 is also specified in x86_mscoff, so if we want to specify the flag in x86_omf but not in x86_mscoff, We need to specify --arch=x86_omf.

Maybe we should wait for the release of x86_omf.

[jacob-carlborg]

Maybe we should wait for the release of x86_omf.

I guess it's fine with this PR as is. It doesn't break anything that didn't work before, right?

[kntroh]

I guess it's fine with this PR as is. It doesn't break anything that didn't work before, right?

It's just one less pattern to break.
After that, I think we can fix it after x86_omf is established.

[jacob-carlborg]

Thanks.

[kntroh]

Thanks too.
I created Issue so that I don't forget to do the work in the future: #61