Re: plans with libmerged

On Wed, 2013-04-10 at 09:04 +0200, Stephan Bergmann wrote:
> An alternative (for other platforms too) might be to have the various 
> URE interface libraries (sal etc.) be shallow wrappers that link against 
> libmerged and just re-export their part (depending on how elegantly 
> different architectures allow such re-exporting).

        Right - that's a good plan indeed; though I suspect that for Mac+Linux
the symlink idea is rather simpler practically [ not certain that it's
easy to safely re-export the same symbol you're implementing under an
ELF model ].

> This is one place where the split into URE and LO directories may become 
> a nuisance.  (It was rather harmless for other scenarios, even helps 
> keeping the URE interface well-defined for extensions, so there's never 
> been much incentive in undoing that.)

        I assume there is ABI impact in unfolding the URE hierarchy out
of /ure/lib etc. if so we'd need to keep it as-is.

Tue, 2013-04-09 at 17:29 -0400, Peter Foley wrote:
> I was under the impression that the goal of libmerged was to
> eventually include most, if not all of the various libraries in
> libreoffice. If this is incorrect, I'd like to know what libraries
> should and should not be in libmerged?

        Well ... times change of course; initially the plan was to accelerate
single-platform startup by doing one big I/O to load a single library
from disk, and to re-order that cleverly :-)

        Then the mobile targets arrived; so - it is indeed useful to try to
work out why libmerged is failing when we have everything linked into
one piece - because that is the same as the mobile case. So your
investigation work is appreciated there - it's surely easier to debug on
a PC than under Android :-)

        You might also find that in fact it is faster to have everything in one
blob - ie. the whole suite there, and that LTO and PGO will give a
better result for that; certainly for some use-cases such as LibreOffice
on-line having a single very large, fully internally resolved library
would be rather more memory efficient for lots of connecting clients I
suspect, faster to get running etc. So it is by no means wasted work -
are you interested in creating an mode for --enable-merge-libs=all (or
sim.) that does that ?

        And did you get any further with the debugging ?

        HTH,

                Michael.

-- 
michael.meeks@suse.com  <><, Pseudo Engineer, itinerant idiot