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

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

 [ please Cc: mmagallo@debian.org ]

>> Steve Langasek <vorlon@netexpress.net> writes:

 > 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

    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).

 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.

 > 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.

 > >  I also tried recompiling a test program for libwraster (compile and
 > >  link against libpng3; run with libwraster linked against libpng2) and
 > >  I'm also having trouble with that.  Note that this isn't as stupid as
 > >  it sounds.  The program doesn't use any libpng's functions, it's just
 > >  contains libpng.so.3 in the NEEDED list.  libwraster does all the work.
 > Has libwraster been recompiled against libpng2+versions in this case?

 Nope.  I had hoped for a way to avoid recompiling all the libpng2 stuff
 but it seems there's none.


To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Reply to: