Thanks for the report, but see below.
John E. / TDM wrote:
> Remember the packaging bug in the first binutils 2.18.50 tech preview that
> was pinned down in the "Necessary environment path settings" thread? This
> release gets at that same issue from the other direction. Since it was
> configured without a specific --build, --host or --target, it defaulted to
> the autodetected "i386-pc-mingw32" platform string.
OK, I'll admit I didn't pay close enough addition to that discussion,
but I don't really understand this bug.
> However this means that
> it looks for binutils in "<mingw>/i386-pc-mingw32/bin" rather than
> "<mingw>/mingw32/bin".
I don't believe that it does this.
GCC finds 'as' and 'ld' on the PATH, which is the same way it finds it
on any other native GCC target, which is also the same way GCJ finds
'ecj1', for example. I wasn't aware it was even possible to do
something different for a native build without giving GCC special options.
You can verify this by passing -Wl,-debug on the link line, which will
cause collect2 to tell you where its finding the linker, or -v on the
compile line, which will tell you how GCC is finding the assembler.
What is the actual manifestation of this problem? What sort of problem
did it cause with the build?
-------------------------------------------------------------------------
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
