John E. / TDM wrote:
> Basically, this bug only manifests
> itself when the MinGW/GCC bin directory is *not* present in PATH -- e.g.
> GCC is run with a fully-qualified command line, like
> "C:\path\to\mingw\bin\gcc.exe -o myprogram mysources". It is in fact
> highly useful to be able to run GCC on Windows without any additions to
> PATH, particularly when working with multiple versions of it or when
> running it from and IDE.
OK this makes a lot more sense to me now. Thanks for the explanation.
Obviously I was never aware of this feature.
I will make this change in the next build.
So we're stuck with --build=mingw32 for backwards compatibility reasons.
This is a little unfortunate, and in a way, almost a GCC bug, as
mingw32 is canonicalized to i386-pc-mingw anyway. I would have
preferred using the latter because then autodetection works correctly,
and I feel the fewer unnecessary command line options we have, the better.
If I recall correctly, GCC and binutils treat all of 386, 486, 586, and
686 identically. In that case, this is a bug that would be fixed in the
long run (not short run) by causing GCC to search all identical CPU
types. The benefit is that people doing native builds on their own are
likely to get something compatible with distributed binaries as far as
this feature is concern, 'compatibility by default.'
If there are no objections, I'll put submitting a patch to FSF GCC for
that on my 'when I seriously have nothing better to do' list. We would
avoid compatibility problems in the short-term by a local patch to check
mingw32 also.
-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Register now and save $200. Hurry, offer ends at 11:59 p.m.,
Monday, April 7! Use priority code J8TLD2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone_______________________________________________
MinGW-dvlpr mailing list
MinGW-dvlpr@...
https://lists.sourceforge.net/lists/listinfo/mingw-dvlpr