Bug 18964 – -m32 should mean COFF, default is surprising

`-m32` should be changed to `-m32omf`, and mscoff should be default. They need to match and nobody should experience nasty surprises about object format mismatches when trying to do 32bit builds. The default (no -m arg given) current emits 32bit OMF. This isn't generally helpful. Personally, I think it's also time that DMD chose -m64 by default when no argument is given; it's 2018, it's been over a decade since it was possible to buy a 32bit x86. I had to pacify a frustrated colleague who wasted their time trying to work out why the x86 build wouldn't link, and explain the back-story. They were not at all satisfied with my explanation >_<

Did you suggest he use -m64? Also, when you submit a PR for an issue please include it in the issue: https://github.com/dlang/dmd/pull/8347 or nobody perusing bugzilla will know there's a PR.

That's where he started, but the trouble usually comes when wanting to build -m32 after building -m64. The errors are surprising, and he spent time trying to understand what was wrong with his libs, maybe pathing problems, a good amount of head-scratching, etc... nope, it's just 'broken'! No reasonable person would expect OMF. I don't know why, but it's still common to emit both binaries in windows builds. There's a sort of de-facto standard that distributing libs should include the full suite. > Also, when you submit a PR [...] Oh okay, can do in future. Honestly, I expected this would have exactly no traction... but I think it's worth consideration. It's not any skin off anyone's noses here, but unsuspecting new users only really stand to be surprised and/or annoyed by the current arrangement.

Fixed by https://github.com/dlang/dmd/pull/13110