www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - TypeInfo and bloated exes - is MingGW toolchain the answer?

reply Bill Baxter <dnewsgroup billbaxter.com> writes:
It seems to me that the MinGW tools are pretty much the best and only 
hope if you are going to abandon OMF and OptLink.

Implementing new object/link tools for existing formats from scratch is 
far too much work.  You can also forget about creating a whole new 
object format from scratch.  If you're going to replace OptLink it needs 
to be with something that exists and is standard.

But there's not a whole lot out there in terms of free code for object 
file and library manipulation.  There's OpenWatcom, which also suffers 
from being OMF-based, and apparently has more bugs than D's current 
tools, and then there's MinGW, which works with MS PE-COFF.

Personally, I don't see why on Windows you'd want to use anything other 
than Microsoft's format.  Especially now that you can get their latest 
C++ compiler for free.  Intel's super-optimized compiler is also 
compatible with this format.  Probably others are as well.

Other than the GPL license, it seems like the MinGW tools have 
everything one could hope for.  Is the license the only real problem?

Also -- one thing that I'm not sure about:  Would there be any 
difference between the current GDC and a hypothetical DMD that used 
PE-COFF and MinGW bintools?

--bb
Feb 22 2007
next sibling parent reply kris <foo bar.com> writes:
Bill Baxter wrote:

 It seems to me that the MinGW tools are pretty much the best and only 
 hope if you are going to abandon OMF and OptLink.


Yesterday, there were strong claims made about the DM Win32 obj-format 
(OMF) being compatible with a number of different linkers. I'm surprised 
it is so hard to track one down?


 
 Implementing new object/link tools for existing formats from scratch is 
 far too much work.  You can also forget about creating a whole new 
 object format from scratch.  If you're going to replace OptLink it needs 
 to be with something that exists and is standard.
 
 But there's not a whole lot out there in terms of free code for object 
 file and library manipulation.  There's OpenWatcom, which also suffers 
 from being OMF-based, and apparently has more bugs than D's current 
 tools, and then there's MinGW, which works with MS PE-COFF.


The one that I used was 4 years old. I've not tried the more recent 
version of OpenWatcom ... has anyone else?


 
 Personally, I don't see why on Windows you'd want to use anything other 
 than Microsoft's format.  Especially now that you can get their latest 
 C++ compiler for free.  Intel's super-optimized compiler is also 
 compatible with this format.  Probably others are as well.


