... 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.
In other words it's exactly the case of "cross-pollution" of name space
by indirect link with different versions of OpenSSL .so. Thanks to
-Bsymbolic at least libcrypto.so.0.9.7 doesn't affect
libcrypro.so.0.9.8, but libcrypto.so.0.9.7 can affect libssl.so.0.9.8
[and/or vice versa].
For the record. I reckon that -Bsymbolic is more than appropriate in
OpenSSL context as it prevents overloading of inner calls by another
module. A.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager [EMAIL PROTECTED]
