niXman <i.nixman@xxxxxxxxx> writes: > 2012/3/17 niXman <i.nixman@xxxxxxxxx>: >> 2012/3/17 niXman <i.nixman@xxxxxxxxx>: >>> 2012/3/17 Ian Lance Taylor <iant@xxxxxxxxxx>: >>>> niXman <i.nixman@xxxxxxxxx> writes: >>>> >>>>>> I assume you can run the failing command yourself and see the failure. >>>>>> Can you run that command with -v and send us the complete output? >>>>> >>>>> Which one command? That which is in the fourth line >>>>> (http://pastebin.com/KiGHVgVQ) ? >>>> >>>> The command that fails. Which I think is the one you are referring to. >>> >>> command: http://pastebin.com/gHbUt2Un >>> output: http://pastebin.com/X4C9Z9bX >>> >>> if I replace lib with lib64 - linking is successfully. >>> I'm confused... %) >> >> Ooops.. >> output with '-v' option: http://pastebin.com/pmhqRfLp > > and output of original command(without replacement lib with lib64): > http://pastebin.com/65MfXcqr Earlier you were saying that you had trouble with CRT files. I don't see any trouble with them in this pastebin link. The link command is explicitly picking up E:/msys/mingw-x32/mingw/lib/../lib64/dllcrt2.o , which seems like the right thing to do. I see a lot of warnings about skipping incompatible libraries, but I don't see any errors. Does this link command succeed? If it fails, what are the error messages? The first two -L options passed to collect2 are -LE:/msys/mingw-x32/i686-w64-mingw32/lib -LE:/msys/mingw-x32/mingw/lib This is odd because these options are not in LIBRARY_PATH, and the options are not adjusted for the 64-bit multilib. The first of these options appears to be the source of the "skipping incompatible" warnings. The subsequent -L options do seem to be multilib aware, in that the /../lib64 variant appears first. So where are those first two -L options coming from? I see now that they are coming from the command itself, so I was looking at the wrong thing. It looks like those -L options are coming from the top level configure script. In the top level configure.ac, I see this: case "$target" in x86_64-*mingw* | *-w64-mingw*) # MinGW-w64 does not use newlib, nor does it use winsup. It may, # however, use a symlink named 'mingw' in ${prefix} . FLAGS_FOR_TARGET=$FLAGS_FOR_TARGET' -L${prefix}/${target}/lib -L${prefix}/mingw/lib -isystem ${prefix}/${target}/include -isystem ${prefix}/mingw/include' ;; *-mingw*) # MinGW can't be handled as Cygwin above since it does not use newlib. FLAGS_FOR_TARGET=$FLAGS_FOR_TARGET' -L$$r/$(TARGET_SUBDIR)/winsup/mingw -L$$r/$(TARGET_SUBDIR)/winsup/w32api/lib -isystem $$s/winsup/mingw/include -isystem $$s/winsup/w32api/include' ;; esac Those lines appear to be clearly incorrect when using multilib. That lets me find http://gcc.gnu.org/PR51206 which appears to be the bug that you are running into. I added a note to that bug report. Sorry to take so long to track this down. Ian
