[csw-maintainers] Symbol versioning for openssl ?

[Joerg Schilling]

Yann Rouillard <yann at pleiades.fr.eu.org> wrote:

> Well I expected it to work more like it does on Linux (more details below).

versioned libraries have been introduced on Solaris nearly 20 ears ago. They 
have been introdiuced recently on Linux and ti me, it seems that Linux copied 
the Solaris model after they had a really strange intermediate solution.

> Here is the problem I want to solve:
>      application APP1 is linked against libB.so.2 and libC.so.1
>      libC.so.1 is linked against libB.so.1
>      libB.so.1 and libB.so.2 have incompatible sonames.
>
>      At runtime, I want:
>         - APP1 libB symbols to be linked against libB.so.2,
>         - libC.so.1 libB symbols to be linked against libB.so.1.
>
>      Currently, what I have is:
>         - APP1 libB symbols linked against libB.so.2 (that's ok),
>         - libC.so.1 libB symbols linked against libB.so.2 (that's not good)

Why is this not good? Is libB.so.2 incompatible to libB.so.1?


> The reason I want this is that I would like to be able to gracefully handle
> a library soname upgrade for libraries like openssl.
> Currently as openssl is directly linked by a lot of libraries and binaries,
> when you provide a new library (with incompatible soname), you have to
> recompile and upload all the reverse-dependant packages at the same time to
> be sure not to have a situation like described above.
>
> This takes a lot of time and needs a lot of coordination.

A library upgrade works easy if the author of the library is careful, keeps 
the same soname and does not introduce incompatible changes but only compatible 
enhancements.

> > Symbol versioning however allows to link against an older version of the
> > library at runtime than the one that was used at compile time - given that
> > the
> > user does not need the new features of younger library versions.
> >
>
> Yes I do understand that. It allows a binary compiled against openssl 1.0.1
> to work against openssl 1.0.0 if the binary only used functions compatibles
> with openssl 1.0.0 (openssl 1.0.1 and openssl 1.0.0 provide the same soname
> libssl1.0.0 but openssl 1.0.1 may have added new functions).
> And if the binary used a openssl 1.0.1 specific function, the linker will
> prevent you from running the binary on a computer with the openssl 1.0.0
> library, even though the openssl 1.0.0 provides the same soname.
>
> But I also expected the symbol versioning to work at the symbol level (and
> not at the library level) so the linker will also use that information to
> understand against which library each symbol must be linked, in case the
> same symbol is provided by two libraries loaded at runtime.

Library versioning works at symbol level. Maybe your mapfile is not correct.
Given the fact that the same mapfiles work on Solaris and Linux, I am not 
convinced that Linux is different.

> This is how it works under Linux.
>
> Do you know how to achieve this under Solaris, or how to solve the general
> library upgrade problem in a general manner ?
>
> Thanks in advance for your answer.
>
>
> To explain how it works under Linux, here is a real exemple:
>
>  - I have a neon library directly linked against libcrypto and libssl 0.9.8
>
> # objdump -xT /usr/lib/libneon.so.27.2.6
> [...]
>   NEEDED               libcrypto.so.0.9.8
>   NEEDED               libssl.so.0.9.8
> [...]
> 0000000000000000      DF *UND* 0000000000000000  OPENSSL_0.9.8 SSLeay
> [...]
>
>  - I have a cadaver binary directly linked against libneon and libcrypto
> 1.0.0
> # objdump -xT /usr/bin/cadaver
> [...]
>   NEEDED               libcrypto.so.1.0.0
>   NEEDED               libneon.so.27
> [...]
> 0000000000000000      DF *UND* 0000000000000000  OPENSSL_1.0.0 SSLeay
> [...]
>
>  - at runtime, both libcrypto libraries are loaded and the linker correctly
> link cadaver and libneon with the good version of the library:
> # LD_DEBUG=all LD_BIND_NOW=1 cadaver
> [...]
>      21796:     file=libcrypto.so.1.0.0 [0];  needed by cadaver [0]
>      21796:     find library=libcrypto.so.1.0.0 [0]; searching
>      21796:      search cache=/etc/ld.so.cache
>      21796:       trying file=/lib/x86_64-linux-gnu/libcrypto.so.1.0.0
> [...]
>      21796:     file=libcrypto.so.0.9.8 [0];  needed by
> /usr/lib/libneon.so.27 [0]
>      21796:     find library=libcrypto.so.0.9.8 [0]; searching
>      21796:      search cache=/etc/ld.so.cache
>      21796:       trying file=/lib/x86_64-linux-gnu/libcrypto.so.0.9.8
> [...]
>      21796:     binding file /usr/lib/libneon.so.27 [0] to
> /lib/x86_64-linux-gnu/libcrypto.so.0.9.8 [0]: normal symbol `SSLeay'
> [OPENSSL_0.9.8]
> [...]
>      21796:     binding file cadaver [0] to
> /lib/x86_64-linux-gnu/libcrypto.so.1.0.0 [0]: normal symbol `SSLeay'
> [OPENSSL_1.0.0]
> [...]

SSLeay may have version tags for more than version but there cannot be 
different SSLeay implementations.

Jörg

-- 
 EMail:joerg at schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
       js at cs.tu-berlin.de                (uni)  
       joerg.schilling at fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily