On Tue, 2002-08-20 at 21:46, Henrique de Moraes Holschuh wrote: > On Tue, 20 Aug 2002, Luca Barbieri wrote: > > 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 > > Well, either this or using versioned symbols is required, and would have > almost the same effect. Do they work without needing to recompile programs? Versioned symbols (or simply symbols with a version number in the name) are surely better but the damage is already done. This is just a way to solve the current problem of having to choose between a libpng2 or libpng3 system rather than a long-term plan for shared library design. > > 2. Recompile all libraries that use either libpng2 or libpng3 to > > explicitly link to them and to use -Bsymbolic > > This should not be needed if versioned symbols are used. Do note that if you > compile something with -Bsymbolic, you cannot override the symbols it > both defines and uses. So, -Bsymbolic is more prone to cause side-efects > than versioned symbols. Surely. Are there any known real-world problems that would be caused by this? > > 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" > > Versioning would be -Wl,-soname,$@.$(MAJOR) where $(MAJOR) is the > versioning we want to apply. Same problem about versioning not being transparent (AFAIK). > > 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. > > I would like to have them in different address spaces, thank you very much > :) That's what symbol versioning does. By "address space" I mean process address space, aka the thing described by the kernel struct mm_struct that has its own set of pagetables and mmap areas and that is shared if you pass the CLONE_VM flag to clone. > > 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 > > (2) should NOT be needed. At least not if the explanation of -Bsymbolic drow > gave me on IRC (which seems to be what the ld info page says about the > matter) is correct. It is necessary because otherwise the library/program will use the first version of libpng in the global search list, which is exactly what we want to avoid. In case the module is the main program this is actually OK, so we don't need -Bsymbolic. > Could you try that again without using -Bsymbolic in anything but png2 and > png3? It won't work. -Bsymbolic affects the search path of the object that it is applied to so applying it to just libpng? is not enough (AFAIK) (But necessary because, as ridiculous as it may seem, one of the libpngs will use symbols from the other one). > > Are there any problems that would be caused by these changes? > > Well, -Bsymbolic is rumored not to be very portable, but as long as ld > supports it in all of our archs, that's a moot problem. AFAIK it does, if all our archs use glibc, that I think is the case. Anyway, this is a standard feature of the ELF object format, not the loader, so it should work on all non-broken ELF platforms (even if they aren't glibc-based).
Attachment:
signature.asc
Description: This is a digitally signed message part