Re: plans with libmerged

On 04/09/2013 07:24 PM, Michael Meeks wrote:
> On Tue, 2013-04-09 at 15:25 +0200, Matúš Kukan wrote:
> > So - it should now work in master.
> > One problem is using ure libraries in libmerged.
> > javaldx had problems to find libmerged because it's not in ure.
>
>         Right; interesting.
>
> > I plan to merge some urelibs and see how it works but that can't be
> > used in regular builds I am afraid because of compatibility issues.
> > And maybe some more regular libraries.
>
>         So - it is probable that the GNU linker for Linux at least, tolerates
> symlinks very nicely. So, I -suspect- that as long as you create
> compatibility symlinks:
>
>         ln -s program/libmerged.so ure/lib/libuno_sal.so.3
>
>         etc. then I imagine the run-time linker will work out they're all the
> same (massive) library and link it just once; while ensuring that other
> things linked to the original URE (like extensions) carry on working.
> But that needs careful testing obviously.
>
>         Of course, that's a Linux-only hack, but ... it might work nicely - I'd
> be interested to know :-) It seems to me that the biggest benefits of
> LTO would come from in-lining lots of sal/ stuff - string methods etc.

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).

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.)

Stephan