[csw-maintainers] Symbol versioning for openssl ?

Yann Rouillard yann at pleiades.fr.eu.org
Wed Jul 25 19:49:09 CEST 2012


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

> Yann Rouillard <yann at pleiades.fr.eu.org> wrote:
>
> > The problem is that the exemples explains how to enable direct linking
> when
> > you compile a binary against a program but it doesn't tell if it's
> possible
> > to compile a library in order to require direct linking when a program
> > tries to link with it.
>
> A library is bound by calling:
>
> cc -o libname -dy -G -ztext -h soname -M mapfile *.o -lneeded-libs
>
> I see no problem to add -Bdirect to this commandline.
>

Yes, but I need to ask for a modification of builds of every package linked
against ssl.
That's more difficult than to only make a modification in openssl.

It might also cause some problem if direct linking should be used against
libssl but not against another lib (you can workaround this by using "-z
direct -lssl" I think that we would need to insert this).
But I think there must not be many cases where direct linking is a problem.


>
> > I tried to change the mapfile like this (for openssl 0.9.8):
> >   OPENSSL_0.9.8 {
> >           global:
> >                   BIO_f_ssl = DIRECT;
> >                   BIO_new_buffer_ssl_connect = DIRECT;
> >                   BIO_new_ssl = DIRECT;
> >                   BIO_new_ssl_connect = DIRECT;
> >    [...]
> >
> > But it didn't work so far.
> > I might require every library / program that link with openssl to enable
> > direct linking but that would be more intrusive.
>
> Wouldn't it be sufficient to just make the high level libs and the final
> binary
> use -Bdirect?
>

Well after having read what "-B direct" is, I think it would be a even
better idea to enable it for all packages in Opencsw.
That is supposed to more efficient and that would solve runtime dual
linking problem for every library without having to enable symbol
versioning (symbol versioning is a good thing but is more work, I still
have to figure how to easily manage and update this file for openssl).

I am trying to gather some more information and I will send a proposal.


BTW, a real-life test with neon linked against openssl 0.9.8 with "-B
direct" shows that it works:
# LD_DEBUG=all,detail cadaver
[...]
01175: file=/opt/csw/bin/cadaver;  add binding to:
01175:     file=/opt/csw/lib/i386/libssl.so.1.0.0   [ NEEDED ]
[...]
01175: version needed processing: file=/opt/csw/lib/libneon.so.27
01175:             file                        version
01175:             libcrypto.so.0.9.8          OPENSSL_0.9.8
01175:
01175: file=/opt/csw/lib/libneon.so.27;  add binding to:
01175:     file=/opt/csw/lib/libcrypto.so.0.9.8   [ NEEDED ]
[...]
01175: 1: binding file=/opt/csw/lib/libneon.so.27 (0xfecbe86b:0x1e86b) at
plt[349]:full to file=/opt/csw/lib/libssl.so.0.9.8 (0xfe4f2f30:0x32f30):
symbol 'SSL_load_error_strings'  (direct)
01175: 1: binding file=/opt/csw/lib/libneon.so.27 (0xfecbe870:0x1e870) at
plt[350]:full to file=/opt/csw/lib/libssl.so.0.9.8 (0xfe4fd9f0:0x3d9f0):
symbol 'SSL_library_init'  (direct)
[...]

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


More information about the maintainers mailing list