Bugzilla – Bug 144113
openoffice_org takes ages to start
Last modified: 2006-03-03 10:10:59 UTC
openoffice_org takes ages to start on my AMD64 machine. Most of the time seems to be spend in javaldx, which 20 or more times calls "/usr/bin/gij -classpath /usr/lib/ooo-2.0/program JREProperties" which takes several seconds on every invocation.
Hmm, I must test it. In the past, the Sun Java was installed by default. Maybe, it was faster than gij. Just to be sure. Michael, could this be related to your spead up work? ;-)
nah - this is unrelated to my speedup stuff; I'm assuming you don't have Sun Java installed - which is one of the causes of the problem. Petr - have we tested this with 64bit gij stuff ? Jan - any ideas ?
Only gcc-java is installed.
Two things are necessary: 1. Add libgcj.so.7 to the list of known java plugins. It is already fixed as the bug #144833. The fix should be available on 10.1-beta3/NLD10-beta3. 2. Install libgcj-32bit.rpm on x86_64. The solution: a) I'll add libgcj.so.7 to the requites of the OOo package as a temporary hack to make sure that it will work on next beta. b) It would be great to add a common provide to our 32-packages including a JRE (java-1_4_2-<vendor>, libgcj). It would be great because OOo is able to use any JRE, so there should not be a hard dependency on gcj. c) We should add libgcj-32bit to the default OFFICE selection on x86_64. Tasks: pmladek: I will add a temporary hack mentioned in 2a), so it will work on next beta. dbornkessel: Daniel, could you please think about an useful provide that could be added to the 32-bit JRE packages? See 2b) for more details. It would be great if it is compatible with the JPackage rules. sndirsch: Stefan, could you please add libgcj-32bit to the OFFICE selection as mentioned in 2c)?
Sorry, I didn't really understand what you meant with 2b. Right now, the Java packages all provide Provides: jre-%{javaver}-%{origin} = %{version}-%{release} Provides: jre-%{origin} = %{version}-%{release} Provides: jre-%{javaver}, java-%{javaver}, jre = %{javaver} Provides: java-%{origin} = %{version}-%{release} Provides: java = %{javaver} This is how jpackage does it as well. For gcj, the package java-1_4_2-gcj-compat provides these as well, so there shouldn't be a problem. %{origin} is the vendor ... so you have provides with and without vendor information. Or did I misunderstand something? Greetings, Daniel
Ah, I forgot one problem: OOo calls gij to check if there is necessary an extra LD_LIBRARY_PATH. No extra paths are necessary for our gij, so the 64-bit gij is enough and we need not add gij32 binary to the libgcj-32bit package. We should make sure that the gij binary or another JRE is installed, though. We should add a common provide to the libgcj package and other JRE's. Note that this is another provide than the one mentioned in the comment #4, point 2b). This is about the java/gij binary. The other provide was about the libgcj library. Daniel, do you think that we could add the string "jre" to provides of the package libgcj? Or do we need an extra name? Stefan, could you plese add libgcj to the OFFICE sellection as well? I'll add libgcj to the requires of OOo as a temporary hack to make sure that also this works on next beta.
Is java-1_4_2-gcj-compat available on openSUSE? In fact, it seems that libgcj and libgcj-32bit is enough for OOo. At least, oobase works even without java-1_4_2-gcj-compat. So, it seems that we need two new common provides. One will signalize that the package provide java/gij binary. One will signalize that the package provide 32-bit version of libgcj or it's Sun/IBM/... alternative. Does this makes sense? I know, it sounds strange but...
If I understand correctly, we already have these provides in our Java packages as well as in the java-1_4_2-gcj-compat package. This is actually one of the reasons for java-1_4_2-gcj-compat package (to provide the same as the normal Java packages do). java-1_4_2-gcj-compat requires of course every gcj stuff that is necessary in order to have a compatible GNU Java on the machine. java-1_4_2-gcj-compat provides: java = 1.4.2 java-1.4.2 java-1_4_2-gcj-compat = 1.4.2.0-10 java-gcj = 1.4.2.0-10 jndi jre = 1.4.2 jre-1.4.2 jre-1.4.2-gcj = 1.4.2.0-10 jre-gcj = 1.4.2.0-10 BEA Java (as an example) provides: jaas = 1.4.2.08 java = 1.4.2 java-1.4.2 java-1_4_2-bea = 1.4.2.08-5 java-bea = 1.4.2.08-5 javaws = 1.4.2 jce = 1.4.2.08 jdbc-stdext = 1.4.2.08 jdbc-stdext = 3.0 jndi = 1.4.2.08 jndi-cos = 1.4.2.08 jndi-dns = 1.4.2.08 jndi-ldap = 1.4.2.08 jndi-rmi = 1.4.2.08 jre = 1.4.2 jre-1.4.2 jre-1.4.2-bea = 1.4.2.08-5 jre-bea = 1.4.2.08-5 jre1.1.x jre1.2.x jre1.3.x jre1.4.x So, with jre / java you have your java/gij binary and with java-bea and java-gcj you have your vendor information. This is what you were asking for, right? If so, it's already there and you could change your requires accordingly. Regards, Daniel
Ah, I am sorry. I though that java-1_4_2-gcj-compat is a commercial package. It solves the problem mentioned in the comment #6. It does not solve the 2nd problem from the comment #4. It would be solvable by a java-1_4_2-gcj-compat-32bit package. Though, it is not enough. We need to have a common provide for the normal 32-bit java-1_4_2-gcj-compat (i586) package and the 64-bit java-1_4_2-gcj-compat-32bit (x86_64) package. But this provide must not be included in the 64-bit java-1_4_2-gcj-compat (x86_64) package. We could create java-1_4_2-gcj-compat-32bit on x86_64 and "java-1_4_2-gcj-compat-32bit" to the provides of the regular java-1_4_2-gcj-compat package in i586. So, I could require java-1_4_2-gcj-compat-32bit in my 32-bit OOo package. Note that we use this one OOo package on both i586 and x86_64. It would also need to add the gij32 binary to libgcj-32bit. What do you think?
Please, forget the last comment #9. It seems that I am too tired to think about it now. Well, it is right that java-1_4_2-gcj-compat package solves the problem mentioned in the comment #6. But it is not right that I would want to add java-1_4_2-gcj-compat-32bit to requires. I do not want to require gcj. I want to require any 32-bit JRE. The current java provides does not solve if the JRE is 32-bit or 64-bit. So, the java-1_4_2-gcj-compat-32bit package is solution but we need another 32-bit specific provides that will be common for all JREs. I hope that the request is correct now.
Ah, ok ... I didn't really get that one before. I can add the following to the spec file if you like -- no problem: %ifarch %ix86 ppc s390 %define bits 32 %endif %ifarch x86_64 ia64 s390x %define bits 64 %endif Provides: jre-%{javaver}-%{origin}-%{bits} = %{version}-%{release} Provides: jre-%{javaver}-%{origin}-%{bits} = %{version}-%{release} Provides: jre-%{origin}-%{bits} = %{version}-%{release} Provides: jre-%{javaver}-%{bits}, java-%{javaver}-%{bits}, jre-%{bits} = %{javaver} Provides: java-%{origin}-%{bits} = %{version}-%{release} Provides: java-%{bits} = %{javaver} Provides: jndi-%{bits}, jdbc-stdext-%{bits}
Looks good. Do it, please. Will it be Novell specific or is there a chance to put this provides to the JPackage project?
I will propose it on JPackage -- shouldn't be a problem.
Submitted package with discussed adjustments and proposed to the JPackage people to change their spec accordingly. Greetings, Daniel
I hope, I have sorted the things over night and have the right solution now. The actual one is still not enough. We are on a good way though. Well, we have 32-bit specific provides. I would need a package that would include this 32-bit provides for gij on x86_64. So, the package java-1_4_2-gcj-compat-32bit was a good idea, finally. My proposal is the following: 1. Michal could add the binaries gcj32 and grmiregistry32 to the package libgcj-32bit. 2. Then Daniel could create the package java-1_4_2-gcj-compat-32bit for 64-bit architectures. It should provide the 32-bit jre, should require libgcj-32bit and should use the 32-bit binaries. BTW: I wonder why java-1_4_2-gcj-compat requires the package gcc-java. It think gcc-java should be required only by java-1_4_2-gcj-compat-devel. 3. I will fix OOo, so it will also check for the binary gij32. Then the binary /usr/lib/gij32 would be enough and OOo will not need to require the 64-bit gij. I have already tested this 3rd step. It works. So, it is a way to go from the OOo point of view. IMHO, this looks like a clean solution. Do you see any problems with it?
I fear this all isn't that easy. The 32bit libgcj on x86-64 comes directly from the i586 RPM, which gets repackaged a bit. That process doesn't fiddle with the binaries at all. I.e. on the x86-64 distribution there is no 32bit gij executable. Including mls for advice, how to best create that magically.
You can add provides in the mkbaselibs configuration.
Michael (mls), is it also possible to rename/add the 32-bit binaries gij/grmiregistry as gij32/grmiregistry32 into the 32bit compat package?
Yes, simple renames are also possible.
mls: So, where is all this documented? What's and where's the mkbaselibs configuration, how do I have to change it, and whom do I need to send these changes (if that's necessary).
Can you please reassign the bug to me as soon as you know if or what changes have to be done to the java-1_4_2-gcj-compat package? Thanks, Daniel
It seems that we are waiting on input from Michael (mls) about how to modify the 32bit compat packages, configuration, ... The question is in the comment #20. Notet that the changes, we want to do, are described in the comment #15.
Michael (mls), could you help us to modify the 32bit compat packages?
What are you talking about, isn't this already working?
No, it works only because of a hack. There is hardcoded a dependency on libgcj.so.7 and /usr/bin/gij. It is bad because: 1. OOo is able to work with any jre, so it should not always require gij. 2. It requires both packages libgcj and libgcj-32bit on x86_64 now. libgcj-32bit would be enough if it includes gcj32 and grmiregistry32 binaries. All problems can be fixed by the changes proposed in the comment #15. Michael (matz) and Daniel would need help with the 1. and 2. point.
Please look at the packages in STABLE.
Ah, I see. I am sorry that I did not double check it. However, I hoped that somebody would update this bug report when it is done. Hmm, the package java-1_4_2-gcj-compat-32bit is quite broken: 1. It should include the various provides compatible with other JREs, see the package java-1_4_2-gcj-compat 2. /usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/jre/bin/rmiregistry should call /usr/bin/grmiregistry32 instead of usr/bin/grmiregistry 3. /usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/jre/bin/java should call gij32 instead of gij. 4. /usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/jre/bin/java looks for /usr/share/java/libgcj-4.1.0.jar. So, the package either has to require libgcj or we must add this jar into the libgcj-32bit as well. 5. /usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/jre/lib/rt.jar is an empty file. IMHO, it should be a symlink to the libgcj-4.1.0.jar. This is broken even in the java-1_4_2-gcj-compat package. 6. /usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/jre/bin/java calls "gcj --version" on two locations. Is it really necessary? Do we really need gcj? Note that only the points 1. and 4. are required for OOo. OOo uses neither the java nor the grmiregistry wrapper. Who could fix it?
Number 5. looks good ... will correct that in the package. Who takes care of this java-1_4_2-gcj-compat-32bit package? I didn't now it was created. For now I will take care of the empty rt.jar pointing to libgcj-4.1.0.jar Cheers, Daniel
Another thing: As there is now a java-1_4_2-gcj-compat-32bit package, should I remove the jre-1.4.2-gcj-32 = 1.4.2.0-11 jre-gcj-32 = 1.4.2.0-11 jre-1.4.2-32 java-1.4.2-32 jre-32 = 1.4.2 java-gcj-32 = 1.4.2.0-11 java-32 = 1.4.2 jndi-32 jdbc-stdext-32 or *-64 respectivly Provides?
Every change in java-1_4_2-gcj-compat has to be done by the maintainer of it, which is Johannes, hence assigning to him, I don't know why nobody did this until now. I have nothing to do with that package. I can only help with the libgcj package, in particular about point 4. Putting the jar file into libgcj-32bit is not possible, because then you can't install both, but libgcj-32bit can require libgcj, which actually even makes sense.
Ah, I expected that all the java stuff was maintained by Daniel :-( Daniel, please do not remove the *-32 provides. OOo requires any 32-bit jre. The target of this operation is that the package OpenOffice_org will require jre-32 and everything will work then.
Johanes, the bug is already quite long. Here is a short summary for you. The primary problem is that OOo is 32-bit application and requires any 32-bit JRE. Therefore we needed to create java-1_4_2-gcj-compat-32bit. The remaining problems with this package are described in the comment #27. I hope, you can help here.
I don't know how a ...-32bit package is actually made. All I know is that in PDB the check-box "Has baselibs (java-1_4_2-gcj-compat-32bit and java-1_4_2-gcj-compat-64bit)" is set to "Yes" for the package java-1_4_2-gcj-compat and then some magic creates java-1_4_2-gcj-compat-32bit. I don't know how I can influence this magic so that the issues in comment #27 can be fixed. Can someone help me or at least tell me whom to ask?
mls of course, as written in this very bugreport. But to give you a head start: The baselibs itself are all configured in /work/abuild/lib/abuild/init_buildsystem/glibc/lib/baselibs.conf (together with baselibs_global.conf there). It already has an entry for the java-1_4_2-gcj-compat, which currently looks like so: java-1_4_2-gcj-compat +.*/(java|rmiregistry|rt\.jar)$ provides "jre-<extension>" requires "libgcj-<targettype>" You can also but a file named "baselibs.conf" into the sources of your package, which overrides the above baselibs.conf file (I don't know if that ever was tested, though). The expressiveness of baselibs.conf is quite large, but the syntax fairly ad-hoc. If you don't find anything looking like what you need in the above file (which contains many examples) you have to ask mls directly. Changes to the above file have to be done by mls. Ohh, and the PDB checkbox actually has no significance regarding building of -32bit or -64bit packages. I don't know if that checkbox has any significance at all anymore, or even if it ever had.
Many thanks matz! I didn't get this information from mls' short comments (and there is no answer to comment #20). The long discussion confuses me a bit. I don't know what exaclty is needed only for OOo and what of this is already done. Therefore a summary according to what I understand at the moment: According to comment #27 only items 1 and 4 are needed for OOo. Regarding comment #27 item 1: According to comment #31 "OpenOffice_org will require jre-32 and everything will work then." According to comment #34 java-1_4_2-gcj-compat-32bit provides jre-32 and java-1_4_2-gcj-compat-32bit in STABLE really does it: $ rpm -qp --provides \ /work/CDs/all/full-x86_64/suse/x86_64/java-1_4_2-gcj-compat-32bit.rpm jre-32 Therefore I assume comment #27 item 1 is fixed. Regarding comment #27 item 4: As far as I understand java-1_4_2-gcj-compat-32bit "has to require libgcj". I assume you meant that it has to require libgcj-32bit which is provided by libgcj-32bit. According to comment #34 java-1_4_2-gcj-compat-32bit requires libgcj-32bit and java-1_4_2-gcj-compat-32bit in STABLE really does it: $ rpm -qp --requires \ /work/CDs/all/full-x86_64/suse/x86_64/java-1_4_2-gcj-compat-32bit.rpm libgcj-32bit Therefore I assume comment #27 item 4 is fixed. Summary: I assume what is needed for OOo is fixed. Is this correct?
Petr, is java-1_4_2-gcj-compat-32bit in STABLE o.k. for OOo on x86_64?
Unfortunately, comment #27 item 4 is still not fixed because the package libgcj-32bit does not include the file /usr/share/java/libgcj-4.1.0.jar. It cannot be there because it would conflict with the package libgcj then. It seems that the best solution is that libgcj-32bit will requite libgcj, see the comment #30. Michael (mls), could you please fix this last problem?
Done, extra requires will be there after the next build. Can anybody else check afterwards if this bug can be closed?
The new dependencies look good. The current solution looks sufficient for OOo. => I'll close this bug as FIXED. Thanks us all for patience :-)