Hi all,
the last days, we work hard on OpenOffice:
Peter Novodvorsky (nidd@debian.org) made a first package [1] of OpenOffice
depending on OpenOffice 638c. Be carefull, it is one package but it is
a beginning.
Bastian Blank (waldi@debian.org) was working on the support for gcc-3.0
in OpenOffice641. OpenOffice does not compile propper with gcc-3.0, the
638c branch requieres gcc-2.95.x and won't compile with gcc-3.0 at all.
You will find his patch a bit laeter. :)
Our Problems are the java-components. Java is highly non-free and has to
be thrown away from OpenOffice. Bastian is working on compiling the
javacode with gcj, but we did not have hope, that this will currently
working!
Then we were discussing, how we will provide OpenOffice. One package is
to bad. OpenOffice is modular, so we should use it.
The question is, dividing the source or only providing multiple
binaries.
Peter has made a picture [2] with the builddependency- tree, that shows us,
splitting the source is impossible.
With DBS (xfree, apache, ... were packaged with it) should it possible
to create multiple binaries easier.
Jan-Hendrik Palic (jan-palic@linux-debian.org) has asked for support and
the discuss mailinglist on OpenOffice.org for some support.
Here some answers about gpc and java, which are the nonfree parts in
OpenOffice.
---
Kevin B. Hendriks wrote :
The JDK is really only needed for the build itself (and even that is not
an issue since you could use jikes to compile the necessary classes).
So shipping it without the JDK is really not be a problem.
As for gpc, I too wish that the depedency on gpc goes away since it is
just a pain-in-the-butt to have to download and install it separately.
It is not a complex piece. Perhaps someone can write a replacement for it.
---
---
Jens-Heiner Rechtien:
regarding compiling with gcc-3.0.1: I'm mostly done with the necessary
changes. At least I've successfully linked the writer. There are several
open issues with gcc-3.0.1 - some map files needs additional exported
symbols (exception throwing over shared libary boundaries, 2 new
mapfiles, the bridge needs stress testing, imprss and calc some cleanup.
Maybe this week.
Indeed, bridges is a big problem ...
---
---
Martin Hollmichel
From 641 on most thing will work with 'unsetenv SOLAR_JAVA' and 'setenv
DISABLE_JAVA TRUE'.
Only one thing left, the usage of the JAVA xslt processor in officecfg.
In the moment I see not the chance to provide an other solution than
delivering of the transformed files with the build.
But maybe somebody is able to provide an other solution ?
> If we get autoconf into the buildsystem, it would be easier to build
> OpenOffice and you would be shell independend.
This was discussed several times earlier see arguments pro/contra in the
archives.
I see don't see this as a critical key for your project.
---
End of the mails on openoffice-discuss
But we are still working on it. I hope some more poeple will help us. :)
The bridges are a big problem. It is hardware dependend, it is required
to know something about assembler.
The change from javac to gcj is the next problem. gcj will not be able
to compile the javasource in openoffice, kaffe isn't it to.
If anyone knows a solution, please tell us!
The gpc seems not to be big and heavy, but we still need someone with
experiences in polygone- programming.
Help is everyday welcome :)
regards
Jan
[1] http://people.debian.org/~nidd/debian/unstable
[2] http://www.altlinux.ru/~nidd/oo/oo-components-depends.psz
--
One time, you all will be emulated by linux!
----
Jan- Hendrik Palic
Url:"http://www.billgotchy.de";
E-Mail: "palic@billgotchy.de"
-----BEGIN GEEK CODE BLOCK-----
Version: 3.12
GCS d- s: a-- C++ UL++ P+++ L+++ E W++ N+ o+ K- w---
O- M- V- PS++ PE Y+ PGP++ t--- 5- X+++ R-- tv- b++ DI-- D+++
G+++ e+++ h+ r++ z+
------END GEEK CODE BLOCK------
Attachment:
pgpBUmt6vOJEy.pgp
Description: PGP signature