Re: the struggle to create a 64-bit gcc on Solaris 10

[Ryan Johnson <ryan dot johnson at cs dot utoronto dot ca>]

On 10/11/2012 3:51 PM, Dennis Clarke wrote:
> > Eric wrote:
> > > > Any pointers at all as to the error of my ways ?
> > > http://gcc.gnu.org/install/specific.html#sparc64-x-solaris2
> > You're up against three factors here. First, the sparc64 platform ABI
> > specifies 32-bit executables unless the user specifically asks for
> > 64-bit. I'm really unclear on why you think that's a bad thing (spacv9
> It isn't.
Then why is it bad to have a 32-bit gcc? I'm really confused now.

I've had a 32-bit gcc producing 64-bit binaries without complaint on a 
Niagara II machine for about three years now. Recent versions of gcc 
aren't even hard to bring up any more. All the stuff I wrote in my email 
was about not doing the easy way, and instead bootstrapping a gcc that 
is itself a 64-bit binary and produces only 64-bit executables.

> <snipped detailed rant>
>
> To make a long story short, it is a drag to deal wwith such crap when I just want a compiler that looks like, walks like and acts like the one in my RHEL 6 workstation at home.
The only difference I've noticed with a stock sparc-solaris gcc is that 
thread-local storage is dog slow (blame the ABI) and dbx usually can't 
handle dwarf debug info correctly. I've actually had *far* more multilib 
pain from linux over the years than solaris. Plus, most multilib pain I 
have suffered in Solaris was due to autotools projects from the linux 
world insisting on dropping 64-bit libraries in $PREFIX/lib instead of 
$PREFIX/lib/sparcv9. I've never even heard of half the stuff you 
mentioned ($ISALIST mumble mumble, version needed mumble mumble), and 
yet multilib development has somehow been working all right so far.

> <snipped some more>
>
> So I have a whole pile of GNU stuff on my production nice shiney new Niagara Sparc server and I can not find a reason to care about 32-bit anything.
> So why not try a full 64-bit GNU toolchain?
... because it's an awful lot of work for something you claim not to 
care about?

> > CC='cc -m64' CXX='CC -m64' ../gmp-5.0.1-src/configure
> > --prefix=$HOME/apps/gcc-4.7.2 --build=sparc64-sun-solaris2.10
> > --disable-shared
> > CC='cc -m64' CXX='CC -m64' ../mpfr-3.1.1-src/configure
> > --prefix=$HOME/apps/gcc-4.7.2 --build=sparc64-sun-solaris2.10
> > --disable-shared --with-gmp=$HOME/apps/gcc-4.7.2
> > CC='cc -m64' CXX='CC -m64' ../mpc-0.8.2-src/configure
> > --prefix=$HOME/apps/gcc-4.7.2 --build=sparc64-sun-solaris2.10
> > --disable-shared --with-{gmp,mpfr}=$HOME/apps/gcc-4.7.2
> > CC='cc -m64' CXX='CC -m64' ../gcc-4.7.2-src/configure
> > --prefix=$HOME/apps/gcc-4.7.2 --build=sparc64-sun-solaris2.10
> > --disable-multilib --with-{gmp,mpfr,mpc}=$HOME/apps/gcc-4.7.2
> > --without-gnu-{as,ld}
> > make {CFLAGS_FOR_TARGET,BOOT_CFLAGS}='-m64 -O2'
> >
> > $ file $HOME/apps/gcc-4.7.2/bin/gcc
> > gcc:   ELF 64-bit MSB executable SPARCV9 Version 1, dynamically
> > linked,
> > not stripped, no debugging information available
> nice !
>
> > $ $HOME/apps/gcc-4.7.2/bin/gcc hello.c
> > $ file ./a.out
> > a.out:          ELF 64-bit MSB executable SPARCV9 Version 1,
> > dynamically
> > linked, not stripped, no debugging information available
> yeah but a 32-bit gcc can do that just fine.
You said you didn't want a 32-bit gcc, that having 32-bit anything 
around was a liability. Hence the directions to make a purely 64-bit one.

> <snipped yet more stuff>
>
> pain.
> been there .. done that .. over and over.
> > (linker errors involving alloca)
> > - Build the support libs with --disable-shared to avoid strange
> > TLS-related loader errors
> > - Disable -g to avoid linker errors mentioning R_SPARC_UA32 and
> > .rela.debug_info during stage 3
> I am rapidly coming to the conclusion that this won't be easy to do .. but I'll keep hacking at it.
I don't think you understand: I used the above configury incantation to 
bring up, from scratch, a purely 64-bit gcc that produces 64-bit 
binaries by default. Today. On a Niagara II machine. No 32-bit ELF files 
anywhere. Hence the delay in responding and the notes about gotchas I 
encountered along the way.

If that's not what you were looking for, what is?

Ryan