On Fri, Oct 28, 2005 at 09:46:30AM +0200, Andy Polyakov wrote: > > Now question to Johnny Lam [who is complaining that we don't bump > versions] and Christoph Martin [who suggests to add versioning on all > symbols]. What exactly didn't work for you? As far as I understand both > NetBSD and Debian are ELF-based so it should have worked...
The current soname is libssl.so.0.9.8, the previous one was libssl.so.0.9.7. A single library or binary ussually doesn't end up linked to both of those, but some binaries do end indirectly linking against both sonames. Any ELF object (library, progam) can have DT_NEEDED records in it, saying it's using symbols from that. Say libA links against libssl.so at the time the soname is libssl.so.0.9.7 and adds an DT_NEEDED for it. Then you also install libssl.so.0.9.8, you link a program progA against both libA and libssl.so. So you have: progA - DT_NEEDED: libssl.so.0.9.8 - DT_NEEDED: libA libA: - DT_NEEDED: libssl.so.0.9.7 Now, if you load progA, it loads: libssl.so.0.9.8, libA, and libssl.so.0.9.7, because libA needs it. Then when the dynamic linker looks for a symbol, it looks at it by name. It will go over all objects to see if it exists in it. It will use the symbol from the first library it finds it in. This means, that a symbol that libA requires, and _should_ get from libssl.so.0.9.7, can also exist in libssl.so.0.9.8, and will most likely be using that. If libssl.so.0.9.8 has a different ABI, this breaks. The way to make sure that libA gets the symbol with the right ABI, is to have all symbols have a unique name. This can be done with symbol versioning. It then gets named "symbol@@version". The runtime linker adds references to the versioned symbol, and dynamic linker then looks for the versioned symbols. This allows you to indirectly link to more than 1 version of the library without having to worry about the ABI having changed. There are also more advanced things you can do with symbol versioning, but those are not what we want. Atleast not at this time. The only thing we want here is to have a unique name for all symbols. > Well, in > PAM case I can imagine problem with GLOBAL_OFFSET_TABLE being > "cross-polluted" by 0.9.7 and 0.9.8 being *both* mapped into same > application. There have been problems reported breaking pam, but I don't know the details about it. It most likely was fixed by relinking the affected modules against the new libssl. Kurt ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]