On Wed, 2007-11-07 at 13:32 -0500, Behdad Esfahbod wrote: > On Wed, 2007-11-07 at 11:06 -0500, Ryan Lortie wrote: > > > > One library, one .so file, one pkg-config file. > > I'd say do a hybrid: separate pkg-config files, single .so. You can > even create .so symlinks, making it a build-time option to include a > "feature" in the gwhatever.so or build a separate .so for it, and > applications simply don't care. When that infrastructure is added, you > can even have glib, gobject, and gmodule in the same .so too, or have > separate ones. It's similar to what Qt does these days btw. This is a very interesting idea. And in fact, I think we could implement this in a backward and forwards compatible way, at least on linux. I did a simple test (see attached file) with creating libstuff1.so and libstuff2.so then linking test1 against these with -lstuff1 -lstuff2. Then i created a libstuff1.so containing the code from both stuff1 and stuff2 and made libstuff2.so be a symlink to libstuff1 and linked test2 in the same way. It looks to me like: 1) test1 and test2 look the same, at least wrt shared library dependencies 2) both binaries work in both the two separate libs and one lib + symlink case 3) in the one lib + symlink case we only load the one lib once This leads me to belive it should be possible to create a configure option for glib such that libglib, libgmodule, libgobject are in the same libglib.so file, and with symlinks for gmodule and gobject. This setup should allow all old binaries to work as they used to, plus apps linked against this setup will continue to work in systems using the old setup. Pretty sweet! As behdad said, there is a risk of people not linking to all the libs they need, but that could be fixed by splitting out the headers into separate dirs, enforcing correct use of the pkg-config files.
Attachment:
test_libs.tar.gz
Description: application/compressed-tar