Mailing List Archive

At Thu, 26 Feb 2004 16:12:17 +0100,
Ivo Timmermans wrote:
> Would it be possible to make all public symbols in the library
> versioned? This is becoming increasingly important for Debian, with
> the growing popularity of GNUTLS as an alternative to OpenSSL. I
> could add them to the Debian package, but I'd rather see support for
> it in your releases as well.

If you are talking about versioned symbol support a la glibc, then
that is a lot of work.

If you are talking about sticking the same version on all symbols in
the library depending on the soname of the library, then that is not
so difficult (nor is it very difficult to maintain it). However, your
intention would then be to _load_ two versions of the library into the
same binary. For this to be supported, it is not enough to make all
symbols versioned. It must also be guaranteed that the two libraries
are not conflicting.

I don't know enough about libgcrypt to say if that is possible.
Potential trouble makers are signal handling, and anything that
accesses task-global state. It's a delicate issue, but worthwhile to
look into it. It's a delicate issue, though.

Thanks,
Marcus

On Thu, Feb 26, 2004 at 04:50:37PM +0100, Marcus Brinkmann wrote:

> If you are talking about sticking the same version on all symbols in
> the library depending on the soname of the library, then that is not
> so difficult (nor is it very difficult to maintain it). However, your
> intention would then be to _load_ two versions of the library into the
> same binary. For this to be supported, it is not enough to make all
> symbols versioned. It must also be guaranteed that the two libraries
> are not conflicting.
>
> I don't know enough about libgcrypt to say if that is possible.
> Potential trouble makers are signal handling, and anything that
> accesses task-global state. It's a delicate issue, but worthwhile to
> look into it. It's a delicate issue, though.

Does the linux ld's versioning solve all these problems? To enable
them adding a version string in libgcrypt.version is sufficient.

> Thanks,
> Marcus

--
Nikos Mavroyanopoulos

At Thu, 26 Feb 2004 18:37:09 +0200,
Nikos Mavroyanopoulos wrote:
>
> On Thu, Feb 26, 2004 at 04:50:37PM +0100, Marcus Brinkmann wrote:
>
> > If you are talking about sticking the same version on all symbols in
> > the library depending on the soname of the library, then that is not
> > so difficult (nor is it very difficult to maintain it). However, your
> > intention would then be to _load_ two versions of the library into the
> > same binary. For this to be supported, it is not enough to make all
> > symbols versioned. It must also be guaranteed that the two libraries
> > are not conflicting.
> >
> > I don't know enough about libgcrypt to say if that is possible.
> > Potential trouble makers are signal handling, and anything that
> > accesses task-global state. It's a delicate issue, but worthwhile to
> > look into it. It's a delicate issue, though.
>
> Does the linux ld's versioning solve all these problems? To enable
> them adding a version string in libgcrypt.version is sufficient.

My reply you quoted above explains why it does not solve the problems.

Thanks,
Marcus

On Thu, 26 Feb 2004 16:12:17 +0100, Ivo Timmermans said:

> Would it be possible to make all public symbols in the library
> versioned? This is becoming increasingly important for Debian, with

As Marcus already explained there might be problems with that approach
and especially for security critical library one should be very
cautiousness.

It is strongly suggested that one does not link to several versions of
libgcrypt and - as soon as 1.2 will be available - to update all
software to use 1.2. With that first stable version we will do our
best to not change the API even if we are required to change the API.
Plase recall that Libgcrypt is still marked under development.

Werner