[Gtk-sharp-list] opening libgtk-x11-2.0.so, not by SONAME / library management

[Marcel Pol]

On Sun, 1 Feb 2004 10:57:52 +0100
Eduard Bloch <blade@debian.org> wrote:

> I am working on proper Debian packages of Gtk-Sharp and a user recently
> run over a problem that is pretty reproducible and should be fixed.
> 
> Symptoms: a program fails to open "libgtk-x11-2.0.so"
> 
> Questions: why is this file used at all? It is only a virtual symlink to
> the library which corresponds to the headers/pkgconfig data. The library
> must be opened at runtime by using its SONAME:

It helps to change the config of mono (/etc/mono/config), so that it will load
the library by the SONAME. For the mandrake packages I used a static
configfile for this, but it would be better to generate this in a dynamic way.
No idea how to do that though.
It doesn't work for all cases though, running muine will try to load the glade
and gconf library through the devel library, and I'm not sure why that is (I
should investigate...). Maybe mapping that in the mono config to the correct
library will help here as well.


> Further, I was shocked (almost literaly) when I saw on the output of
> ldd...
> 
> ldd /usr/lib/libgtksharpglue.so | wc -l
> 64
> 
> That is one of the most chaotic lib namespace management I have ever seen!
> I am not a Gtk-Sharp developer but I strongly recommend to cleanup
> there, very, very, soon. libgtksharpglue.so should be linked with only most
> important libs, and use dlopen to open others, but using their SONAMEs,
> not .so, and not using anything listed in .la files since they often
> cause the whole system to wreak random havoc.

Here it is linked with the SONAME's. that's the same for you?
I was about to post a message about this issue as well. It is easy to package
the gtk-sharp dll files in seperate packages, but they all depend on the glue
library. So even if you just use gtk-sharp.dll in a piece of software, it
still loads glade, gnome libraries, gda, gnome-db, etc, because the glue
library needs it. Would it be possible to split the glue library in the same
way as the dll libraries? That would make it possible to have more finegrained
packaging, without having to install all dependencies for just one app.



--
Marcel Pol