Enhancement: _coff suffix for architectures

[mdparker]

Since the proper way to specify -m32 and -m64 is with -ax86 and -ax86_64 on the command line, there also needs to be a way to specify -m32mscoff. This also applies to LDC, where there is a need to distinguish between the MinGW and VC backends. This is true for both compilers, particularly if any linker-specific flags need to be passed along (I often use the SUBSYSTEM:WINDOWS flag, which requires a different format the three different linkers on Windows). Here's a proposal:

Two new architecture formats that can be passed to -a and tested for with 'platform' in the package configuration: x86_coff and x86_64_coff.

• on platforms that do not support coff output (non-windows and gdc) these are synonyms for x86 and x86_64.
• with dmd, x86_64 is a synonym for x86_64_coff; x86_coff implies -m32mscoff.
• with ldc-vc, *_coff is the architecture no matter what is passed on the command line; the opposite with ldc-mingw.

So we can then do things like this:

lflags "/SUBSYSTEM:windows,6.00" "/ENTRY:mainCRTStartup" platform="x86_64_coff"

If would be nice if it were possible to specify both x86_coff and x86_64_coff in platform, but I don't know if that's actually valid. Perhaps we could also add 'windows_coff' to cover that case?

[s-ludwig]

My feeling is that we should make this a fully orthogonal extension. In that case it would be separated by a dash and we'd have ...-coff, ...-omf and ...-elf. For full cross compilation support we'd also need some additional pieces of information, either specified using additional command line options, or using something like LLVM's target triple.

[mdparker]

+1 Even better.

[tchaloupka]

I found this bug when looking if something similar is already reported.
I have a problem with application referencing botan library with configuration 32mscoff that adds:
"dflags-windows-x86": [
"-m32mscoff"
]

when building with default dub build, the m32mscoff switch is added ok, but when you try it with dub build -a x86 -> both flags are added which seems wrong.
Solution you mentioned should be ok

[etcimon]

You might have stumbled on an issue that is due to me giving up on OMF. You have a 64k symbol limit that causes obscure failures in the linker. I've had too many issues with it for other reasons - there's also the vast amount of windows libraries WinVista+ that weren't ported to that format. You also can't statically link anything built on C++/C VS2013. So, might as well use microsoft linker for microsoft platforms, but it's a shame 32mscoff isn't supported in DMD installations out of the box (you have to custom compile the phobos library for it).

[tchaloupka]

I'm trying to build a REST server based on vibe, botan, libasync on windows and it's painfull :)
With 32bit it went somewhat ok for me with dmd 2.068.0, there were some linking warnings, but it worked. Today I upgraded to 2.068.1, and libasync, memutils and botan builds ok with 32mscoff config, but vibe is a problem as it comes with OMF libeay and ssleat libs I guess.
At least 2.068.1 seems to be delivering mscoff phobos already (c:\D\dmd2\windows\lib32mscoff).
Going with 64bit built dmd is also not much user friendly as it is needed to be built by hand :(

[etcimon]

I can't say much about building with libevent and openssl, because I use botan and libasync. Maybe you can try my custom fork on here:
https://github.com/etcimon/vibe.d

In your project, use: "subConfigurations": { "vibe.d": "libasync_botan" }

They are tested with these druntime/phobos versions:
https://github.com/etcimon/druntime/tree/2.068-gc
https://github.com/etcimon/phobos/tree/2.068-gc

I've tested this setup for the last 5 months, eliminating many leaks, access violations, etc. I will be adding LDC 16 support soon. However, the latest REST updates might not be available, but it's a production build (at least for me).

You can look at the h2_server and h2_request examples. There's a cookie jar and http/2 in there, and a new debug (wireshark-like capture) interface in http://127.0.0.1:8080/debugger/ if you register it from vibe.http.debugger setupDebugger . (preview: https://htmlpreview.github.io/?https://github.com/etcimon/vibe.d/blob/master/views/capture.html# ), it was made not to slown down production builds if it is not capturing.

[MrSmith33]

What is the progress on this issue?

[jpf91]

👍 for target triple(t)s. These are also used by GCC and autotools. GDC and GCC cross compilers are named $TRIPLET-gdc and the -dumpmachine option tells you the triplet for any gdc or gcc compiler.

*coff is a bad name for the switch. DMD is the only compiler which can use OMF, MinGW and MSVC both use the Coff file format. (It's probably even possible to link dmd -m32mscoff code with MinGW, but I don't think anybody ever tried this). So I think the switch should rather specify the C Runtime / Environment.
There are well-known target triplets for mingw(-w64) and msvc:
x86_64-w64-mingw32 and LLVM has something for MSVC. So we only need to invent a mars environment for the dmd -m32 triplet and were done.

[s-ludwig]

A temporary solution, targeting -m32mscoff specifically, has been implemented with #1007.

[mdparker]

Timing! I just forked the source the other day and implemented the same, though I called it x86_msvc. I also added intended to add x86_dmc and x86_gcc for consistency. I wanted to do more, though, before submitting a PR. I tried to dig around and figure out how to get it picked up in platform tuples in the config file, but ran out of time before I worked it out. I added a runtime field to BuildPlatform and a determineRuntime function, but got no further than that.

[s-ludwig]

Closing this in favor of #228, which is intended to provide a general solution.