Quoting "Aaron W. LaFramboise" <
aaron77thyme@...>:
> 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.
>
As has already been stated in this list configure switches for GCC and
binutils and others that produce a target directory must include
--host=mingw32 --target=mingw32. That is the reason --build=mingw32.
The canonicalization should be i386-pc-mingw32 instead of
i386-pc-mingw. For x86_64 it should be --host=mingw64, etc.
> 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.'
>
Correct, which is why the triplet is just plain stupid for mingw32; it
makes no logical sense. We end up with i686-pc-mingw32 when it should
really be i386-pc-mingw32 just because the build is on i686 but the
target is really i386. I remember being so confused when I first came
to Cygwin.
> 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.
>
Keith and I have been in contact with Ben Elliston and one of us will
provide patches for MinGW to config.guess and config.sub.
Earnie
-------------------------------------------------------------------------
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