Because of the general instability of OPTLINK, I request that dmd should be able to generate object files consumable by other linkers. OPTLINK is the only OMF linker I've found capable to link dmd's output. Possible targets include the Microsoft linker (supports COFF) or the GNU linker (supports both COFF and ELF on Windows). dmd already has an Linux and a MacOSX backend, both with different object file formats; this can't be a too unrealistic feature request.
This is actually one which I'd really like to see done at some point. The fact that you have to use dmc to build your C/C++ code is a huge blocker for D on Windows for anyone who works in an environment which is primarily using Microsoft or Intel's compiler. It would not be possible for me to use dmc for C++ where I work, which makes using D there much harder, even if I were to end up with a project where I would have a chance of choosing to use it in D. There was a discussion about this on the D list a while back, and it was suggested that dmd at least be altered such that you could have a plugin architecture of some kind to swap out linkers. That way, even though dmd would still use dmc/optlink normally, someone other than Walter could then write and maintain a plugin which used Microsoft's compiler. So, we could potentially get support for other linkers without requiring Walter to deal with it.
If someone wants to write the .obj writer for an alternate format, do it. How to wire it up with dmd is the least of the problems.
Likely true. But as with many things around here, it requires someone to step up and do it.
It's more than just writing a different object file format, if the goal is to link with VC output. It's being ABI compatible with whatever the VC compiler puts out.
(In reply to comment #4) > It's more than just writing a different object file format, if the goal is to > link with VC output. It's being ABI compatible with whatever the VC compiler > puts out. Is this issue now solved since x64 uses the VC linker?
I wouldn't consider it done until win/32 is also migrated to the visual studio runtime and linker. I admit that's an expansion of the original description of this issue, but I think it's the spirit of it. And I agree with the spirit.
(In reply to comment #6) > I wouldn't consider it done until win/32 is also migrated to the visual studio > runtime and linker. I admit that's an expansion of the original description of > this issue, but I think it's the spirit of it. And I agree with the spirit. I'm totally for having support for COFF on win32 too, but IIRC Walter mentioned win32 will stay with Optlink? (I might be wrong). You can currently use one other linker on win32 though, Unilink. It often gives out readable error messages rather than crashing like Optlink.
Walter does not currently plan to make dmd on Windows produce COFF for 32-bit programs. It's considerably more work to do that on top of the 64-bit stuff, and he considers 32-bit to be dying out such that it's not worth the effort to convert it. I doubt that he'd be opposed to someone else doing that work, but as I understand it, he has no intention of doing it himself.
Speaking for Walter is generally a bad idea. Anyway, I recall the thread as "64 bit first, 32 bit maybe later".
I'm just repeating what I remember of what he said. I'd obviously have to dig through the archives to get exact quotes though. And he could certainly change his mind. Regardless, we're definitely not getting COFF on 32-bit Windows right now.
dmd will now support MS-COFF output with the -m32mscoff compiler switch.