On Wed, Jul 24, 2002 at 03:50:42AM -0500, Marcelo E. Magallon wrote: > [ please Cc: mmagallo@debian.org ] > >> Steve Langasek <vorlon@netexpress.net> writes: > > What adding versioned symbols to libpng2 gives us is a smooth > > transition. If the rule is "ok, recompile everything against > > libpng3", there will be packages that are unnecessarily broken in > > unstable for a while. Maybe the number of broken packages is so > > small that we don't want to go to the effort of adding versioned > > symbols, but that's not how people were making it sound. > Ok. Let's see if I understand this. > The idea is to add versioned symbols to both libpng2 and libpng3, is > that right? And then recompile the stuff that wants to use libpng3? > The application is linked against libpng3, it wants to use png_foo, > which exists as png_foo@@PNG3 in the library and the linker notes that > at compile time. At run time the linker sees that the application > wants png_foo@@PNG3, it finds png_foo@@PNG3 and png_foo@@PNG2 and picks > png_foo@@PNG3 because of the versioned symbol. What happens in the > case of an application linked against libpng2 without versioned > symbols? It wants png_foo and the dynamic linker resolves that to ... > do I have to tell the dynamic linker that for applications wanting > png_foo it has to pick png_foo@@PNG2? How? I know how to make a > specficic symbol the default inside one library, but it's not clear to > me how to do that with two libraries. 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. > Anyways, I've compiled libpng2 and libpng3 with versioned symbols and I > have recompiled an application that uses libpng directly and that links > to another library which also uses libpng. The other library is > compiled against libpng2 and I compiled my application using libpng3. > I did *not* recompile the library. Checking the symbol table in my > application, it correctly lists the version string for libpng3 that I > have used. But the library's functions still can't read PNG files. I > get an error: > Unable to read logo Failed to load image '/usr/share/pixmaps/gnome-logo-icon.png': Fatal error in PNG image file: Incompatible libpng version in application and library > The application looks like this: > $ readelf -d ./celestia-gtk | grep png > 0x00000001 (NEEDED) Shared library: [libpng.so.3] > $ ldd ./celestia-gtk | grep png > libpng.so.3 => /usr/lib/libpng.so.3 (0x4077d000) > The library in question is libgdk_pixbuf-2.0.so which uses a plug-in > system to open PNG files. Can the fact that this library is > dlopen()'ing libpng.so.2 be a problem? What happens in this case is > that libgdk_pixbuf-2.0 maps libpng.so.2 in the application's space and > tries to load png_foo (not versioned) and the linker picks the first > one it finds (in this case the one from libpng3). 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.) > 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? Steve Langasek postmodern programmer
Attachment:
pgpIJEhQgUgcf.pgp
Description: PGP signature