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
