On 3/28/2012 3:05 AM, Ruben Van Boxem wrote:
2012/3/28 Anil Sahukar <asahu...@wowway.com <mailto:asahu...@wowway.com>>
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
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?
You're creating64-bit binutils executables by setting
"--host=x86_64-w64-mingw32". It is very logical you need the 64-bit
ar, prefixed because binutils build scripts are indeed a bit picky.
Given your input, then can I extrapolate and conclude the following?:
HOST == BUILD == TARGET == 32bit --> 32-bit
native-binutils (as provided by mingw)
HOST == BUILD == 32bit, TARGET == 64bit --> 32bit cross-binutils
capable of supporting cross-GCC compiler
BUILD == 32bit, HOST == TARGET == 64bit --> 64bit native-binutils
> 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).
That's not my saying, that was Vincent, and he is wrong. You also
built a native binutils: HOST == TARGET. It will run on 64-bit and
work with 64-bit binaries. Also, don't look at the $PREFIX/$TARGET/bin
directory, these are for GCC internal use only.
Sorry for the mis-quote.
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.
Do a clean configure with --host=i686-w64-mingw32 if you want a 32-bit
to 64-bit cross-compiler. Also: binutils needs nothing PPL/CLooG
related, those are for GCC.
I will do that. Regarding the PPL/CLooG comment, I'm a little
confused. When I run <path-to-configure>/configure --help, it lists
options --with-ppl and --with-cloog (as well as options for gmp, mpc and
mpfr). I would appreciate the insight as to why those options are
offered if they have nothing to do with binutils.
Does the above have any merit from your viewpoint?
It's based on some wrong assumptions, so not really ;-)
And I agree, now that misconceptions have been clarified. Once again,
thank you for the information and insight.
Ruben
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
Mingw-w64-public@lists.sourceforge.net
<mailto:Mingw-w64-public@lists.sourceforge.net>
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
------------------------------------------------------------------------------
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
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
------------------------------------------------------------------------------
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
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
