OpenOffice.org is an Open Source, community-developed, multi-platform office
productivity suite. It includes the key desktop applications, such as a
word processor, spreadsheet, presentation manager, and drawing program,
with a user interface and feature set similar to other office suites.
Components include:
* A universal word processing application for creating business
letters, extensive text documents, professional layouts, and HTML
documents.
* A sophisticated application for performing advanced spreadsheet
functions, such as analyzing figures, creating lists, and viewing data.
* A tool for creating effective eye-catching presentations.
* A vector-oriented draw module that enables the creation of 3D
illustrations
I made the mozilla distfiles about 4MB smaller. The includes are always
the same, so there isn't any reason we should include them in each
version. Change the MD5 checksums one last time.
Remove very very stupid -L/lib -L/usr/lib -l/usr/local/lib. If
a different gcc is used, they make libstd++ conflict with the
system installed one.
Pointy hat to OpenOffice people.
Many thanks to: David E. O'Brien <obrien@FreeBSD.org>
We finally made it possible. With the new bridge code from Alexander,
OpenOffice works now (on STABLE). Thanks goes to the following people
which helped me a lot :
Tim Tretyak <timothy@umc.com.ua>
Alexander Kabaev <ak03@gte.com>
Carlos F. A. Paniago <pan@panix.ecof.org.br>
Add new cpp uno bridge for STABLE. Make the necessary hooks and also add
the missing EXCEPTION argument to configure.in
Submitted by: Alexander Kabaev <ak03@gte.com>
Work around the broken deliver.pl behaviour on CURRENT. For some very
strange reason (perl bug ?i), deliver does not copy the includes to
the right place, it just skips them. Just copy the includes to the
right place.
Second part, forgot to commit it.
Make openoffice compile with gcc from ports, or just with CC=$CC and
CXX=$CXX, like it should normally be. Usable options are:
USEPORTGCC295=YES, USEPORTGCC31=YES and USEPORTGCC32=YES
Add a lot off gcc3.x fixes, make included stlport compile with CURRENT.
Next step will be to include a mozilla build, so we can link openoffice
against mozilla librarys without c++ compat problems.
Make openoffice compile with gcc from ports, or just with CC=$CC and
CXX=$CXX, like it should normally be. Usable options are:
USEPORTGCC295=YES, USEPORTGCC31=YES and USEPORTGCC32=YES
Add a lot off gcc3.x fixes, make included stlport compile with CURRENT.
Next step will be to include a mozilla build, so we can link openoffice
against mozilla librarys without c++ compat problems.
Mark it broken again.
It seems that our c++ (2.95.3) has still bugs. This time c++ exceptions
do not work as they should and instead a clean exit we get a segfault.
This works with a virgin 2.95.3 compiler, or even the one in the ports
collection. Another bug is a internal compiler error during compile
a part of OO without -g or with -O.
The rtld-elf symbolcache seems to have problems too. If used,
the installation coredumps. A workaround seems to disable the
caching altough this can't be the real solution.
There is also an outstanding problem in the uno-bridge code of OO.
We are currently investigating it:
http://www.openoffice.org/issues/show_bug.cgi?id=5071
Fix the last commit. Since OO was only compileable in a little
timeframe on CURRENT, mark it broken for all CURRENT versions.
Beside that, the logic was wrong.
Fix one mastersite, add install targets and remove the os version check.
I think if the gcc fixes for oo go in before 4.6, we can check against
this version later.
Openoffice does build now till the end. A normal build with a P800 Mhz
does take approximatly 20 hours.
Go back to mozilla 2.95 includes, a newer version has LDAP code
problems and doesn't compile. We can bump later to 1.0, if the
openoffice project does the same.
Upgrade to build 641d. More work is necessary to make the build compile.
There are still at least two different gcc bugs in our compiler, one
issue has already been found by Alexander Kabaev <ak03@gte.com>. He's
working on fixing the other.
Revert the last change. It looks like -fno-rtti is only needed for the
mozilla part, and else it breaks the build where -rtti is used. Add a new
patch to change it for the mozilla build.
Add ASM flags, replace the REENTRANT and THREAD_SAFE definitions with
-pthread, add JAVA_RUNTIME definition, change the optimization from 02 to -O
and from -O to -O0. Add -lXaw -lXt to link for GUI part, and reorder the
librarys the correct way.
Use autoconf, remove the ugly configure patch. Do the gcc tests and fix them
while we are here (AWK had an endless loop), add a FreeBSD configure variable
called with-os-version, so we can check the OSVERSION in the build to support
both STABLE and CURRENT (there are different patches needed)
