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

Re: Accepted sdl-image1.2 1.2.2-1 (i386 source)

On Wed, Jul 24, 2002 at 05:03:16PM +0200, Marcelo E. Magallon wrote:

>  > In the case where an application looks for the symbol with no
>  > versioning information, the symbol will be resolved in the
>  > traditional, first-come-first-serve order.  This is why a smooth
>  > transition requires that everything be recompiled against the
>  > version-using libraries, since both libpng2 and libpng3 will still be
>  > providing conflicting, unversioned copies of the symbols.

>  Ok.  I had suspected that.

>  So the transition plan would be something like this:

>  0. Recompile libpng2 and libpng3 with versioned symbols.

>     Nothing in Debian will break because applications linked against the
>     old libpng2 or libpng3 will still be able to have their PNG
>     dependencies resolved (both at package level and symbol level)

>  1. Recompile all the library packages that link against libpng2 or
>     libpng3.

>     Nothing broken yet

>  2. Recompile all the packages that depend on those libraries.

>     Still nothing broken

>  3. Start migrating stuff to libpng3

>     Since now everything is using versioned symbols, mixing libraries
>     linking against libpng2 or libpng3 is not a problem.

>     Passing pointers to opaque PNG data structures is a problem because
>     each png library will treat will expect these data structures to be
>     in its own format.  The question is if that's really an issue.

>  4. At some point everything is compiled against libpng3 and we keep
>     libpng2 arround only for compatiblity

>  The catch here is step 0.  This breaks compatibility with other
>  distributions.  Stuff compiled against non-versioned libpng2 or libpng3
>  will work in Debian (with the same potential problems as we have now),
>  but stuff compiled on Debian won't run on other distributions because
>  the dynamic linker looks for versioned symbols and doesn't find them
>  (or that's the impression I have after reading the relevant portions of
>  ld.info -- I haven't tried this yet).

Your understanding is correct -- a binary that wants a versioned symbol
will not settle for an unversioned symbol.  Is this a grave concern?
Do we know that there are ISVs compiling (libpng-using) software on
Debian today with the expectation that their binaries will work
elsewhere?  As far as I've heard, /no one/ develops software on Debian
except for use on Debian-derived systems.

>  Other than that, does that plan look ok?  Did I miss something?  Can it
>  be made shorter?  We are talking about a total of 400+ packages here.

I believe this is the shortest plan that provides a clean upgrade path
without breaking SONAMEs.

It is possible to enforce limits on the transitional period; if
maintainers of small packages that need to be recompiled have not done
so after an open bug has been sitting idle for (e.g.) 4 months, the
libraries they depend on can be recompiled against libpng3, and the
programs can be visibly broken.  There's no reason to pander to inactive
maintainers in the name of a smooth transition.  In some cases, doing so
just prolongs the transition.

>  > Actually, I would expect that any library or application that
>  > dlopen()s a library would not suffer at all from segfaults; if you
>  > *only* use the handle returned by dlopen(), then there is no risk of
>  > getting the symbols from the wrong library.  So I can only conclude
>  > that libgdk_pixbuf-2.0.so is doing something extraordinary here.
>  > (Mixing dlopen() with the runtime linker's symbol resolver qualifies
>  > as extraordinary.)

>  Yeah, sorry, I looked at it again.  What libgdk_pixbuf dlopen()s is a
>  small plug-in which is linked against libpng.so.2 directly.

Ah, that makes sense.

Steve Langasek
postmodern programmer

Attachment: pgp9EQc1oPsf0.pgp
Description: PGP signature

Reply to: