> 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. In fact, it has never been a problem for me in the past. Furthermore I have been doingbuilds of GCC on Solaris for a long long time now. Decade. Maybe more. Can't recall to be honest. Usually I have no problem and like to post my results. See solaris 8 results at http://gcc.gnu.org/gcc-4.7/buildstat.html However, Solaris 8 was the old gold standard. anything that built there, ran everywhere in the Solaris world. At least for anything in the last ten years. Consider the compiler I am using here : $ ls -lap $CC -rwxr-xr-x 1 root bin 640388 Aug 11 2010 /opt/csw/gcc4/bin/gcc $ file /opt/csw/gcc4/bin/gcc /opt/csw/gcc4/bin/gcc: ELF 32-bit MSB executable SPARC Version 1, dynamically linked, not stripped $ elfdump -vd $CC Version Needed Section: .SUNW_version file version libc.so.1 SUNW_1.18.1 Dynamic Section: .dynamic index tag value [0] NEEDED 0x2973 libc.so.1 [1] INIT 0x36150 [2] FINI 0x3616c [3] RUNPATH 0x2989 /opt/csw/lib/$ISALIST:/opt/csw/lib:/opt/csw/gcc4/lib/$ISALIST:/opt/csw/gcc4/lib [4] RPATH 0x2989 /opt/csw/lib/$ISALIST:/opt/csw/lib:/opt/csw/gcc4/lib/$ISALIST:/opt/csw/gcc4/lib [5] HASH 0x100e8 [6] STRTAB 0x13ce0 [7] STRSZ 0x29d9 [8] SYMTAB 0x114f0 [9] SYMENT 0x10 [10] CHECKSUM 0x88ef [11] VERNEED 0x166bc [12] VERNEEDNUM 0x1 [13] PLTRELSZ 0x48c [14] PLTREL 0x7 [15] JMPREL 0x16730 [16] RELA 0x166dc [17] RELASZ 0x4e0 [18] RELAENT 0xc [19] DEBUG 0 [20] FEATURE_1 0x1 [ PARINIT ] [21] FLAGS 0 0 [22] FLAGS_1 0 0 [23] PLTGOT 0x63544 [24] NULL 0 $ See that version need section in the output binary gcc ? To me this compiler works just fine and has for a few years now. It is really well tested and was released a while back. Note, however, the version needed for libc.so.1. See that SUNW_1.18.1 ? Well to someone in the know, that is a dead give away that this was compiled on Solaris 8. That version "NEEDED" was released quite a while ago. If you had a baseline version of Solaris 8 and then patched it up to date you would have a libc no higher than 1.18.1 or maybe 1.19. This means the resultant binaries created on that platform are assured to have access to the system calls and baseline functions provided in all libraries that follow in Solaris 9 and 10 and even Solaris 11. Let's take a look at the libc in Solaris 10 : $ ls -lapb /lib/libc.so.1 -rwxr-xr-x 1 root bin 1653368 Aug 21 17:34 /lib/libc.so.1 $ elfdump -vd /lib/libc.so.1 Version Definition Section: .SUNW_version index version dependency [1] libc.so.1 [ BASE ] [2] SUNW_1.23 SUNW_1.22.7 [3] SUNW_1.22.7 SUNW_1.22.6 [4] SUNW_1.22.6 SUNW_1.22.5 [5] SUNW_1.22.5 SUNW_1.22.4 [6] SUNW_1.22.4 SUNW_1.22.3 [7] SUNW_1.22.3 SUNW_1.22.2 [8] SUNW_1.22.2 SUNW_1.22.1 [9] SUNW_1.22.1 SUNW_1.22 [10] SUNW_1.22 SUNW_1.21.3 [11] SUNW_1.21.3 SUNW_1.21.2 [12] SUNW_1.21.2 SUNW_1.21.1 [13] SUNW_1.21.1 SUNW_1.21 [14] SUNW_1.21 SUNW_1.20.4 [15] SUNW_1.20.4 SUNW_1.20.1 [16] SUNW_1.20.1 SUNW_1.20 [17] SUNW_1.20 SUNW_1.19 [18] SUNW_1.19 SUNW_1.18.1 [19] SUNW_1.18.1 SUNW_1.18 [20] SUNW_1.18 SUNW_1.17 [21] SUNW_1.17 SUNW_1.16 [22] SUNW_1.16 SUNW_1.15 [23] SUNW_1.15 SUNW_1.14 [24] SUNW_1.14 SUNW_1.13 [25] SUNW_1.13 SUNW_1.12 [26] SUNW_1.12 SUNW_1.11 [27] SUNW_1.11 SUNW_1.10 [28] SUNW_1.10 SUNW_1.9 [29] SUNW_1.9 SUNW_1.8 [30] SUNW_1.8 SUNW_1.7 [31] SUNW_1.7 SUNW_1.6 [32] SUNW_1.6 SUNW_1.5 [33] SUNW_1.5 SUNW_1.4 [34] SUNW_1.4 SUNW_1.3 [35] SUNW_1.3 SUNW_1.2 [36] SUNW_1.2 SUNW_1.1 [37] SUNW_1.1 SUNW_0.9 [38] SUNW_0.9 SUNW_0.8 [39] SUNW_0.8 SUNW_0.7 [40] SUNW_0.7 SISCD_2.3 [41] SISCD_2.3 SYSVABI_1.3 [42] SYSVABI_1.3 [43] SUNWprivate_1.1 Dynamic Section: .dynamic index tag value [0] SUNW_FILTER 0x596f /usr/lib/ld.so.1 [1] SUNW_FILTER 0x5980 libm.so.2 [2] SUNW_AUXILIARY 0x598a /platform/$PLATFORM/lib/libc_psr.so.1 [3] INIT 0xd0444 [4] FINI 0xd0450 [5] SONAME 0x5965 libc.so.1 [6] HASH 0x2dfc [7] STRTAB 0x13db0 [8] STRSZ 0x59b0 [9] SYMTAB 0x8890 [10] SYMENT 0x10 [11] CHECKSUM 0xb6f9 [12] VERDEF 0x19760 [13] VERDEFNUM 0x2b [14] RELACOUNT 0x86a [15] PLTRELSZ 0x1ad0 [16] PLTREL 0x7 [17] JMPREL 0x21f74 [18] RELA 0x1b3f8 [19] RELASZ 0x864c [20] RELAENT 0xc [21] SYMINFO 0xb4 [22] SYMINSZ 0x2d48 [23] SYMINENT 0x4 [24] SUNW_RTLDINF 0x14a1a0 [25] FEATURE_1 0x1 [ PARINIT ] [26] FLAGS 0 0 [27] FLAGS_1 0x20000 [ NODIRECT ] [28] PLTGOT 0x1433ec [29] NULL 0 $ wow. See that version SUNW_1.23 ? If you compile something on this machine ( Solaris 10 ) and then try to run it on Solaris 9, forget it. Even worse, and people screw this up all the time, if you create a software package on Solaris 10 and then install it on another Solaris 10 machine, whammo, you may be in deep trouble there also because it was not patched up to date. So to make a long story short, there are good reasons to compile on baseline servers within reason. Next comes the heartache of dealing with an operating system that is perfectly happy with both 32-bit executables and all dependencies as well as 64-bit. Well how do you keeep all that working? I mean heck, how does a 32-bit binary locate and then use the 32-bit libraries it needs and not have the runtime linker bring up a 64-bit library which has the exact same name? I don't want to get into a long yakkity yak about things like $ISALIST or RPATH values in the ELF objects without sufficient beer and scotch. Nope. Not today. Have fun looking at : http://docs.oracle.com/cd/E23824_01/html/819-0690/appendixc-1.html .. but don't waste your time. 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. [dclarke@rockbox ~]$ cat /proc/version Linux version 2.6.32-279.11.1.el6.x86_64 (mockbu...@x86-009.build.bos.redhat.com) (gcc version 4.4.6 20120305 (Red Hat 4.4.6-4) (GCC) ) #1 SMP Sat Sep 22 07:10:26 EDT 2012 On this box I have gcc provided by the Red Hat folks, it isn't the version I want, but it will work to bootstrap what I want. $ which gcc /usr/bin/gcc $ ldd /usr/bin/gcc linux-vdso.so.1 => (0x00007ffff8fff000) libc.so.6 => /lib64/libc.so.6 (0x0000003c85a00000) /lib64/ld-linux-x86-64.so.2 (0x0000003c85200000) For a giggle, run "readelf -Vd /lib64/libc-2.12.so". Holy nightmare batman. In any case, the gcc binary is 64-bit and there isn't a 32-bit part of it anywhere. can I compile 32-bit objects? Yeah sure, why not? All one needs is some headers and some libs. Away we go. 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. I don't care about memory overhead, because, quite frankly, I'm swimming in memory. There are a bucket of cores here : gnume-sparc-SunOS5.10 # psrinfo -pv The physical processor has 64 virtual processors (0-63) UltraSPARC-T2+ (chipid 0, clock 1582 MHz) The physical processor has 64 virtual processors (64-127) UltraSPARC-T2+ (chipid 1, clock 1582 MHz) So why not try a full 64-bit GNU toolchain? So .. that is what I have been doing. It has all been going well. All except for GCC which simply insists on creating a pile of 32-bit objects in the bootstrap stage 1. Hell if I know why. > CC='cc -m64' and CXX='CC -m64' ./configure --build=sparc64-sun-solaris2.10 yep .. did that .. fail again. > usually does the trick (you didn't mention which compiler you're using GCC 4.5.1 > Another issue is preventing gcc from attempting a 32-bit multilib, > since it wants to be able to generate both 32- and 64-bit code (as per the > platform ABI). Passing --disable-multilib takes care of that. yep .. did that. > The last (very annoying) issue is that when gcc bootstraps itself, the > freshly-built compiler doesn't generate 64-bit binaries by default. > BOOT_CFLAGS can work around that: http://gcc.gnu.org/install/build.html. Seems to be something we can control with STAGE1 and STAGE2 or whatever they are called CFLAGS in the Makefiles. > 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. $ cat -n hello.c 1 #include <stdio.h> 2 3 int 4 main(int argc, char *argv[]) 5 { 6 printf ( "Hello World!\n" ); 7 return (0); 8 } $ file $CC /opt/csw/gcc4/bin/gcc: ELF 32-bit MSB executable SPARC Version 1, dynamically linked, not stripped $ gcc -m64 -o hello hello.c $ file hello hello: ELF 64-bit MSB executable SPARCV9 Version 1, dynamically linked, not stripped $ ./hello Hello World! So 32-bit gcc works just fine. However I need a pile of libs all over the place ( gmp, mpfr, mpc, etc etc ) for this to work and that doesn't even get into libgcc or libstdc++ blah blah blah and the list goes on and then I am stuck with a libpath with both 32-bit libs and 64-bit libs and $ISALIST etc etc. pain. > Notes: > - Use mpfr-3.1.1 or newer, older versions are broken on sparc-solaris $ ls /usr/local/lib/libmpfr* /usr/local/lib/libmpfr.a /usr/local/lib/libmpfr.so.4 /usr/local/lib/libmpfr.la /usr/local/lib/libmpfr.so.4.1.1 /usr/local/lib/libmpfr.so $ file /usr/local/lib/libmpfr.so.4.1.1 /usr/local/lib/libmpfr.so.4.1.1: ELF 64-bit MSB dynamic lib SPARCV9 Version 1, UltraSPARC3 Extensions Required, dynamically linked, not stripped $ head -29 /usr/local/lib/libmpfr.la | tail -5 # Version information for libmpfr. current=5 age=1 revision=1 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. Dennis
