From: Anil S. <asa...@wo...> - 2012-03-29 02:20:01
|
On 3/28/2012 3:05 AM, Ruben Van Boxem wrote: > > > 2012/3/28 Anil Sahukar <asa...@wo... <mailto:asa...@wo...>> > > 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 > Min...@li... > <mailto:Min...@li...> > 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 > Min...@li... > https://lists.sourceforge.net/lists/listinfo/mingw-w64-public |