[prev in list] [next in list] [prev in thread] [next in thread] 

List:       gtk-devel
Subject:    Re: Merging gio into glib
From:       Alexander Larsson <alexl () redhat ! com>
Date:       2007-11-11 20:16:26
Message-ID: 1194812186.21228.11.camel () localhost ! localdomain
[Download RAW message or body]


On Fri, 2007-11-09 at 14:43 -0500, Behdad Esfahbod wrote:

> > There is a slight problem with ldconfig. It goes throught the
> > $prefix/lib directory and "fixes" up all symlinks based on the actual
> > soname in the files. This means it will change the libglib.so.0 symlink
> > to point to libglib.so, totally breaking things. I've worked around this
> > by having the dummy library be in another directory
> > ($libdir/glib-2.0/dummy/) which causes ldconfig not to change anything.
> 
> Makes sense to have them in a separate lib as they are not actual
> libraries.  $libdir/glib-2.0/stubs or something... and pkg-config makes
> it completely transparent.  Though the pkg-config --libs should probably
> give full path to the stub object instead of -L followed by -l.

I'm not sure what pkg-config should output, especially if that then gets
put into libtool .la files. However, imho we really need to ship the
symlink so that "-lglib -lgobject" gcc lines keep working. Not everyone
uses pkg-config.

> You can gain even more.  I guess with your approach, gobject is not
> linking to "internal" glib objects, but to the public aliases.  That is,
> it's going through PLT entries.  That can be optimized too.  We need to
> find a extensible scheme to include the aliases files from all modules
> being combined and do all the work...

I don't think this will be that hard.


_______________________________________________
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
[prev in list] [next in list] [prev in thread] [next in thread]