| Summary: | app-office/openoffice-bin installs its own libstdc++ (was: cannot startup previous instance) | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Robert Bradbury <robert.bradbury> |
| Component: | Current packages | Assignee: | Gentoo Office Team <office> |
| Status: | RESOLVED DUPLICATE | ||
| Severity: | normal | CC: | admwiggin, chris, nando.sm |
| Priority: | High | ||
| Version: | unspecified | ||
| Hardware: | x86 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Bug Depends on: | |||
| Bug Blocks: | 249051 | ||
| Attachments: |
strace attempting to start oowriter
Gdb trace of all threads during SEGFAULT Strace -f of oowriter which segfaults |
||
|
Description
Robert Bradbury
2008-07-03 12:11:49 UTC
Created attachment 159408 [details]
strace attempting to start oowriter
Here is an strace attempting to start oowriter 2.4.1 leading to a segmentation fault.
Created attachment 159409 [details]
Gdb trace of all threads during SEGFAULT
This is a trace from gdb of all of the threads when soffice.bin has segfaulted. Sorry, no symbols yet (there seems to be an incompatibility between the openoffice libraries and a somewhat older libc.so I have which has debug symbols.
Created attachment 159412 [details]
Strace -f of oowriter which segfaults
Compressed strace -f of oowriter (soffice.bin) which crashes. At the point that it starts opening the .crash_report_* files and tries to get to libgnomebreakpad it has probably gone south.
In contrast to the 4.9MB size of the bad trace. The good oowriter startup complete trace only has a size of 559879 bytes. Though a side-by-side comparison seems to suggest there are some timing differences in how long it takes to get files open.
You built libraries on your system with a more recent version of GCC than the GCC (libstdc++) you're running atm. This doesn't work, since libstdc++ is not held downwards compatible. improper resolution, reopening System breakpad library is built with a newer GCC than OOo's own libstdc++, so linking fails. Unless OOo's libstdc++ is modified, it probably should use the system libstdc++. (In reply to comment #6) > System breakpad library is built with a newer GCC than OOo's own libstdc++, so > linking fails. Unless OOo's libstdc++ is modified, it probably should use the > system libstdc++. > Soooooooo. The big question is: How to do that with the binary package from upstream? I have recompiled openoffice from source and that does seem to work properly. I think if you are going to push the binary package you may need to do it (a) without an interface to bug-buddy and checking to see if the user has a compatible libstdc++ already installed and to use that instead of any distributed version (or have openoffice-bin depend upon a specific binary libstdc++ which is part of the portage system. (In reply to comment #7) > Soooooooo. The big question is: How to do that with the binary package from > upstream? By simply not installing OOo's libstdc++. The linker will fall back to the next best visible, which is the system one on regular systems. This should do it, unless a) the libstdc++ that comes with OOo includes some nasty hacks making it incompatible b) upstream GCC folks breaks ABI again c) you do belong to the tiny minority using some hardened or other GCC 3.x desktop system As a side-effect, doing so should reduce cold application startup time and reduces memory consumtion a bit. So, what's the fix for the average layperson? Is the maintainer of the openoffice-bin package (or anyone, for that matter) working on a solution? Anyone know a workaround that doesn't involve compiling the absolutely massive openoffice package on our systems? You might try preventing the use of Bug Buddy (breakpad?) entirely (I haven't tested to see if this works). That would involve setting during your system login (or in the oowriter, oocalc, etc. shell scripts in /usr/bin) the following: export GNOME_DISABLE_CRASH_DIALOG=1 I normally run Firefox this way so it will produce core dumps but I'm not sure that it will work around the openoffice problems however. I simply punted by setting things up to compile from source. It isn't too bad. Version 3.1.1 required something like 12 hours on a relatively unloaded 2.8 GHz Pentium IV Prescott (1 core). It will require a fair amount of disk space -- something like 3-4 GB for the portage working build directories (PORTAGE_TMPDIR) and perhaps a relatively large compiler cache (CCACHE_DIR) whose size can be constrained to a few hundred MB I think. It helps if you are spreading this across multiple drives and have a far amount of memory (1+ GB) to keep things in the memory cache. It will produce a 5-11 MB output listing (presumably depending on USE options). One needs about 280 MB for the executable install in /usr/lib/openoffice. The alternate of downgrading your system to run with the same version of glibc libraries that is used by openoffice-bin is, I would imagine, very dicey. Alternatively, Gentoo could release openoffice-bin matched to various gcc and glibc releases but I doubt this is going to happen. Thanks for your reply! I actually found that I had an older openoffice binary open on another workspace and had forgotten about it. After the upgrade, I couldn't open any more openoffice windows until I'd closed that one, and that bug-buddy error message is all I was getting to clue me in on the issue, even though it wasn't actually related (and I still get the error even though openoffice starts and runs just fine). Hopefully this might help someone else at some later date if they run into the same issue and are led to this bug report. :) *** Bug 276916 has been marked as a duplicate of this bug. *** This bug also affects scim input manager, which renders me unable to write in japanese (and many more languages) inside openoffice-bin. Is there any workaround apart from building the source? This is the output error: (soffice:6564): Gtk-WARNING **: /usr/lib/openoffice/program/../basis-link/ure-link/lib/libstdc++.so.6: version `GLIBCXX_3.4.9' not found (required by /usr/lib/gtk-2.0/immodules/im-scim.so) (soffice:6564): Gtk-WARNING **: Loading IM context type 'scim' failed This bug is still present in the lo-b-3.4 and we really need to redo the -bin package. Duping it against the "overhaul masterbug" *** This bug has been marked as a duplicate of bug 361695 *** |
