Difference between revisions of "GNU Linux Sparc Porting"
(→Building GNU/Linux SPARC with OpenJDK)
m (added Category:Build_System)
|Line 193:||Line 193:|
Revision as of 03:04, 29 December 2008
The objective is to maintain the upstream sources so that the GNU/Linux SPARC platform can be packaged for example by Debian, Gentoo, and others. Also to provide an upstream "benchmark" version that can be installed for checking who owns any bugs, while not interfering with the distribution's installed packages. For GNU/Linux SPARC all Java building is done with gcj.
Other projects that need more work:
- fix multimedia
- more qa needs to be done
The latest upstream release is on OpenOffice.org mirrors under contrib/linuxsparc
- 1 What is SPARC?
- 2 Which shell to use for building, sparc or sparc64?
- 3 Specific code for GNU/Linux SPARC
- 4 Building OOo on GNU/Linux SPARC with OpenJDK
- 5 Building with GCC 4.1.2 (preview)
- 6 Installing from rpm without root access
What is SPARC?
SPARC means Scalable Processor ARChitecture about SPARC
The most common hardware implementation is done by Sun.
Most GNU/Linux SPARC users are running second-hand hardware which may be quite old and the installed user base and developer resources are relatively small.
There are 2 main flavours of SPARC hardware:
32 bit known as sparc (uname -m returns sparc) 64 bit known as sparc64 (uname -m returns sparc64)
GNU/Linux is ported to run on both sparc and sparc64, there are separate kernels for sparc and sparc64 but the majority of user software is designed to run on both sparc and sparc64.
For example on my system I can find these files:
jim@sun:/boot$ file vmlinux-2.6.13 vmlinux-2.6.13: ELF 64-bit MSB executable, SPARC V9, version 1 (SYSV), statically linked, not stripped
jim@sun:~/o147/program$ file soffice.bin soffice.bin: ELF 32-bit MSB executable, SPARC, version 1 (SYSV), for GNU/Linux 2.2.0, dynamically linked (uses shared libs), stripped
So the first issue for porting is, how to build the 32 bit product on a 64 bit system? The simple and correct method is to build in a shell where the command "uname -m" will return "sparc" on a "sparc64" machine. This is achieved by using the command "sparc32 bash" or "linux32 bash" to get the shell for building. See here for a more authoritative comment
Which shell to use for building, sparc or sparc64?
But for maintaining the port I prefer to not use the sparc shell (from the "linux32 bash" command) because that might hide some bugs or bad behaviour. For GNU/Linux Sparc the 32 bit product can be built in the sparc64 shell, by the simple method of:
compiler flag "-m32" will tell gcc to build sparc and not sparc64
In the past bad behaviour occurred when a module ignores the configured compiler path or compiler flags. For example:
configured to build with "/usr/local/4.1/bin/gcc -m32" module builds with a different "gcc" for example /usr/bin/gcc"
Currently there are no examples of this bad behaviour. This will not be easily noticed unless all alternative possible compilers are excluded from the configured environment path. Still there remains a risk that a module will seek "/usr/local/bin/gcc" and find it. This sometimes seemed to involve using libtool which may have some defaults configured on the build machine?
In summary, building in the sparc shell is the simple and correct method, but building in a sparc64 shell is better for finding bugs.
Specific code for GNU/Linux SPARC
There are only a small number of places where GNU/Linux SPARC requires different code than used by other GNU/Linux platforms. The following list is not complete but it provides some examples and will be gradually increased. For a full history of the GNU/Linux SPARC port just query Issuezilla for issues where sparcmoz has reported or commented.
Platform Make file
Various compiler and other flags are set in the platform Make file solenv/inc/unxlngs.mk. That file is kept as close as possible to solenv/inc/unxlngi6.mk but the following differences are important:
If the assembler is called directly, it must build for sparc v7 by default (could use v8 safely?) and not v8plus or v9
# mk file for unxlngs ASM=$(CC) AFLAGS=-Wa,-K,PIC -c $(CDEFS)
Code must be compiled with -fPIC, as -fpic will not do for sparc/sparc64
Platform specific identifier for shared libs
DLLPOSTFIX=ls DLLPRE=lib DLLPOST=.so
GNU/Linux SPARC did not provide an implementation of frame.h that was needed for backtrace functions. It was also needed to provide the backtrace function without using the crash reporter. (This is out of date - it is no longer required. I need to remove this code from OOo sources). Backtrace is currently broken, possibly something here:
The following code provides runtime detection of the user hardware (sparc or sparc64) and loads some different code at start up.
This file is modified to build the preceding files
A number of runtime isssues (crash) were found with the early builds of the spreadsheet using gcc 3.2. A workaround was found to compile certain files with no optimisation. A review of the code suggests similar issues were found with other platforms, but in different files. The files were found fairly quickly by using a binary search pattern to locate the files that caused the crashes (build - test - crash - build half the files again without optimisation). Fortunately this type of work-around is supported by the build system environment variables NOOPTFILES and EXCEPTIONSNOOPTFILES! It is possible some of these issues have gone away with later compilers, further investigation is needed. Refer to the source code as follows:
sc/source/core/data/makefile.mk:.IF "$(OS)$(COM)$(CPUNAME)"=="LINUXGCCSPARC" sc/source/core/tool/makefile.mk:.IF "$(OS)$(COM)$(CPUNAME)"=="LINUXGCCSPARC" sc/source/filter/excel/makefile.mk:.IF "$(OS)$(COM)$(CPUNAME)"=="LINUXGCCSPARC" sc/source/ui/unoobj/makefile.mk:.IF "$(OS)$(COM)$(CPUNAME)"=="LINUXGCCSPARC" sc/source/ui/view/makefile.mk:.IF "$(OS)$(COM)$(CPUNAME)"=="LINUXGCCSPARC"
A typical example follows from sc/source/core/data/makefile.mk:
.IF "$(OS)$(COM)$(CPUNAME)"=="LINUXGCCSPARC" NOOPTFILES= \ $(SLO)$/column2.obj \ $(SLO)$/column3.obj \ $(SLO)$/table3.obj \ $(SLO)$/table4.obj \ $(SLO)$/documen4.obj \ $(SLO)$/conditio.obj \ $(SLO)$/validat.obj EXCEPTIONSNOOPTFILES= \ $(SLO)$/cell.obj .ELSE EXCEPTIONSFILES+= \ $(SLO)$/cell.obj .ENDIF
The bridges code in bridges/source/cpp_uno/gcc3_linux_sparc is copied exactly from the corresponding gcc3_linux_intel and only the assembler snippets have been changed.
TODO: describe bridges code
TODO: configuration, installation
Building OOo on GNU/Linux SPARC with OpenJDK
This is work in progress. The first step is to build OpenJDK.
No distributions are shipping OpenJDK for sparc yet (please correct me if I'm wrong ;)
On Debain/sid I have got the build dependencies OK, configured and started ./make for icedtea6 from icedtea.classpath.org
For the first build I will play it safe - building in a sparc shell:
$ linux32 bash $ ./configure $ ./make
Progress will be tracked at issue 91484
Building with GCC 4.1.2 (preview)
This section is deprecated - the SPARC build works fine on debian with java-gcj-compat.
I don't mention here any issues that affect gcc < 4.1
I normally build using debian gcc/ecj but if it is desired to build gcc too, then GCC 4.1 is built using gcc.gnu.org sources checked out by svn from gcc-4_1-branch and installed in /usr/local/4.1 with these configure flags: --prefix=/usr/local/4.1 --enable-java-awt=gtk,xlib
Also need put ecj.jar in the source file - see gcc instructions for building gcj with ecj
Step 1: get a version of gcc with suitable gcj
In my case I get gcc version that builds with ecj, and build gcc into /usr/local/4.1
Step 2: set up the required commands for build tools
Note that the required compiler can be specified by setting environment variables CC and CXX before running configure. The code expects some "java" commands to be available in the PATH: java jar javadoc. Different distributions provide those commands in different ways, but when using one's own gcc built from upstream sources then gcc provides instead the corresponding commands: gij fastjar gjdoc. There is an issue with internal ant commands in build files in xmerge so that a symbolic link is needed: javadoc-> gjdoc
Step 3: configure
In my case the configure commands may be like this:
$ export CC="ccache /usr/local/bin/gcc -m32"
$ export CXX="ccache /usr/local/bin/g++ -m32"
$ ./configure --with-jdk-home=/usr/local/4.1 \
--enable-crashdump=STATIC --enable-symbols=SMALL --enable-build-mozilla \
Now if configure reports that "ant does not work" try this: export PATH=/path/to/gcj:$PATH
Some additional hoops to jump through for the crash reporter
Step 4: Build
berkeleydb - see issue 54657 berkeleydb has hardcoded "java" command with fallback to JAVA but environment defines JAVAINTERPRETER. the fix is in cws_src680_maho1
sal: Since m166 some memory alignment problem will cause bus errors (signal 10 or SIGBUS) on GNU/Linux SPARC. This is referenced at issue 65788 and the workaround is configure --with-alloc=system
moz: some recent change in GCC? (4.1.2) mimeExternalObjectClass' with 'C++' linkage mimemult.cpp:76: error: conflicts with new declaration with 'C' linkage issue 66906 (fixed?)
Installing from rpm without root access
The GNU Linux Sparc packages from contrib/linuxsparc should not interfere with installations provided by the various distribution packagers such as debian, gentoo etc. Therefore the supplied rpms can be installed in the user's home directory using the install_linux.sh script which is available on mirrors at pub/OpenOffice.org/developer/install_scripts/
The rpm command is required but root access is not required