On Mon, 6 Feb 2012, Petr Mladek wrote:
Stephan Bergmann píše v Pá 03. 02. 2012 v 22:10 +0100:
Petr, the best approach might be to build the "official" Linux LO
installation sets with explicit --with-system-stdlibs, so that the
installation sets do not bring along their own libgcc_s.so.1 and
libstdc++.so.6. If the installation sets are built on a sufficiently
old baseline system, it should be a pretty safe bet that each box on
which they are installed bring along sufficiently new versions of those
libs as part of the system.
Hmm, I am a bit scared to do such change at this stage. I am not sure if
the stdlibs are 100% backward compatible, it there are not disabled some
features on some crazy systems. Note that we already have 3.5.0-rc3
which is supposed to be final.
One possibility would be to try system stdlibs in daily builds. Ask
people for testing. If we do not get any complains, we could try this
with 3.5.1`bug fix release that should get release 4 weeks from now.
People could remove the libs in 3.5.0 as a workaround.
How does that sound? Maybe, we should discuss this on TSC.
My preference is to have this fixed in 3.5.0, obviously, but I have no
idea what the impact could be. If it won't be fixed in 3.5.0, I'd prefer
if the release notes mention the problem with the workaround.
But the issue deserves a bugzilla entry, so here it is:
https://bugs.freedesktop.org/show_bug.cgi?id=45696
I took the liberty to add it to the "Most annoying bugs" list and the
Release Notes.
Thanks for your help !
--
-- dag wieers, d...@wieers.com, http://dag.wieers.com/
-- dagit linux solutions, i...@dagit.net, http://dagit.net/
[Any errors in spelling, tact or fact are transmission errors]
_______________________________________________
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
