Re: GNOME 1 ABI involving libpng
I'm considering again.
>>>>> On Wed, 28 Aug 2002 17:39:00 +0200,
>>>>> "MEM" == "Marcelo E. Magallon" <mmagallo@debian.org> wrote:
>>> Akira TAGOH <tagoh@debian.org> writes:
>> For this issue, I don't remember why I added those packages to
>> Depends(perhaps from discussion with Marcelo?)
MEM> yes.
ah, ok.
>> I think adding libpng3-dev to Build-Depends in the
>> applications/libraries which actually needs it is enough. so we may
>> remove libpng3-dev from libgtk2.0-dev's Depends.
MEM> if you remove that dependency, it will be possible to build an
MEM> application that links against libpng2 and libgtk2.0-0. Without
MEM> further changes in libgtk2.0-0 that's not desireable because the
MEM> application won't be able to use PNG files.
Notes that libgtk2.0-0png3 didn't breaks ABI. if that
application links gtk+2.0 and *libpng2* at the same time,
basically you are right. but that application needed to be
rebuilt agaist libpng3 anyway since gtk+2.0 linked against
libpng3. it's not related -dev's Depends, because we have
Build-Depends to solve this problem.
Actually if that application didn't links libpng directly,
it's unnecessary libpng3-dev to *use* libgtk2.0-dev.
MEM> We seem to agree that the best solution in this particular case is to
MEM> modify the loading of libraries without using RTLD_GLOBAL. The problem
MEM> with that is that dlopen is abstacted by glib, and the interface
MEM> doesn't allow for specifying this option. There's a chance that
MEM> modifying that behaviour might break something. The chance is
MEM> microscopic because the API documentation doesn't specify that opening
MEM> a module will import the module's symbols into the program's space.
MEM> Any application relying on that is relying on undocumented behaviour.
MEM> Even more, g_module_open might or might not do this depending on the
MEM> architecture, so it's not only undocumented but also undefined
MEM> behaviour.
GLib's API refference isn't enough for you?
file:///usr/share/doc/libglib2.0-doc/glib/glib-dynamic-loading-of-modules.html
MEM> With that in mind I'd say a) modify glib to NOT use RTLD_GLOBAL; b)
MEM> remove the dependency from libgtk2.0-dev; c) be happy. In that order.
MEM> And before someone cries that is making us incompatible with the world,
MEM> it's not. Read what I wrote about undocumented and undefined
MEM> behaviour. Relevant portion of the source (gmodule/gmodule-dl.c):
As written on a comment, when G_MODULE_BROKEN_RTLD_GLOBAL is
defined, it's only OSF1 V5.0. 'making us incompatible with
the world' points to almost Linux, doesn't it?
for example, do we need to keep a compatibility to run
OSF1's application?
--
Akira TAGOH : tagoh@gnome.gr.jp / Japan GNOME Users Group
at@gclab.org : tagoh@gnome-db.org / GNOME-DB Project
: tagoh@redhat.com / Red Hat, Inc.
: tagoh@debian.org / Debian Project
Reply to: