[csw-maintainers] Symbol versioning for openssl ?

[Yann Rouillard]

Hi Joerg,

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

> > 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?
>
>
Yes they are incompatible. libB.so.2 has a different soname, it is not ABI
compatible with 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.
>

Well, libraries authors change the soname from time to time when they don't
want to maintain the ABI compatibility for some reason.
I do agree there should not be any problem if the soname is kept and if the
ABI compatibility is maintained by the authors.
But the case here is a library upgrade with a soname/ABI modification.


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

Yes, its works at the symbol level but:
  - the linker doesn't seem to use that information when it links a given
symbol, it only uses it to check wether or not it can load a library,
  - it is not registered at the symbol level in the solaris elf file (that
could perfectly work without it, but it seems that the version is stored
for each symbol in Linux elf files).

But I may have done something wrong, you could have a look at my previous
email to see the tests I made (I showed the output of pvs to check if the
symbol versioning information was there) and I just commited my
modifications so you can have a look on svn:
 - the mapfiles are here:
http://gar.svn.sourceforge.net/viewvc/gar/csw/mgar/pkg/openssl1/trunk/files/map.openssl.engines
 ,
http://gar.svn.sourceforge.net/viewvc/gar/csw/mgar/pkg/openssl1/trunk/files/map.openssl.libssl
 and
http://gar.svn.sourceforge.net/viewvc/gar/csw/mgar/pkg/openssl1/trunk/files/map.openssl.libcrypto

 - the modification I've made are in this patch:
http://gar.svn.sourceforge.net/viewvc/gar/csw/mgar/pkg/openssl1/trunk/files/0007-enables-symbols-versioning.patch?revision=18832&view=markup
   Basically I've just added the "-M" option.


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

Well it is the case here.
 - libcrypto.so.0.9.8 provides the SSLeay symbol.
 - libcrypto.so.1.0.0 also provides the SSLeay symbol.
 - but these 2 libraries are not ABI compatibles so we're not supposed to
link against libcrypto.so.1.0.0 a SSLeay symbol present in a binary that
was compiled against libcrypto.so.0.9.8.

Tell me if I understand something wrong here.

Thanks for your

Yann
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opencsw.org/pipermail/maintainers/attachments/20120723/e002da18/attachment-0001.html>