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.me...@novell.com <><, Pseudo Engineer, itinerant idiot
_______________________________________________
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
