[csw-maintainers] Symbol versioning for openssl ?

[Yann Rouillard]

Hi Joerg,

2012/7/22 Joerg Schilling <Joerg.Schilling at fokus.fraunhofer.de>

> Yann Rouillard <yann at pleiades.fr.eu.org> wrote:
>
> > It seems the version check is only done to see if the whole library can
> be
> > loaded (and only if the application/library and the library both use
> > versioning), but it is not used after to link the symbols.
> >
> > From what I understood, symbol versioning in Linux works at the symbol
> > level and would effectively help to prevent the kind of problem we have
> > here.
>
> I am not sure whether you have different expectations than what symbol
> versioning is.
>

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


>
> What problem do you have and how do you like to solve it?
>

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)


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.



>
> Symbol versioning cannot heal incompatible changes.


> 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.

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]
[...]



Yann





>
> Jörg
>
> --
>  EMail:joerg at schily.net                  (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
> _______________________________________________
> maintainers mailing list
> maintainers at lists.opencsw.org
> https://lists.opencsw.org/mailman/listinfo/maintainers
> .:: This mailing list's archive is public. ::.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opencsw.org/pipermail/maintainers/attachments/20120722/95470d4e/attachment.html>