Very true. One big question (that's been asked several times before) is 
"how does DM expect to support 64-bit on Win32"? Perhaps OMF will have 
to be dumped one way or another?


 
 Other than the GPL license, it seems like the MinGW tools have 
 everything one could hope for.  Is the license the only real problem?


Is it 64-bit compliant?


 
 Also -- one thing that I'm not sure about:  Would there be any 
 difference between the current GDC and a hypothetical DMD that used 
 PE-COFF and MinGW bintools?
 
 --bb
Feb 22 2007
next sibling parent Sean Kelly <sean f4.ca> writes:
kris wrote:

 Bill Baxter wrote:

 It seems to me that the MinGW tools are pretty much the best and only 
 hope if you are going to abandon OMF and OptLink.


 
 Yesterday, there were strong claims made about the DM Win32 obj-format 
 (OMF) being compatible with a number of different linkers. I'm surprised 
 it is so hard to track one down?


Perhaps not so surprising given the age of the OMF format.  DMC/DMD are 
the only compilers I know of that still use it.


 Personally, I don't see why on Windows you'd want to use anything 
 other than Microsoft's format.  Especially now that you can get their 
 latest C++ compiler for free.  Intel's super-optimized compiler is 
 also compatible with this format.  Probably others are as well.


 
 Very true. One big question (that's been asked several times before) is 
 "how does DM expect to support 64-bit on Win32"? Perhaps OMF will have 
 to be dumped one way or another?


I suspect it will, but that's more a hunch than an authoritative claim.


 Other than the GPL license, it seems like the MinGW tools have 
 everything one could hope for.  Is the license the only real problem?


 
 Is it 64-bit compliant?


I think the license may turn out to be more of an issue as far as DMD is 
concerned.  Why work to generate code for an object file format you 
don't have the software to link?  Or is it perhaps not a tremendous 
amount of work (which seems unlikely) and the format could be specified 
via a compiler flag?


Sean
Feb 22 2007
prev sibling next sibling parent reply Sean Kelly <sean f4.ca> writes:
By the way, this may be a pertinent link:

http://support.microsoft.com/kb/888328
Feb 22 2007
parent reply Bill Baxter <dnewsgroup billbaxter.com> writes:
Sean Kelly wrote:

 By the way, this may be a pertinent link:
 
 http://support.microsoft.com/kb/888328


That's only talking about the format for debug symbols so I'm not sure 
how relevant it is.
It also only says you can't *build* objects with COFF debug info, but it 
doesn't say whether MS tool still support *debugging* programs with 
embedded COFF debug info.
Feb 22 2007
parent reply Jascha Wetzel <"[firstname]" mainia.de> writes:
Bill Baxter wrote:

 It also only says you can't *build* objects with COFF debug info, but it
 doesn't say whether MS tool still support *debugging* programs with
 embedded COFF debug info.


Support for debugging embedded debug symbols is kind of broken in new MS
debuggers. It's like they crippled that support while updating the
software. The debugger reads the symbols and you can see them, but it
doesn't find the source line corresponding to an address, so you can't
use it.

But isn't this about the linker, anyway? As long as the linker copies
embedded debug symbols from COFF files correctly to the executable,
there shouldn't be a problem.
Feb 23 2007
parent Sean Kelly <sean f4.ca> writes:
Jascha Wetzel wrote:

 Bill Baxter wrote:

 It also only says you can't *build* objects with COFF debug info, but it
 doesn't say whether MS tool still support *debugging* programs with
 embedded COFF debug info.


 
 Support for debugging embedded debug symbols is kind of broken in new MS
 debuggers. It's like they crippled that support while updating the
 software. The debugger reads the symbols and you can see them, but it
 doesn't find the source line corresponding to an address, so you can't
 use it.
 
 But isn't this about the linker, anyway? As long as the linker copies
 embedded debug symbols from COFF files correctly to the executable,
 there shouldn't be a problem.


Ah, good point.  I only brought this up because a switch to COFF is seen 
as a universally good thing, but if this "new" object format isn't even 
supported by MS debuggers any more, then it still may be an issue for 
Win32 development.  But I suppose it's pointless trying to chase 
changing MS standards.  There are other linkers and debuggers out there 
anyway.


Sean
Feb 23 2007
prev sibling parent Bill Baxter <dnewsgroup billbaxter.com> writes:
kris wrote:

 Bill Baxter wrote:

 It seems to me that the MinGW tools are pretty much the best and only 
 hope if you are going to abandon OMF and OptLink.


 
 Yesterday, there were strong claims made about the DM Win32 obj-format 
 (OMF) being compatible with a number of different linkers. I'm surprised 
 it is so hard to track one down?


There were some other tools I saw that use OMF format.  Actually alink 
can use both.  And the OpenWatcom tools are using it too.  But aside 
from OpenWatcom I didn't notice any *currently supported* tools using 
OMF as their main format.   Most of the OMF-using links were to things 
for generating 16-bit or MS-DOS compatible programs.  Maybe MS-DOS 
support is still important in the embedded world, though?


 Other than the GPL license, it seems like the MinGW tools have 
 everything one could hope for.  Is the license the only real problem?


 
 Is it 64-bit compliant?


http://www.mingw.org/mingwfaq.shtml#faq-what
Says it "will be eventually".

I think too many people use MinGW for 64-bit to remain unsupported.
Actually there may be a patch or something floating around because a 
search for mingw64 turns up lots of hits.

--bb
Feb 22 2007
prev sibling parent John Reimer <terminal.node gmail.com> writes:
On Fri, 23 Feb 2007 09:36:09 +0900, Bill Baxter wrote:


 It seems to me that the MinGW tools are pretty much the best and only 
 hope if you are going to abandon OMF and OptLink.
 
 Implementing new object/link tools for existing formats from scratch is 
 far too much work.  You can also forget about creating a whole new 
 object format from scratch.  If you're going to replace OptLink it needs 
 to be with something that exists and is standard.
 
 But there's not a whole lot out there in terms of free code for object 
 file and library manipulation.  There's OpenWatcom, which also suffers 
 from being OMF-based, and apparently has more bugs than D's current 
 tools, and then there's MinGW, which works with MS PE-COFF.
 
 Personally, I don't see why on Windows you'd want to use anything other 
 than Microsoft's format.  Especially now that you can get their latest 
 C++ compiler for free.  Intel's super-optimized compiler is also 
 compatible with this format.  Probably others are as well.
 
 Other than the GPL license, it seems like the MinGW tools have 
 everything one could hope for.  Is the license the only real problem?
 
 Also -- one thing that I'm not sure about:  Would there be any 
 difference between the current GDC and a hypothetical DMD that used 
 PE-COFF and MinGW bintools?
 
 --bb



Between OpenWatcom and Mingw, we at least have something to think about. 
MingW particularly is not going away anytime soon and has a large
developer base.

This should be investigated. Of course, it's all rather futile if dmd
doesn't commit to outputting files in a compatible format for these tools.

-JJR
Feb 22 2007