This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: New Port Suggestion


Sam Lauber wrote:

> I have an idea for a Windows port of GCC 

I have also experimented with using Microsoft's assembler and linker
rather than binutils.  The most important question is: what value does
adding support for this add?

There is a whole lot that doesn't work.  From memory, there are a few
fairly irreconcillable syntactic differences between gas and ml
(Microsoft's assembler).  So, more support would need to be added to
GCC, or (as I have experimented with) a preprocessor written to convert
gas-isms to ml-isms.

There are also a few dependencies on the linker.  GNU tools for Windows
have a few dependencies on GNU ld that would need to be emulated with
some sort of wrapper for ld.  Alternately, yet more support could be
added to GCC, or associated runtime libraries.

If you'd like to do the work to make GCC do this, I think it would be
prety cool, and I might even be willing to help.  But first, realize
that theres a significant amount of work that may be involved, and think
hard about what benefit would be added.

By the way, note that the MASM32 package you're using doesn't actually
come from Microsoft.  I'm actually a little concerned about the
appropriateness of their redistribution of Microsoft's tools.

> that is acturally NATIVE

This is a matter of some frustration for me.  There is nothing about
*-mingw32 that isn't native; and there isn't anything about GCC on
Windows that makes it any less native than GCC on any other target.

I think the real trouble here is the name, MinGW.  I think its just a
historical relic of the port, which came from Cygwin, which wasn't
"MinGW."  I would be very tremendously happy if we could just start
calling it i686-pc-windows, or *-win32, or whatever, if only so my
collegues would understand that the Windows target can be as first-order
as the other targets.  Besides, theres no *-MinGSolaris or *-MinGARM.

Maybe this way originally done backwards.  The normal Windows port
should have come first, and POSIX support added later, in a library,
just as we add support for any other interface.  Then there would be no
*-mingw32, no *-cygwin, and no "winsup"; there would only be *-windows
and -lposix, or whatever.

Aaron W. LaFramboise


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]