------- Comment #4 from gdr at cs dot tamu dot edu 2007-10-04 20:29 ------- Subject: Re: configuration failure during native build
"dannysmith at users dot sourceforge dot net" <[EMAIL PROTECTED]> writes: | ------- Comment #3 from dannysmith at users dot sourceforge dot net 2007-10-04 08:26 ------- | (In reply to comment #2) | | While looking for collect2, I | > realized the path to ld (and as) had been misdetected. Explicit | > specification of the path, --with-ld=/mingw/bin/ld.exe, let me have a | > successful configuration. The buikd is now past the confiuguration step. | > I hope there won't be anymore failure. Many thanks! Is this type of | > failure documented somewhere? | | | Explicit specification of the path to ld and as has bot been necessary | on my native builds on WinXP host, using cygwin bash. But possibly I am | just avoidng the problem by using 'identity' mounts -- mounts where the | posix path equate to the DOS path on the current drive. eg, c:\mingw is | mounted as /mingw. etc so both the posix tools (like exec in the ld | scrtpt) and the native executables refer to the same path. Hi Danny, On my mahcine, I too have what you call `identity' mounts. However, for some reasons, the path to ld is detected as: c:/Docume~1/gdr/Desktop/sandbox/eval-build/i686-pc-mingw32/libstdc++-v3/c:/mingw/bin/../lib/gcc/mingw32/3.4.5/../../../../mingw32/bin/ld.exe which is not right. I suspect the real path is c:/mingw/bin/../lib/gcc/mingw32/3.4.5/../../../../mingw32/bin/ld.exe but somehow it is appended to the build directory path. Furthermore, it looks a very complicated path name. Thanks for looking into this. -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33603
