Re: Trouble with building multilib GCC (MinGW)

[Ian Lance Taylor <iant at google dot com>]

niXman <i.nixman@gmail.com> writes:

> 2012/3/17 niXman <i.nixman@gmail.com>:
>> 2012/3/17 niXman <i.nixman@gmail.com>:
>>> 2012/3/17 Ian Lance Taylor <iant@google.com>:
>>>> niXman <i.nixman@gmail.com> 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