Every few weeks I got asked why OpenPKG uses 32 bit by default on Solaris 10/sparc64 and Solaris 10/amd64 even this platform supports 64 bit. And every time I'm confused myself a little and don't know immediately what the best answer actually is. But here are the gory details for our summary:
1. The whole 32 vs. 64 bit issue is just a compiler tool chain issue. For OpenPKG this means that "binutils" and "gcc" have to support 32 and/or 64 bit in order to allow the other packages to be build and running in 32 or 64 bit mode. Fact #1: OpenPKG's "binutils" and "gcc" packages (at least in CURRENT and 2-STABLE) out-of-the-box(!) support _BOTH_ 32 and 64 bit mode. The _default_ is just 32 bit. 32 bit mode is explicitly selected with "gcc -m32" while 64 bit mode is explicitly selected with "gcc -m64". 2. The usual "32 bit is bad and 64 bit is always better on a 64 bit box" (either sparc64 or amd64) is more or less an urban legend. If you don't trust RSE, I can alternatively quote Sun itself here (see e.g. http://developers.sun.com/sunstudio/articles/options.html): "- When moving from 32-bit to 64-bit code, the memory footprint of the application typically gets bigger, because long, unsigned long, and pointers all change from being 32-bits in size to being 64-bits in size. Because of this, some applications will run more slowly. - The programming model for the UltraSPARC processor allows 32-bit applications to use the same set of features as 64-bit applications. As such there is often little to be gained by targeting 64-bit. - The x64 platform has a number of fundamental architecture improvements which can enhance performance when using 64-bit code. In particular the number of registers available for the application to use has significantly increased -- this fact gives the compiler a number of opportunities to extract performance out of the application. - The primary and critical reason to use 64-bit code is if the application handles a large amount of data in memory." Fact #2: don't panic, 32 bit mode on a 64 bit architecture like the particular sparc64 or amd64 is _NOT_ really an issue as long as you don't run a high-performance PostgreSQL, a memory-caching Squid or something similar. 3. As one _CANNOT_ mix 32 and 64 bit code in the _SAME_ application we cannot just switch our GCC to use 64 bit mode by default as long as not all other OpenPKG packages depended on our GCC. Because even the Sun Studio vendor compiler generates 32 bit binaries _BY DEFAULT_ on both sparc64 and amd64 platforms! So, even if we switch our GCC, the building of OpenPKG would break until either one uses OpenPKG also for bootstrapping (install a set of pre-built binary packages) _AND_ have no vendor compiler installed at all. Only in this case we would result in a consistent set of 64 bit code in all libraries and this way all applications can be correctly built in 64 bit mode. Fact #3: Even the Sun Studio vendor compiler uses 32 bit by default: Proof: $ cat hello.c #include <stdio.h> int main(int argc, char *argv[]) { printf("Hello World\n"); return 0; } $ cat hello.sh #!/bin/sh shtool platform --type=binary compile () { echo "$* -o hello hello.c" eval "$* -o hello hello.c" file hello | sed -e 's/, dynamically linked.*$//' } compile /opt/SUNWspro/bin/cc compile /opt/SUNWspro/bin/cc -xtarget=generic compile /opt/SUNWspro/bin/cc -xtarget=generic64 compile /openpkg-dev/bin/gcc compile /openpkg-dev/bin/gcc -m32 compile /openpkg-dev/bin/gcc -m64 $ sh hello.sh sparc64-solaris10 /opt/SUNWspro/bin/cc -o hello hello.c hello: ELF 32-bit MSB executable, SPARC32PLUS, V8+ Required, version 1 (SYSV) /opt/SUNWspro/bin/cc -xtarget=generic -o hello hello.c hello: ELF 32-bit MSB executable, SPARC32PLUS, V8+ Required, version 1 (SYSV) /opt/SUNWspro/bin/cc -xtarget=generic64 -o hello hello.c hello: ELF 64-bit MSB executable, SPARC V9, version 1 (SYSV) /openpkg-dev/bin/gcc -o hello hello.c hello: ELF 32-bit MSB executable, SPARC, version 1 (SYSV) /openpkg-dev/bin/gcc -m32 -o hello hello.c hello: ELF 32-bit MSB executable, SPARC, version 1 (SYSV) /openpkg-dev/bin/gcc -m64 -o hello hello.c hello: ELF 64-bit MSB executable, SPARC V9, version 1 (SYSV) $ sh hello.sh amd64-solaris10 /opt/SUNWspro/bin/cc -o hello hello.c hello: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV) /opt/SUNWspro/bin/cc -xtarget=generic -o hello hello.c hello: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV) /opt/SUNWspro/bin/cc -xtarget=generic64 -o hello hello.c hello: ELF 64-bit LSB executable, AMD x86-64, version 1 (SYSV) /openpkg-dev/bin/gcc -o hello hello.c hello: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV) /openpkg-dev/bin/gcc -m32 -o hello hello.c hello: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV) /openpkg-dev/bin/gcc -m64 -o hello hello.c hello: ELF 64-bit LSB executable, AMD x86-64, version 1 (SYSV) 4. So what? You see that what OpenPKG by default provides here is neither better nor worse than what the OS vendor provides. And because of the "you cannot mix 32 and 64 bit code in a single executable on these platforms" constraint we even CANNOT change this _IN GENERAL_. But, but, but.... please stop complaining, Hackers! There is a possibility, of course ;-) Nevertheless _YOU_ can change it for your _particular_ situation if you follow the following procedure: (a) bootstrap a fresh OpenPKG instance (say under /openpkg) with just the packages (in this order): openpkg, make, binutils, gcc. (These are usually still built in 32-bit mode.) (b) force OpenPKG's GCC into 64 bit mode now by default. 1. for honest build environments of packages which correctly honor %{l_cc}/%{l_cxx} and this way don't need any hacking: $ vi ~/.rpmmacros | # force OpenPKG GCC into 64 bit mode by default | %l_cc /openpkg-dev/bin/gcc -m64 | %l_cxx /openpkg-dev/bin/g++ -m64 2. for nasty build environments of packages which call cc/c++/gcc/g++ directly as they insist it is in the $PATH: $ for name in cc gcc c++ g++; do \ ( echo '#!/bin/sh'; \ echo "exec /openpkg/bin/$name \"[EMAIL PROTECTED]"" \ ) >/openpkg/lib/openpkg/override/$name; \ chmod 755 /openpkg/lib/openpkg/override/$name; \ done (c) rebuilt the existing 4 packages immediately: $ /openpkg/bin/openpkg build -ZaKB | sh (These are now built in 64-bit mode.) (d) Voila! You should now have a 64-bit only instance! Now just proceed as usual by installing an arbitrary set of additional OpenPKG packages... Well, plus minus the usual amount of funny problems, this should do the trick for you. But as I have not the time available for in-depth testing, it is more or less like in Knuth's famout quote: "I have only proved it correct, not tried it." Fact #4: It _IS_ possible to build a complete OpenPKG 64-bit environment under Solaris 10/amd64 and Solaris 10/sparc64. (PS: No, I don't think all this works with Solaris 9 or even older as the GNU tool chain doesn't seem to support multiple architectures there). Yours, Ralf S. Engelschall [EMAIL PROTECTED] www.engelschall.com ______________________________________________________________________ The OpenPKG Project www.openpkg.org User Communication List openpkg-users@openpkg.org
