Bugzilla – Bug 77967
gcc4, java and binary modules (problems to build OpenOffice.org)
Last modified: 2007-06-05 12:33:36 UTC
OpenOffice.org uses a java interface to libdb (BerkleyDB). OOo uses an internal version of libdb and builds the necessary libdb_java-X.Y.so (binary part) and db.jar (java part) from its own sources. The build crashes when it calls java and the java tries to use the libdb_java-X.Y.so. It is interesting that java is able to load the module. It crashes later when it tries to use a function provided by this module. I expect that the problem is that the Java SDK is built using and older gcc and the module is built with gcc4 now, so there is a small chance that they are compatible. Debians are hacking OOo to be usable with gcj-4.0, so there is a big chance that we could use gcj as well. I am going to try it now. Thought, we should try to solve this problem some way because we should not force users to use OOo with gcj. In addition, I expect that there would be more problems with java and binary plugins, for example with the mozilla plugin, ...
Created attachment 34497 [details] strace.log that shows the problem The important part is: --- cut --- 13292 15:44:11.085890 write(1, "[Loaded com.sleepycat.db.db_java]\n", 34) = 34 13292 15:44:11.087306 gettimeofday({1113493451, 87338}, NULL) = 0 13292 15:44:11.087759 write(1, "[Dynamic-linking native method com.sleepycat.db.db_javaJNI.getDbEnv0 ... JNI]\n", 78) = 78 13292 15:44:11.089239 write(1, "[Dynamic-linking native method com.sleepycat.db.db_javaJNI.initDbEnvRef0 ... JNI]\n", 82) = 82 13292 15:44:11.090553 --- SIGSEGV (Segmentation fault) @ 0 (0) --- --- cut --- Note that you must start java with -verbose and -verbose:jni options to get more useful strace.
The actual package, where the build with gcc4 is enabled, some problems are already solved but the build still crashes as described above, can be found in ~pmladek/Export/OOo/STABLE.gcc4.problem/OpenOffice_org
Sonja, this might be interesting for you as well. Michael, something for you.
I guess this is still the case? Were you able to perhaps reduce this somewhat?
How do you mean to reduce it? I am afraid that cannot work by definition. Do you think that a module compiled by gcc-4.0 can be load by an application compiled by ggc-3.3? If you expect only minor problems and the module can be fixed, I could try to extract it from OOo to help you fixing it. if it cannot work by definition, it is not necessary, IMHO.
Well, we don't know yet for sure, if it's really the difference between gcc 3 and gcc 4 which makes this not work, or do we? Is the libdb_java-X.Y.so C++? (Sorry, I don't know much about OOo). Could it work by linking statically against libstdc++?
OK, I'll try to get some more info and reduce the necessary steps to test the problems.
It is strange. If I compile our system "db" with the java support and use it instead of the OOo internal "db", than it seems to work. I must investigate it more but it looks promising.
Please note that we can't compile our db package with java support unless we manage to do this with gcj (not natively, just as a replacement for javac), because db is one of the packages needed to bootstrap the distribution. The autobuild team understandably doesn't want a dependency on a proprietary java in that.
Yeah, but it at least is a nice hint for Petr to start from. If everything breaks he can simply replace the copy of db in OOo with a copy of our system db ;)
Finally, it was enough to build the OOo internal berkeleydb with the same CFLAGS as those used to build the system one. Even the RPM_OPT_FLAGS were not passed to build the OOo internal version. And the important option -fno-strict-aliasing was not used as well. I have successfuly rebuild the entire OOo with the java support enabled. So, I think that we can close this bug for now. Yes, it would be better to build OOo against the system berkeley db and it would be necessary to build our system db with the java support but it is another bug. Also I must discuss it with some more developers if it is save to use the system db for OOo. I heard that db was not backward compatible between versions in the past. In additon, OOo has not been ported for db-4.3 yet. (I ported only the part necessary to test this problem.)
Very cool. Thanks for the efforts.