The distribution of LibreOffice for 3.5.0RC1 contains it's own elibstdc++.so.6 DSO, and things are set up for that to be used ahead of the system libstdc++.so.6. However - this version is not the latest, and so libraries which are used from the underlying system install (as the LO install does not include them) can fail to load because of missing symbol version dependencies. Hence this: [parent]: /opt/libreoffice3.5/program/soffice /opt/libreoffice3.5/program/../ure-link/lib/libstdc++.so.6: version `GLIBCXX_3.4.11' not found (required by /usr/lib64/libproxy.so.1) Failed to load module: /usr/lib64/gio/modules/libgiolibproxy.so The supplied libstdc++.so.6 only goes up to GLIBCXX_3.4.9 Since I don't actually use a proxy this may not affect me directly (I was only running 3.4.5RC1 to check out another bug) but it may well affect others, and there may well be other library dependencies which would affect me. Similar things have been reported before (see, e.g. Bug32852), but that report has been closed a No a Bug. However, I reckon that if I can't load libraries which are needed in certain circumstances then that *is* a bug.
we are currently discussing whether it would not be better to build the <http://www.libreoffice.org/download/> installation sets --without-system-stdlibs (so they do not bring along their own versions of libstdc++.so.6 and libgcc_s.so.1) in the scope of issue 45696
fixed by not shipping the old stdlibs. *** This bug has been marked as a duplicate of bug 46246 ***