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

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



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


Reply to: