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:
pgpYHx0OsgMUM.pgp
Description: PGP signature