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

Re: RFC: SDL and X static extension libraries re-revisited

>>>>> "Branden" == Branden Robinson <branden@debian.org> writes:

    Branden> On Fri, Nov 02, 2001 at 05:32:44PM -0500, Sam Hartman
    Branden> wrote:
    >> Hmm, I was sort of assuming that you would have libsdl depend
    >> on xlibs-pic rather than things that depend on using sdl in a
    >> plugin architecture.  The advantage of this is that you can
    >> manage the tricky versioning issues in one case (libsdl) and
    >> minimize the number of people who have to get sonames changes,
    >> conflicts, etc right.

    Branden> Except that there's no *reason* for libsdl to declare a
    Branden> dependency on xlibs-pic.  Everything that's going to need
    Branden> those static extension libraries will be statically
    Branden> linked with them.  Almost all will use the regular static
    Branden> versions in xlibs-dev; a very few will require the PIC
    Branden> objects in xlibs-pic.

I argue that linking libsdl against the pic versions of the extension
libraries and not linking the applications against the extension
libraries at all may be preferable to linking the applications against
the static versions of the extension libraries.  Before flaming please
look at my assumptions and see if I'm being reasonable.

I assume:

1) The static extension libraries are more likely to change than
   libsdl's public interface.  

2) Libsdl presents a good enough abstraction that libsdl-using
 applications rarely need to call the X extension libraries
 directly.  Instead they call libsdl.  The only reason they need to
 depend on libsdl is that  libsdl calls these extensions.    That is
 there are no application subroutines that have references to the
 extension libraries even though there are application subroutines
 with references to libsdl and  libsdl subroutines with references to
 extension libraries.

3)  IT is possible to limit the set of symbols exported from an elf
    shared object to those who want to dynamically link against that
    shared object.

Given these assumptions we can evaluate two possible approaches.

A) (This is what I believe you are proposing).  The libsdl does not
link against the extension libraries but instead leaves these symbols
undefined.  Applications link against libsdl and the extension
libraries  to define these symbols.  Plugins link against the -pic
extension libraries and the shared libsdl.

B)  Libsdl links against the -pic extension libraries   and
applications and plugins link against libsdl only.

O, wait, that won't work  will it?  Well' it would work  but we'd
again be in the situation where applications linked on Debian won't
work on Redhat.

Really it is unfortunate that proposal B won't work well. It had the
nice property that you only needed to change the soname of libsdl when
libsdl's public interface changes.  Under proposal A, you need to
change the soname either when libsdl's public interface changes or
when an extension library changes.  If you do not then I cannot have
applications installed on my system that depend both on the old and
new libsdl.

Reply to: