|
Bugzilla – Full Text Bug Listing |
| Summary: | gcc4, java and binary modules (problems to build OpenOffice.org) | ||
|---|---|---|---|
| Product: | [openSUSE] SUSE LINUX 10.0 | Reporter: | Petr Mladek <pmladek> |
| Component: | Basesystem | Assignee: | Michael Matz <matz> |
| Status: | RESOLVED FIXED | QA Contact: | E-mail List <qa-bugs> |
| Severity: | Normal | ||
| Priority: | P5 - None | CC: | aj, pmladek |
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Hardware: | All | ||
| OS: | SUSE Other | ||
| Whiteboard: | |||
| Found By: | Development | Services Priority: | |
| Business Priority: | Blocker: | --- | |
| Marketing QA Status: | --- | IT Deployment: | --- |
| Attachments: | strace.log that shows the problem | ||
|
Description
Petr Mladek
2005-04-14 15:45:48 UTC
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. |