On Wed, Jul 30, 2008 at 7:56 AM, Jay wrote: [Jay] This definitely won't be the quickest way. [J] Quicker would be to set CC/CFLAGS and use -disable-bootstrap. [David] Before I try your suggestions, another question: It seems like [D] setting BOOT_CFLAGS to include "-m64" should do what I want. The [D] Makefile says: [D] # BOOT_CFLAGS is the value of CFLAGS to pass to the stage2, stage3 and stage4 [D] # bootstrap compilations. [D] If I understand this correctly, this would cause gcc from the later [D] stages to be called with -m64, so that they would, when building the [D] compiler, produce 64-bit objects and be able to link against my 64-bit [D] libgmp and libmpfr. Is this right? Maybe. I don't know. There are many options.. I should clarify/correct, that another thing i would try, which might have the advantage of - working vs. not-working - leaving you with more functionality installed in the end, maybe for the same time cost is first build a sparc(32) => sparc64 cross compiler install it and then a native sparc64 => sparc64 mkdir /obj/1 cd /obj/1 /src/configure -host sparc-sun-solaris2.9 -target sparc64-sun-solaris2.9 -disable-bootstrap -disable-nls -disable-multilib -enable-languages=c,c++ -verbose make sudo make install In truth, you can stop here. The next part doesn't buy much. (numbers as to the perf of gcc -host sparc vs. -host sparc64? or more generally foo vs. foo64?) mkdir /obj/2 cd /obj/2 # following line identical to above but for -host sparc vs. -host sparc64 /src/configure -host sparc64-sun-solaris2.9 -target sparc64-sun-solaris2.9 -disable-bootstrap -disable-nls -disable-multilib -enable-languages=c,c++ -verbose make sudo make install Personally I am bothered by the fact that this rebuilds a lot of the same code the same way multiple times. e.g. libiberty. However if you can spare the day of waiting and want it to just work and don't care about making it faster for future runs, this direct approach should work. I am working on a "system" (ie: a little bit of code) that minimize the rebuilds and reconfigurations and non-use of config.cache. For example, if I am building multiple toolsets, with "some overlap" -- e.g. same build/host, varying target, I shouldn't have to compile libiberty more than once per platform. Likewise for binutils, if I -enable-targets=all (but -enable-targets=all has small problems in bfd/opcodes, and doesn't currently work with ld, gas, and certainly gcc). I'd really like gcc, ld, as all take a -target command line parameter, and have gcc/cc1/as run in just one process, possibly compiling multiple source files (e.g. Visual C++ cl -c 1.c 2.c 3.c vs. gcc -c 1.c 2.c 3.c -- one process vs. seven!) But I until I have this working well... - Jay
