OO.org2

[Thomas Fitzsimmons]

On Fri, 2005-03-04 at 15:54 -0500, Thomas Fitzsimmons wrote:
>On Fri, 2005-03-04 at 15:45 -0500, Dan Williams wrote: 
>>On Fri, 2005-03-04 at 15:36 -0500, Thomas Fitzsimmons wrote:
>>> On Fri, 2005-03-04 at 19:45 +0000, Caolan McNamara wrote:
>>> >On Thu, 2005-03-03 at 21:57 -0500, Dan Williams wrote:
>>> >> On Thu, 2005-03-03 at 23:10 +0000, Paul wrote:
>>> >> > Hi,
>>> >> > 
>>> >> > > So, it is in a beta candidate release now. The question is, is it going
>>> >> > > to be considered for FC4 or is FC4 going to be 1.1.x?
>>> >> > 
>>> >> > FC4 has slipped from the schedule slightly, so it the chances are that
>>> >> > if OOo2 is released (say) 1st week of April as a release, it stands a
>>> >> > good chance of being in.
>>> >> > 
>>> >> > Of course, I don't work for RH, so could be just speaking out of my
>>> >> > backside on that one.
>>> >> 
>>> >> Caolan has had packages building for quite a while now, and if the damn
>>> >> thing doesn't keep failing to build on PPC, it should be out in Rawhide
>>> >> by early next week.  Last I heard, the release for OOo 2.0 was going to
>>> >> be "April/May", and since FC4 is slated for a June release, chances of
>>> >> OOo 2.0 Final being in FC4 a looking good.
>>> >
>>> >After an astonishing 20 hour build 1.9.81 should materialize soon. There
>>> >are some known non-specific to fedora bugs so searching the
>>> >qa.openoffice.org for your symptoms is likely to explain most problems,
>>> >but feel free to log issues for unreported upstream issues against
>>> >openoffice.org's fedora bugzilla component.
>>> >
>>> >If gcj/java guys want to poke at the java stuff that builds the
>>> >helpcontent2 directory to speed up the slowest build part, that would be
>>> >appreciated :-)
>>> >
>>> 
>>> Are you building bytecode or native objects?  The rawhide
>>> java-1.4.2-gcj-compat-devel has a fix to make ecj run natively which
>>> speeds up bytecode compilation 2-3 times.  We're planning on
>>> natively-compiling rawhide ant -- that will likely further reduce build
>>> times.
>>
>>That would be 'gij' at this time.
>>
>>/usr/bin/gij -Dgnu.gcj.runtime.VMClassLoader.library_control=never -
>>Djava.library.path=/usr/src/build/532736-
>>i386/BUILD/SRC680_m81/solver/680/unxlngi6.pro/lib -
>>cp .:../../unxlngi6.pro/class::/usr/src/build/532736-
>>i386/BUILD/SRC680_m81/solver/680/unxlngi6.pro/bin/jaxp.jar:/usr/src/build/532736-i386/BUILD/SRC680_m81/solver/680/unxlngi6.pro/bin/parser.jar:/usr/src/build/532736-i386/BUILD/SRC680_m81/solver/680/unxlngi6.pro/bin/xt.jar:/usr/src/build/532736-i386/BUILD/SRC680_m81/solver/680/unxlngi6.pro/bin/unoil.jar:/usr/src/build/532736-i386/BUILD/SRC680_m81/solver/680/unxlngi6.pro/bin/ridl.jar:/usr/src/build/532736-i386/BUILD/SRC680_m81/solver/680/unxlngi6.pro/bin/jurt.jar:/usr/src/build/532736-i386/BUILD/SRC680_m81/solver/680/unxlngi6.pro/bin/jut.jar:/usr/src/build/532736-i386/BUILD/SRC680_m81/solver/680/unxlngi6.pro/bin/xmlsearch.jar:/usr/src/build/532736-i386/BUILD/SRC680_m81/solver/680/unxlngi6.pro/bin/db.jar:/usr/src/build/532736-i386/BUILD/SRC680_m81/solver/680/unxlngi6.pro/bin/xmlsearch.jar:/usr/src/build/532736-i386/BUILD/SRC680_m81/solver/680/unxlngi6.pro/bin/xmlhelp.jar com.sun.star.help.HelpLinker @/tmp/mkfRPrRw
>>
>>As an example.  This particular step of the process is done quite a few
>>times, and even just this one invocation of gij took 5 minutes in my
>>observation last night on bugs.build (900Mhz Xeon).  Caolan has more
>>details, he was going to look at compiling a native binary of HelpLinker
>>soon.
>>
>
>Yeah, compile the HelpLinker jar file to a specially-named shared object
>(e.g. lib-com-sun-star-help.so), then make sure LD_LIBRARY_PATH points
>the the .so's location.  Then you can run the same command and gij will
>find and load the .so and run com.sun.star.help.HelpLinker natively.
>

Actually, this won't work with library_control=never so you'd better do
it the way Tromey recommended.

Tom