Difference between revisions of "GNU Linux Sparc Porting"

From Apache OpenOffice Wiki
Jump to: navigation, search
(which shell to use ? was Cross compiling ?)
m (clarification of Specific code for GNU/Linux sparc)
Line 65: Line 65:
 
== Specific code for GNU/Linux sparc ==
 
== 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 platforms. The following list is not complete  but it provides some examples and will be gradually increased. A full history of the sparc port can be found in issuezilla, just look for issues where sparcmoz has reported or commented.
+
No sparc patches are required as the items described below are already integrated in the source. This discussion is only to provide an understanding of the work already done for the port. There are only a small number of places where GNU/Linux sparc requires different code than used by other platforms. The following list is not complete  but it provides some examples and will be gradually increased. A full history of the sparc port can be found in issuezilla, just look for issues where sparcmoz has reported or commented.
  
 
===Platform make file===
 
===Platform make file===

Revision as of 09:54, 24 March 2006

GNU Linux Sparc Porting

The objective is to maintain the complete 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" released version that can be used for confirming who owns any bugs, while not interfering with the distribution installed packages.

For GNU/Linux sparc all building now is done with gcj. Upstream contributed builds use gcc4.1. Distribution packagers use the following versions:

Debian -  gcc4.0(?)/gcj
Gentoo?
any others?

Other projects that need more work:

- fix multimedia (sound was partly working in m137 but not since, and Java Media Framework does not run with any GNU/Linux with gcj)

- qa needs to be done

- very slow startup (depends on javaldx?)

The latest upstream release is on mirrors under pub/OpenOffice.org/contrib/linuxsparc. Only released builds will be uploaded ie 2.0.2, 2.0.3...

What is SPARC?

SPARC means Scalable Processor ARChitecture about SPARC

The most common hardware implementation is done by Sun Sun

Most GNU/Linux sparc/sparc64 users are running surplus (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 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, with the main issues being:

configuration must be told what platform to use for the product, and to ignore the build platform, when setting the build environment

compiler flag "-m32" will tell gcc to build sparc and not sparc64
some modules (only in external?) will not obey the configured environment

The most common bad behaviour occurs 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 "gcc" which may be /usr/bin/gcc"

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 seems 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

No sparc patches are required as the items described below are already integrated in the source. This discussion is only to provide an understanding of the work already done for the port. There are only a small number of places where GNU/Linux sparc requires different code than used by other platforms. The following list is not complete but it provides some examples and will be gradually increased. A full history of the sparc port can be found in issuezilla, just look 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

PICSWITCH:=-fPIC

Platform specific identifier for shared libs

DLLPOSTFIX=ls
DLLPRE=lib
DLLPOST=.so

Module sal

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. Some of this may be obsolete now and needs further investigation:

sal/osl/unx/backtrace.c
sal/osl/unx/backtrace.h

The following code provides runtime detection of the user hardware and loads some different code at start up.

sal/osl/unx/util.c
sal/osl/unx/asm/interlck_sparc.s

This file is modified to build the preceding files

sal/osl/unx/makefile.mk

Module sc

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

Module bridges

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

Hardware issues

postprocess - checkdeliver fails

To make enough space for building on my sunblade 100, the output files are deleted after delivery. But post process tries to compare pre- and post- delivered files, sigh...workaround is to skip the checkdeliver step

TODO: configuration, installation

Building with GCC 4.1

These notes are based on m157, build completed.

The main issue affects runtime i59722 gcc-4.1: undefined usage of pointers in the icu module

Get the up-to-date patch here:
wget http://www.go-oo.org/patches/src680/buildfix-gcc41-pointers-icu.diff

The following notes are specific for gcc4.1. General issues for gcj and gcc4.0 are set out in another section below.

In my case 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

For GNU/Linux sparc it is necessary to get the bridges patches from cws_src680_warnings01. That needs the patches for sal and psprint. Other platforms might not need these. For psprint it may be sufficient to apply only the patches for source/fontsubset/gsub.cxx and source/fontsubset/gsub.h. To get these patches if they are needed where XXX is the current resync state of warnings01, expect a few rejects might need to be applied by hand.

$ cvs diff -u -r SRC680_mXXX -r cws_src680_warnings01 bridges > bridges.diff
$ cvs diff -u -r SRC680_mXXX -r cws_src680_warnings01 sal > sal.diff
$ cvs diff -u -r SRC680_mXXX -r cws_src680_warnings01 psprint > psprint.diff
module sd issue 61875 gcc-4.1: no matching function for call to GetIdleState

For GNU/Linux sparc there is excessive time required building the precompiled libraries for java parts, so I remove the code from sub cachejar in solenv/bin/deliver.pl so that when sub cachejar is called it does nothing.

The following may be out of date, needs to be confirmed

To run dmake runtest in testtools/source/bridgetest/pyuno it was necessary to update PYTHONPATH and revert the makefile ( see issue 40091 ). This may be useful to remember later...

Building with gcj >= 4.0

Since m155 at least, building with gcj is fully supported "out of the box" apart from a few issues mentioned below. The following describes how I build with gcj. The work to make this possible was mostly done by Caolan cmc@openoffice.org and of course gcc.gnu.org

Step 1: get a version of gcc with suitable gcj

I think that gcc >= 4.0 is necessary, in my case I get the latest preview gcc4.1 sources 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. To adapt the code to those commands use cws_src680_maho1. Finally 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="/usr/local/bin/gcc -m32"

$ export CXX="/usr/local/bin/g++ -m32"

$ ./configure --with-jdk-home=/usr/local/4.1 --with-java=gij \

--enable-crashdump=STATIC --enable-symbols=SMALL --enable-build-mozilla \

--with-package-format=rpm

Step 4: Build

berkeleydb - see issue 54657
berkeleydb has hardcoded "java" command with fallback to JAVA but environment defines JAVAINTERPRETER. A workaround is export JAVA=/path/to/gij
xmlhelp - needs this patch xmlhelp
This will be fixed when cws_src680_jaxpapi is integrated
filter - needs patches for this module from cws_src680_jaxpapi
instsetoo_native - preregistering java components fails. 
A workaround for gcc4.1 has been provided here: preregistering java components
cachejar: there are some problems compiling jar files with gcj, so that some files need large memory > 700mb and others never finish (xalan). 
Some enhancements are coming, in the meantime disable cachejar code in deliver.pl
moz: not gcj related...note here for convenience
moz needed patch here ...Issue 59842

Building with debian/unstable gcc4.0/gcj

I have completed building OOB680_m5 with debian/unstable gcc4.0, gcj, ant, java-gcj-compat-dev. My configure flags:

./configure --enable-build-mozilla --with-ant-home=/usr/share/ant

The resulting build environment by jim@sun:~/vanilla$ set | grep JA

JAVACOMPILER=/usr/bin/javac
JAVADOC=/usr/bin/javadoc
JAVAINTERPRETER=/usr/bin/java
JAVA_HOME=/usr
NEW_JAR_PACK=TRUE
SOLAR_JAVA=TRUE

With gcc-4.0 it is not possible to call ant the direct way so some patches are needed. Also there is a problem with cachejar so it will be disabled. The patches are at Issue 62905

Debian/unstable provides this version of "make":

jim@sun:~$ make -v
GNU Make 3.81rc1
Copyright (C) 2006  Free Software Foundation, Inc.

This needs the patch at Issue 59482

xmlhelp - needs this patch xmlhelp
This will be fixed when cws_src680_jaxpapi is integrated
xmerge needs to be updated with cws_src680_jaxpapi
filter - needs patches for this module from cws_src680_jaxpapi
instsetoo_native - preregistering java components fails. 
A workaround for gcc4.1 has been provided here:
preregistering java components 
but this does not help for gcc-4.0 
so it is necessary to ignore the error 
but the product works fine anyway, 
except the first 3 wizards in File-Wizards do not start.

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
Personal tools