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... Does it > simply conflict with your less-than-three-numbers convention [not that > something is wrong with such convention, I'm just asking!] or is there > some other reason? I'm not saying that that we refuse to change .so > versioning in any way, all I want is to do things for right and > recognized reasons, not just upon "we have had some problems." 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. Is it the case? Can you elaborate on which symbols were > overloaded? You can figure this out by examining dynamic name tables *in > pam modules* with objdump -T.
If you want an example of things breaking because of the transition from 0.9.7 to 0.9.8, look at: http://bugs.debian.org/334180 In this case, libpq (from postgresql) was linked to libssl0.9.7, and dovecot was linked to libpq and libssl0.9.8. It gave some strange error message indicating it couldn't load libz.so. I really don't want to debug this, it's alot more easier to just relink libpq against libssl0.9.8. Kurt ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
