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