Date: Tue, 7 Mar 2006 22:19:22 -0500 (EST) From: Daniel Eischen <eischen@vigrid.com> To: current@freebsd.org Subject: RFC: Symbol versioning for libc Message-ID: <Pine.GSO.4.43.0603072214130.8396-100000@sea.ntplx.net>
next in thread | raw e-mail | index | archive | help
I've been working on symbol versioning libc and have a patch
that seems to work. It's been tested on x86 with build &
install world, KDE, mozilla, and firefox, but there may be
some problems I haven't found yet. These would likely result
in undefined symbol errors from libraries or applications.
I'd like to commit what I have to enable wider testing, but
turn off symbol versioning by default. I would also like
re@ to take a look at the version namespace scheme. The
following was derived from Sun's convention.
FBSD_1.0 (FBSD_X.Y[.Z])
This is the first rev of the public namespace for
libc and related libraries. For every minor
release of FreeBSD, starting with 7.0, the minor
version of the namespace will be bumped if there
is an ABI change. The version is bumped as soon
as the first ABI change hits the tree. If there
are no ABI changes, a minor-minor (subminer?)
version (Z) can be added (or bumped) to denote a
release, performance improvement, etc.
FBSDprivate_1.0 (FBSDprivate_X.Y)
This is our private namespace. Any symbols that
need to be visible outside of libc (or any other
versioned library) that are only meant for use by
our own libraries or applications are listed in
this namespace. For instance, _spinlock() which
is overridden in libc by the thread libraries, or
libc's __pw_scan() or __use_pts() which are used
by libutil. This is initially given a version
number, but is not bumped after introducing private
ABI changes or within release cycles. We provide
a complete system built from a consistent set or
sources, so there is no real need to maintain
ABI in this namespace. However, since our first
release may need to be compatible with older libraries
built before symbol versioning, it may require us
to provide at least one additional version.
The two namespaces allow us to write simple ABI-checking
tools (readelf -s application | grep "FreeBSDprivate") that
3rd-party developers can use to certify compliance with our
ABI. We (FreeBSD) will give no guarantees about anything
within the FreeBSDprivate version namespace; symbols within
that namespace may come and go within release cycles.
The proposed numbering scheme would be something along the
lines of this (in linker map format and in chronological order):
# Release 7.0
FBSD_1.0 {
};
FBSDprivate_1.0 {
};
# Release 7.1 - no ABI changes, depends on FBSD_1.0
FBSD_1.0.1 {
} FBSD_1.0;
# Release 7.2 - with ABI changes, depends on FBSD_1.0
# There is no benefit to depending on 1.0.1 since there
# are no ABI changes to inherit.
FBSD_1.1 {
} FBSD_1.0;
# Release 8.0 - with or without ABI changes
# This was branched from release 7.2. It could just as
# well have been branched from 7.0 or 7.1.
FBSD_2.0 {
} FBSD_1.1;
# Release 7.3 - without ABI changes, depends on FBSD_1.1
FBSD_1.1.1 {
} FBSD_1.1;
# Release 7.4 - with ABI changes, depends on FBSD_1.1
FBSD_1.2 {
} FBSD_1.1;
# Release 8.1 - with ABI changes, depends on FBSD_2.0
FBSD_2.1 {
} FBSD_2.0;
...
The latest patch is here:
http://people.freebsd.org/~deischen/symver/symver.diffs.030706
There's a brief description of symbol versioning here:
http://people.freebsd.org/~deischen/symver/library_versioning.txt
and you can find some other documents at:
http://docs.sun.com/app/docs/doc/817-1984
http://people.redhat.com/~drepper/symbol-versioning
or google.
--
DE
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.GSO.4.43.0603072214130.8396-100000>