[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Symbol versioning in Linux distributions

From: Thomas Dickey
Subject: Re: Symbol versioning in Linux distributions
Date: Thu, 14 Jan 2016 21:19:23 -0500
User-agent: Mutt/1.5.21 (2010-09-15)

On Thu, Jan 14, 2016 at 05:04:30PM +0100, Miroslav Lichvar wrote:
> Hi,
> in ncurses-6.0 was added support for versioning of symbols in the
> ncurses libraries, which by default is disabled. It seems some
> distributions are already using it. As the maintainer of the Fedora
> package I was wondering if there are any upstream recommendations for
> distributions whether to build with this feature enabled or disabled.
> The INSTALL text describes the map files as samples. Does that mean
> incompatible changes in the naming are expected to happen?

no... I marked them as "samples" for two reasons:

        a) the files are formed by merging symbols from multiple
           build-configurations.  While there's probably lurking that
           merge the possibility of two "equivalent" symbols providing
           different behavior, the intent of doing it this way I could
           point out the symbols which are known to exist, along with
           the release at which they were added.  A purist would insist
           on a single configuration -- which doesn't exist across the
           various packages that I know of.

        b) as a merge, each file contains some symbols which do not
           exist in some given build-configuration.  Linux's linker
           accepts that, and (with a little tweak) the BSDs do also.
           Solaris doesn't.  When I get to this item on my to-do list:
           that will show the scripts which I used to generate the
           map-files.  So someone else could generate something similar.

So calling them "samples" is a caveat to the packagers that the files
don't solve all possible problems.  (I use them, of course).

> It's not clear to me what exactly is the intention of this feature.
> To allow the library to have the same symbol in multiple versions to
> not break the ABI for old binaries like glibc does for instance? Or
> just to make it easier to see what ncurses version (patch?) a binary
> needs to run?

Mostly the latter: I don't have any plans to provide the same symbol
in multiple versions.  The story on this goes quite a ways back, but
the purpose for including it in ncurses6 is to help ensure that programs
linked against ncurses6 don't run against ncurses5, and vice versa.

Being able to do that helps Debian accept the release as a
binary-incompatible upgrade (256-colors and wheel-mouse).
> Now that some distributions use it and some don't I think there is a
> problem that binaries built with versioned symbols won't load on
> distributions that don't have it enabled yet. I'm not sure if anyone
> needs to do that these days. It also means it's difficult to disable
> it once it's enabled, so I'd like to know what I'm getting into :).

I suppose some people distribute binaries expecting them to load across
distributions, but I haven't seen success in that except for instance
between Red Hat vs CentOS.

Some platforms use libtinfo, some don't - that's the sort of impact
that I see in using versioned-symbols.

Thomas E. Dickey <address@hidden>

Attachment: signature.asc
Description: Digital signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]