Re: [Mingw-w64-public] Error when building binutils for cross-compilation under MinGW32

[Mook <moo...@gm...>]

On 3/27/2012 8:40 PM, Anil Sahukar wrote:
> My goal is to build the cross-compiler for MinGW-w64 starting from the
> native MinGW and source packages GMP (5.0.2) , PPL (0.11), CLooG
> (0.15.11) and binutils-2.21.53.
>
>  From config.log:
>
> It was created by configure, which was generated by GNU Autoconf 2.64.
> Invocation command line was
> $ ../../../src/binutils/binutils-2.21.53/configure
> --build=i686-w64-mingw32 --host=x86_64-w64-mingw32
> --prefix=/mingw64 --with-sysroot=/mingw64
> --target=x86_64-w64-mingw32 --disable-multilib
> --with-ppl=/third_party/spt/i686-w64-mingw32
> --with-cloog=/third_party/spt/i686-w64-mingw32

The --build you gave says you started with a 32 bit mingw-w64 toolchain; 
I believe for mingw you want --build=i686-pc-mingw32.

Anyway, since --host=x86_64-w64-mingw32, you are telling the build that 
you want binaries that will run on that system (a native toolchain).  To 
do that you first need to be able to cross-compile to that.  But you 
can't yet, you only have native i686-pc-mingw32.

I believe what you wan is:
1) a i686-pc-ming32 -> x86_64-w64-mingw32 cross toolchain
2) a x86_64-w64-mingw32 -> x86_64-w64-mingw32 native toolchain

You're t step 2 without hitting step 1 first.  2) is what gets you 
unprefixed binaries.
>
> I have read the thread
> http://comments.gmane.org/gmane.comp.gnu.mingw.w64.general/4453 from
> this past month.
>
> For the reasons discussed in the thread above, the configure script
> assumes x86_64-w64-mingw32-ar.exe will be used as the archive tool.
> Unfortunately, MinGW does not name its binutils execs that way
> out-of-the-box and libiberty fails during compilation.
>
> As the thread suggests, renaming (or copying - as I did) the ar.exe file
> in /mingw/bin to x86_64-w64-mingw32-ar.exe does indeed allow the build
> to work. I'm sure that setting AR=/mingw/bin/ar.exe would similarly
> work. I also saw the suggestion to set the --build option to
> 'x86_64-w64-mingw32', but as I am building with the 32-bit toolchain,
> that doesn't make any sense to me (and I didn't try it either).
>
> Having acknowledged those work-arounds, I have objections to this
> approach that can be summarized as follows:
>  > These extra steps seem unnecessary to me - shouldn't the
> configuration work with MinGW as-released?
>
>  > Given that I am building with the 32-bit toolchain, requiring
> x86_64-w64-mingw32-ar is at best confusing.
> If you do insist on a triple, shouldn't it be 'i686-w64-mingw32-ar' when
> --build is set to i686-w64-mingw32?
>
>  > When binutils are installed (using make install) with the above
> configuration, *ALL* the utilities are named
> without the 'triple' (i.e. x86_64-w64-mingw32) in both /mingw64/bin and
> /mingw64/x86_64-w64-mingw32/bin.
> What's going to happen to those "autotooled programs/libraries [that]
> rely on the host to compile
> in some specific way." when they are built against that toolchain?
> (quote lifted from Ruben Van Boxem
> <http://search.gmane.org/?author=Ruben+Van+Boxem&sort=date> | 16 Mar
> 17:11 - above thread).
>
> I would have no problem with requiring the triple prefixes on the
> binutils execs if the original MinGW distribution came that way, the
> configure script used the proper triple when using the 32-bit toolchain
> and the installation target for x86_64-w64-mingw32 binutils played the
> game consistently as well.
>
> Does the above have any merit from your viewpoint?
>
> Anil E. Sahukar
>
>
>
>
> ------------------------------------------------------------------------------
> This SF email is sponsosred by:
> Try Windows Azure free for 90 days Click Here
> http://p.sf.net/sfu/sfd2d-msazure
>
>
>
> _______________________________________________
> Mingw-w64-public mailing list
> Min...@li...
> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public