SPARC-specific Issues After Installation (Running Linux)

F.5. SPARC-specific Issues After Installation

On UltraSPARC systems, the current provided userland is still 32-bit (even though the processor and the kernel itself are 64-bit). One advantage of this is that nearly all Linux/SPARC applications run unchanged between different Linux/SPARC machines. A 64-bit userland is (at the time of this writing) scheduled to be deployed in the summer of 1999. The 32-bit libraries will remain in the distribution so that users can still run their legacy 32-bit Linux/SPARC binaries.

One side effect of the current UltraSPARC 32-bit userland is that you need to take some care when compiling applications from source. Since the machine (and kernel) is 64-bit, the uname facility will report sparc64 as the system type, instead of just plain sparc (which is what all the non-UltraSPARC systems report).

Several build scripts used to drive the compilation of source packages (such as GNU autoconf ) use this identification string to determine various aspects about the compilation environment (the sizes of various types in the C languages, and so on). The GNU utilities are going to do the wrong thing, because they see a 64-bit SPARC system type being reported, yet the userland runtime is 32-bit.

To overcome this issue, a tool called sparc32 is provided on Linux/SPARC systems. Before you configure and build to compile some source-code package, invoke a subshell with a sparc32 sh command. This will cause all uname queries done in that subshell (and thus by the programs run from it) to report plain sparc as the system type. This solves the problem.