Re: Merging gio into glib

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 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 and then linking test1 against these with -lstuff1 -lstuff2.
Then i created a containing the code from both stuff1 and
stuff2 and made 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
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 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

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

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]