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: