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: