As it turns out, OpenOffice use of an internal copy of libicu requires us all to rebuild it, as libicu was found vulnerable. I think this is a good case in point for not using internal libraries.
Now, looking at it, I’ve seen that it still uses an internal copy of STLport. I haven’t found a copy of STLport itself in portage, but I didn’t look around much; still I’d think it would be a good idea NOT to use the internal copy if possible. Also, for what I read on the configure.in file in OpenOffice, it’s possible to use GCC’s libstdc++ with GCC 3.4 and later, at the expense of breaking ABI. Not sure what uses OpenOffice’s ABI, but I sincerely wouldn’t care. I don’t need any add-on, I just need OpenOffice from time to time, and I want it to be fast and use as less memory as possible; using libstdc++ would save me from loading another STL copy (I already have it loaded for KDE).
Funnily enough, my previous post only counts two bugs closed, one is the OpenOffice one, because of a security issue, the other was gdb’s readline which I fixed myself. I admit it’s not really a good count.
As it turns out, Gentoo developers don’t seem to have enough time to handle everything themselves; I’ll be filing upstream bugs for those things at this point, to see if that helps.
Please leave us with the bug # so we can CC ourselves.
> Not sure what uses OpenOffice’s ABIOpenoffice extensions (well, the ones that are not written in python) do:http://extensions.services….> but I sincerely wouldn’t care.Many users would. If you add a USE flag for breaking openoffice ABI, please please please do NOT make it a default.
Diego, perhaps take a look at this thread in unsupported software:http://forums.gentoo.org/vi…Ive only glanced at it but it appears that Geki is back packaging new OO releases and may have a version of OO that uses GCC’s libstdc++Maybe with a bit of work some of these changes can get into portage?
Suka is trying quite hard to go withexternal libraries. Somewhere alongOOo-2.1 or 2.2 external icu and STLportwere used. Unfortunately that went backward in OOo-2.3 because of buildingproblems. To say OOo is fragile/fussy isan understatement, _it is huge too_ which doesn’t help.
I’m the jok from the page Nick linked.The Geki packages are just that; using as much of the system libraries as possible. That is, at least stlport (from gcc), hunspell, cairo, jfreeport, mozilla (from xulrunner|firefox|seamonkey|mozilla), stdlibs, zlib, python, icu, freetype, libxml, expat, db, hsqldb, xalan, xerces, libxslt, curl and neon are linked to the system installed versions, when available, instead of providing an internal implementation. Hope it works, I’m still building 2.4.0_pre5 😉
what is the compilation speed of this openoffice version? it is something that a normal user could think about it?! the old oo releases weren’t worth all the compile time they needed.
i think the problem is most of us have is not free time, it’s we have no idea what you’re talking about. and when we do, we have no idea how to fix these things. your blog posts have been informative, and do help, but they’re on a technical level generally over the heads of the majority of our maintainers. these things may seem simple to some, but we need documentation or pointers to existing documentation to understand the problems at hand and the steps needed to repair them or a bug report like https://bugs.gentoo.org/207025 is gibberish.
STLport still exists in portage:eix -s STLport* dev-libs/STLport Available versions: 5.1.2 ~5.1.3 {boost} Homepage: http://stlport.sourceforge…. Description: C++ STL library
> what is the compilation speed of this openoffice version?The current 2.3 takes about 6 hours on an Athlong64 3200+ (single core), 1 Gig RAM (/var/tmp/portage is a disk). It is thus the single longest-compiling package I have installed, by a fair margin. (Since KDE went modular, nothing else takes so long. Even Firefox only needs 30-40 minutes.)I wouldn’t expect external libraries to speed up compilation very much. 40 minutes, perhaps. Mozilla is already external in the current ebuild, and the other libraries don’t take that long.
stlport might as well take an hour, C++ building is quite slow.