RPM Community Forums

Mailing List Message of <rpm-devel>

Re: librpmmisc approach for handling shared external libraries doesn't look sane

From: Alex Myltsev <avm@altlinux.org>
Date: Wed 11 Jul 2007 - 08:17:50 CEST
Message-ID: <ffae7d540707102317n400d2069vd7798375087a2884@mail.gmail.com>
On 7/11/07, Mark Hatle <mark.hatle@windriver.com> wrote:
> if librpm* has a requirement on librpmmisc, and librpmmisc requires the
> libraries (static or shared) it works w/o --as-needed.
No, not really. It may break in the presence of symbol versioning.

Consider this case:
* the developer links librpmmisc against his development version of
libfoo.so.1, which provides two interfaces: FOO_1 and FOO_1.1;
* the linker notices that librpmmisc does not require any of the
symbols from any of these interfaces, so it only records the
dependency on libfoo.so.1;
* the new RPM package only depends on libfoo.so.1, not on libfoo.so.1(FOO_1.1)
* the user then installs this new RPM alongside his (older)
libfoo.so.1, without the FOO_1.1 interface.

Now rpm fails to work, telling the user that some symbols are missing.
The user cannot upgrade his libfoo anymore, because rpm isn't working,
and we've got trouble...

There are AFAIK two ways to solve this problem:
(1) ensure that in all of the supported distributions, none of the
libraries used by RPM use symbol versioning in a way that can break
RPM, or
(2) just link the libraries with whatever they require.
Received on Wed Jul 11 08:17:52 2007
Driven by Jeff Johnson and the RPM project team.
Hosted by OpenPKG and Ralf S. Engelschall.
Powered by FreeBSD and OpenPKG.