On Wed, 25 Apr 2007, Gabriel Schulhof wrote:
On Tue, 2007-04-24 at 13:28 -0400, Behdad Esfahbod wrote:
Don't forget that the more libraries you have, the longer the dynamic
linker will work to resolve all the symbols, and consequently the longer
it will take for each application to start.
And each shared library consumes at least one page of private
per-process data memory.
These are absolutely true.
So, I'm wondering: How difficult would it be to set up the GLib build
system to give distributors a choice as to whether to compile all bits
(glib, gobject, gthread) into a single .so (e.g. for desktop
applications) or leave it as is or, for that matter, split it further
(though not by default), as Brandon has suggested into more .so files ?
the answer to this is very straightforward, someone simply has to invest
the necessary energy to find out how difficult it is. without anyone
having a real need for that, it definitely won't happen (it hasn't
happened yet afaik at least).
And, while we're on this track: How about GTK and GDK ? In some embedded
systems it may very well turn out that GDK is used on its own far too
rarely to warrant having it a separate library. Why not then have a
single library and save a little loading time and a page of memory.
we've discussed that during last GUADECs Gtk+ meeting:
http://mail.gnome.org/archives/gtk-devel-list/2006-June/msg00146.html
the main outcome was that the ability to disable some of the non-strict-core
widgets in Gtk+ could be an interesting code size reduction in embedded
contexts. if done properly and if it's possibly interesting to have
for multiple parties, compilation subsets could also be backfolded into
the upstream Gtk+ configure.in/Makefile.am.
so far, no one has really attempted this and submitted a patch though,
and without anyone taking a stab at it, it won't happen.
Having such a flexible build system could be a boon.
---
ciaoTJ
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
