Difference between revisions of "GNU Linux Sparc Porting"

From Apache OpenOffice Wiki
Jump to: navigation, search
(→‎finished m155 Building with gcc4.1/gcj on GNU/Linux Sparc)
m (removed historical page from its category list)
 
(89 intermediate revisions by 4 users not shown)
Line 1: Line 1:
−
== GNU Linux Sparc Porting ==
+
{{historical}}
  
−
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.
+
The objective is to maintain the upstream sources so that the GNU/Linux [http://en.wikipedia.org/wiki/SPARC 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.
−
 
+
−
For GNU/Linux sparc all building now is done with gcj. The gcj versions being used for upstream contributed builds are gcc4.0.2 and gcc4.1. Distribution packagers use the following versions:
+
−
 
+
−
Debian -  gcc4(?)/gcj
+
−
Gentoo?
+
−
any others?
+
  
 
Other projects that need more work:
 
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)
+
* fix multimedia
 +
* more qa needs to be done
  
−
- qa needs to be done
+
The latest upstream release is on OpenOffice.org mirrors under contrib/linuxsparc
−
 
+
−
- very slow startup (depends on javaldx?)
+
−
 
+
−
The latest upstream release is on mirrors under pub/OpenOffice.org/contrib/linuxsparc
+
  
 
== What is SPARC? ==
 
== What is SPARC? ==
  
