I propose to do the following to solve the libpng2/3 problem. I've
recompiled libpng2. libpng3 and libgtk2.0-0png3 locally and the system
seems to work correctly.
1. Recompile libpng2 and libpng3 with -Bsymbolic
2. Recompile all libraries that use either libpng2 or libpng3 to
explicitly link to them and to use -Bsymbolic
3. Recompile all programs that use either libpng2 or libpng3 to
explicitly link to them [all programs should already do
this]
4. Make either libgtk2.0-0 or libgtk2.0-0png3 a dummy package
depending on the other
Note1: for GTK+ 2.0, only the png loader plugin needs to be recompiled
with -Bsymbolic
Note2: "recompile with -Bsymbolic" means "add -Wl,-Bsymbolic to the
flags passed to the compiler in the linking stage, rebuild and upload
the new package"
Doing this will allow applications using GTK+ to use either libpng2 or
libpng3 and still work correctly.
I'll now explain what the problem is and why this solution works.
The problem is that libpng2 and libpng3 have symbols with different
names and we want to have both loaded in the same address space.
Symbols are resolved by the GNU dynamic linker, part of glibc, that
normally uses the same search list for all modules.
This means that normally when two symbols have the same name everything
will use the symbol in the first module loaded.
What we instead want is to use the symbol in the library that the
calling module links to.
Fortunately the ELF object format offers a "flag" called DT_SYMBOLIC
that alters the search path so that symbols are first searched starting
from the calling module.
This is exactly what we need.
So we can solve this by making sure that anything that wants to use png
symbols:
1. Directly links to the desired version of libpng
2. Is either the main program or is linked with -Bsymbolic
Of course, there is a drawback: programs will no longer be able to
always redefine library symbols. AFAIK this is mostly irrelevant when
compared to the problems that come from not doing this.
Are there any problems that would be caused by these changes?
Attachment:
signature.asc
Description: This is a digitally signed message part