From: Aaron W. L. <aar...@aa...> - 2008-04-04 22:38:14
|
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? |