−
SPARC means Scalable Processor ARChitecture [http://www.sparc.org about SPARC]
+
SPARC means Scalable Processor ARChitecture [http://www.sparc.org/ about SPARC]
−
 
+
−
The most common hardware implementation is done by Sun [http://www.sun.com 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.
+
The most common hardware implementation is done by [http://www.sun.com/ 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:
 
There are 2 main flavours of SPARC hardware:
Line 33: Line 23:
 
  64 bit known as sparc64 (uname -m returns sparc64)
 
  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.
+
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:
 
For example on my system I can find these files:
Line 42: Line 32:
 
  soffice.bin: ELF 32-bit MSB executable, SPARC, version 1 (SYSV), for GNU/Linux 2.2.0, dynamically linked (uses shared libs), stripped
 
  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? This requires something like "cross compiling" because the product runs on a platform different from the build system, but for sparc/sparc64 this is normal.
+
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 [http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=251149 more authoritative comment]
  
−
== Cross compiling ?==
+
== Which shell to use for building, sparc or sparc64? ==
  
−
I read somewhere that Openoffice.org build tools do not support cross compiling (where?). But something like cross compiling is achieved when building with multiple compiler versions installed, or when the target platform is different from the build platform.
+
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:
  
−
For GNU/Linux Sparc it can be done, 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
 
  compiler flag "-m32" will tell gcc to build sparc and not sparc64
  
−
some modules (only in external?) will not obey the configured environment
+
In the past bad behaviour occurred when a module ignores the configured compiler path or compiler flags.  For example:
−
 
+
−
installation has some hard-coded references to the target platform
+
−
 
+
−
 
+
−
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"
 
  configured to build with "/usr/local/4.1/bin/gcc -m32"
−
  module builds with "gcc" which may be /usr/bin/gcc"
+
  module builds with a different "gcc" for example /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?
+
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?
  
−
The other issue to investigate is that various tools are built and used during building. These tools need to be built for the building machine not for the target 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 ==
+
== 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.
+
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===
+
===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:
+
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   
 
If the assembler is called directly, it must build for sparc v7 by default (could use v8 safely?) and not v8plus or v9   
Line 89: Line 70:
  
 
===Module sal===
 
===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:
+
 
 +
 
 +
 
 +
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:
 
  sal/osl/unx/backtrace.c
 
  sal/osl/unx/backtrace.c
 
  sal/osl/unx/backtrace.h
 
  sal/osl/unx/backtrace.h
  
−
The following code provides runtime detection of the user hardware and loads some different code at start up.
+
The following code provides runtime detection of the user hardware (sparc or sparc64) and loads some different code at start up.
 
  sal/osl/unx/util.c
 
  sal/osl/unx/util.c
 
  sal/osl/unx/asm/interlck_sparc.s
 
  sal/osl/unx/asm/interlck_sparc.s
Line 101: Line 85:
  
 
===Module sc===
 
===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:
+
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/data/makefile.mk:.IF "$(OS)$(COM)$(CPUNAME)"=="LINUXGCCSPARC"
Line 129: Line 113:
 
===Module bridges===
 
===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.
 
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
 
TODO: configuration, installation
  
−
== Building with GCC 4.1 ==
+
== Building OOo on GNU/Linux SPARC with OpenJDK ==
  
−
The main issue affects runtime
+
This is work in progress. The first step is to build OpenJDK.
−
[http://qa.openoffice.org/issues/show_bug.cgi?id=59722 i59722 gcc-4.1: undefined usage of pointers in the icu module]
+
  
−
Get the up-to-date patch here:
+
No distributions are shipping OpenJDK for sparc yet (please correct me if I'm wrong ;)
−
wget http://www.go-oo.org/patches/src680/buildfix-gcc41-pointers-icu.diff
+
  
−
==  Building with gcc4.1/gcj on GNU/Linux Sparc  ==
+
On Debain/sid I have got the build dependencies OK, configured and started ./make for icedtea6 from icedtea.classpath.org
  
−
'' These notes are based on m155, build completed.''
+
For the first build I will play it safe - building in a sparc shell:
  
−
Those cws have been integrated now so minimal changes are required for building.
+
$ linux32 bash
 +
$ ./configure
 +
$ ./make
  
−
In my case GCC 4.1 is built using gcc.gnu.org sources checked out from gcc-4.1-branch and installed in /usr/local/4.1.
+
Progress will be tracked at [http://qa.openoffice.org/issues/show_bug.cgi?id=91484 issue 91484]
−
 
+
−
SRC_ROOT is jim@sun:~/build680
+
−
Everything is run from SRC_ROOT unless stated.
+
−
 
+
−
$ export CVSROOT=:pserver:anoncvs@anoncvs.services.openoffice.org:/cvs
+
−
$ cvs -z4 co -r SRC680_mNNN OpenOffice2
+
−
 
+
−
Set the compiler variables. When building on sparc64, the -m32 is required to build for sparc:
+
−
$ export CC="/usr/local/4.1/bin/gcc -m32"
+
−
$ export CXX="/usr/local/4.1/bin/g++ -m32"
+
−
 
+
−
Adjust the PATH so there is no other gcc or gxx in the PATH, and that there is no fake java, so there is nothing returned by:
+
−
$ which gcc
+
−
$ which java
+
−
 
+
−
If gjdoc is not in the jdk_home then it will not be found so:
+
−
$ export JAVADOC=/usr/local/bin/gjdoc
+
−
Temporary workaround for ant in xmerge also need a link from /usr/bin/javadoc --> /usr/local/bin/gjdoc
+
−
 
+
−
For berkeleydb hardcoded java
+
−
$ export JAVA=/usr/local/4.1/bin/gij
+
−
 
+
−
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
+
−
 
+
−
 
+
−
Some patches for ant and gcj may be required, depending on the builders tools and environment.
+
−
In my case the following are required (These will be attached at issue 50599):
+
−
 
+
−
ant-gcj.diff: set the ant flags for gcj in sal/inc/ant.mk and/or antsettings.mk
+
−
fastjar.diff: issue 57565, also need export JAR=/usr/local/4.1/bin/fastjar
+
 
   
 
   
−
TODO: build with all of warnings01
 
  
−
Out of Memory: qadevOOo with gcj will need about 800-1000mb of RAM, but I have only 256mb. I must remember to increase swap file to 1000mb to be safe.
+
== Building with GCC 4.1.2 (preview) ==
  
−
Patch to build module sd with gcc-4.1 courtesy of caolan (cmc)
+
This section is deprecated - the SPARC build works fine on debian with java-gcj-compat.
−
[http://qa.openoffice.org/issues/show_bug.cgi?id=61875 issue 61875 gcc-4.1: no matching function for call to GetIdleState]
+
  
 +
''I don't mention here any issues that affect gcc < 4.1 ''
  
−
''The following may be out of date, needs to be confirmed ''
+
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
  
−
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...
+
Also need put ecj.jar in the source file - see gcc instructions for building gcj with ecj
  
−
== Building with gcj ==
 
−
This is mainly intended as a diary to remind myself what i am doing. Building with gcj is not fully supported "out of the box" and anyone seeking to build this way will need to figure out some things for themselves. Recent patches for building GNU Linux Sparc with gcj are at i50599 but these will not be committed as they are specific to my building environment.
 
  
−
[http://www.openoffice.org/issues/show_bug.cgi?id=50599 i50599 Build GNU Linux Sparc with gcj]
+
=== Step 1: get a version of gcc with suitable gcj ===
  
−
The following describes how I build with gcj. I believe the work to make this possible was mostly done by Caolan and Rene showed me how to get Ant working.
+
In my case I get gcc version that builds with ecj, and build gcc into /usr/local/4.1
  
−
Step 1: get a version of gcc with suitable gcj.
+
=== Step 2: set up the required commands for build tools ===
−
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 because gcj was for some time not working on debian/unstable. And it is easier to see what is happening without the various workarounds to provide commands such as java that do not really exist.
+
  
−
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
  
−
Note that the required compiler can be specified by setting environment variables CC and CXX before running configure, but the same is not possible for some related programs. In just a few places the code expects these commands to be available, normally in /usr/bin:
+
=== Step 3: configure ===
−
java
+
−
javac
+
−
jar
+
−
 
+
−
But building gcc provides instead the corresponding commands:
+
−
gij
+
−
gcj
+
−
fastjar (gcc 4.1)
+
−
 
+
−
Some distributions will arrange for the java etc commands to be available, but the method to provide these varies between distributions and over time. In my opion it will be better to let these be defined by the configuration step, but I am a long way from knowing how that should be done!
+
−
 
+
−
With /usr/local/bin in my PATH the configuration finds /usr/local/bin/gjdoc without being asked. In anycase it is possible to define the following for the configurator: JAVADOC=/usr/local/bin/gjdoc
+
−
 
+
−
Configuration --with-java=gij and --with-jdk-home=/usr/local takes care of gij and gcj in most cases. Patches are needed to workaround one case of hardcoding for each of java and jar.
+
−
 
+
−
Ant is more complicated, the basic idea is to set up the required command line and parameters to invoke Ant in solenv/inc/ant.mk depending on how Ant is installed, and is better explained by reviewing the patches here [http://www.openoffice.org/issues/show_bug.cgi?id=50599 i50599 Build GNU Linux Sparc with gcj]
+
−
 
+
−
 
+
−
Step 3: configure
+
  
 
In my case the configure commands may be like this:
 
In my case the configure commands may be like this:
  
−
$ export CC="/usr/local/bin/gcc -m32"
+
$ export CC="ccache /usr/local/bin/gcc -m32"
  
−
$ export CXX="/usr/local/bin/g++ -m32"
+
$ export CXX="ccache /usr/local/bin/g++ -m32"
  
−
$ ./configure --with-jdk-home=/usr/local --with-java=gij
+
$ ./configure --with-jdk-home=/usr/local/4.1 \
  
 +
--with-ant-home=/usr/local/apache-ant-1.6.5 \
  
−
For my patches to avoid using java and jar commands I will also define the following:
+
--enable-crashdump=STATIC --enable-symbols=SMALL --enable-build-mozilla \
  
−
$ export JAR=/usr/local/bin/fastjar
+
--with-package-format=rpm \
  
−
$ export JAVA=/usr/local/bin/gij  <-- needed for berkeleydb
+
--with-alloc=system
  
 +
Now if configure reports that "ant does not work" try this: export PATH=/path/to/gcj:$PATH
  
−
Step 4: packaging
+
Some additional [http://www.openoffice.org/servlets/ReadMsg?list=dev&msgNo=16375 hoops to jump through] for the crash reporter
  
−
Finally the build fails when preregistering java components. A workaround for gcc4.1 has been provided here: [http://www.openoffice.org/servlets/ReadMsg?list=dev&msgNo=15641 preregistering java components]
+
=== Step 4: Build ===
−
 
+
−
== Notes for Building with gcc4.0/gcj - m154 ==
+
−
 
+
−
Issues marked (*) arise because I am using pure gcc/gcj in /usr/local while other builders use fake java commands such as provided by java-gjc-compat?
+
−
 
+
−
bean - see [http://qa.openoffice.org/issues/show_bug.cgi?id=53880 issue 53880]
+
−
bean can not currently be built on debian/unstable due to issues with freetype. Issue 53880 references some upstream issues, but also note bean builds OK using --with-system-freetype. A not recommended workaround is to skip the failed test, by renaming the file bean/unxlngs.pro/lib/check_libofficebean.so to libofficebean.so then complete the build in the module and deliver
+
  
 
  berkeleydb - see [http://qa.openoffice.org/issues/show_bug.cgi?id=54657 issue 54657]
 
  berkeleydb - see [http://qa.openoffice.org/issues/show_bug.cgi?id=54657 issue 54657]
−
berkeleydb has hardcoded "java" command with fallback to JAVA but environment defines JAVAINTERPRETER. A workaround is export JAVA=/path/to/gij (*)
+
berkeleydb has hardcoded "java" command with fallback to JAVA but environment defines JAVAINTERPRETER. the fix is in cws_src680_maho1
−
 
+
−
xmerge - see [http://qa.openoffice.org/issues/show_bug.cgi?id=57286 issue 52786]
+
−
ant expects javadoc command and ignores environment JAVADOC=/path/to/gjdoc. A partial workaround is to make a fake command javadoc linked to gjdoc (*)
+
−
 
+
−
xmlhelp - needs this patch [http://util.openoffice.org/source/browse/util/xmlhelp/source/com/sun/star/help/GCJFileURLStreamHandler.java?r1=1.2&r2=1.2.2.1 xmlhelp]
+
−
This will be fixed when cws_src680_jaxpapi is integrated
+
−
 
+
−
filter - needs patches for this module from cws_src680_jaxpapi
+
  
−
  postprocess - checkdeliver fails
+
  sal: Since m166 some memory alignment problem will cause bus errors (signal 10 or SIGBUS) on GNU/Linux SPARC.
 +
This is referenced at  [http://www.openoffice.org/issues/show_bug.cgi?id=65788 issue 65788] and the workaround is configure --with-alloc=system
  
−
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
+
moz: some recent change in GCC? (4.1.2)  mimeExternalObjectClass' with 'C++' linkage
 +
mimemult.cpp:76: error: conflicts with new declaration with 'C' linkage
 +
[http://qa.openoffice.org/issues/show_bug.cgi?id=66906 issue 66906] (fixed?)
  
 
== Installing from rpm without root access ==
 
== Installing from rpm without root access ==
Line 272: Line 192:
 
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 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
+
The rpm command is required but root access is not required

Latest revision as of 07:52, 22 June 2012

This page is archived for historical reasons only. It is no longer maintained and information may not be current.

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

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 

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. (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: 

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

The following code provides runtime detection of the user hardware (sparc or sparc64) 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

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 \

--with-ant-home=/usr/local/apache-ant-1.6.5 \

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

--with-package-format=rpm \

--with-alloc=system 

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

Retrieved from "https://wiki.openoffice.org/w/index.php?title=GNU_Linux_Sparc_Porting&oldid=202437"
Personal tools