[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:

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

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

 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.

 I'll check what libpng does (and how it figures that two versions of
 libpng are loaded), perhaps that's the problem.

 Any feedback appeciated,

 Marcelo


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



Reply to: