Re: [Libreoffice] [GSoC] library merging

On Fri, 2011-06-24 at 16:08 +0100, Caolán McNamara wrote:
> Hmm, yeah, the passive uno registration stuff as it stood didn't really
> help a lot here does it. That just removed the need to dlopen libs at
> registration time to find out what's in it, component_getFactory was
> still the required entry point to actually get at them them.

        Right.

> I never really bothered to look at
> component_getImplementationEnvironment but I wonder if that could be
> elided in 90% of cases. i.e. that all merged libraries are going to have
> the same body there anyway.

        AFAICS it is a total waste of breath :-) Matus - this is another task
worth looking at - can you do an audit of all
component_getImplementationEnvironment calls and see if any do anything
interesting ? [ and what the default is if it is not there ] :-) one fun
cleanup may be just binning all of them.

> So instead of a "prefix" tag that's always added to both
..
> Though I suppose that makes it a little more difficult to undo
> a merge trivially.

        Quite; and:

> Well, as a low-hanging fruit I suggest that all the *.uno.so in the list
> that appear in the ure/lib install dir get merged together anyway. Those
> are all typically very small, too small really, libraries.
> libi18npaperlo.so and libi18nisolang1gcc3.so are too small too really.

        Sounds good to me, particularly if they are un-conditionally loaded.

> I wonder though about the developer rebuild-time hit if the
> bigger ones are linked into a mega-lib, sw and sc and svx
> are pretty big thumb-twiddlers when linking ?

        I guess one of the nice things about the new prefix is that (in theory
a least), we can have a release-build configuration where we link
*world* into one enormous library, with an hour-long link-time-
optimize / link / thrash phase - while keeping something like the
existing setup for faster developer re-linking, and do that from the
same object files.

> Some of these things are of course dlopened outside the uno-cod
> path as well, e.g. libdesktop_detectorlo IIRC

        Right - and often to avoid or detect run-time dependencies; Matus -
what that means is that we can't really drop the separate libvcl
plugins, since each depends on libraries that we want to pull in at
run-time.

        HTH,

                Michael.

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