Symbol versioning errors in libthr

Peter Wemm peter at
Sun Feb 3 15:59:48 UTC 2008

On Feb 3, 2008 8:16 AM, Dag-Erling Smørgrav <des at> wrote:
> Here's an excerpt from the RELENG_7 vs HEAD diff of libthr's symbol map:
> --- 13 May 2007 14:12:39 -0000      1.18
> +++ 20 Dec 2007 04:32:28 -0000      1.21
> @@ -84,9 +84,13 @@
>         pthread_multi_np;
>         pthread_mutex_destroy;
>         pthread_mutex_getprioceiling;
> +       pthread_mutex_getspinloops_np;
> +       pthread_mutex_getyieldloops_np;
>         pthread_mutex_init;
>         pthread_mutex_lock;
>         pthread_mutex_setprioceiling;
> +       pthread_mutex_setspinloops_np;
> +       pthread_mutex_setyieldloops_np;
>         pthread_mutex_timedlock;
>         pthread_mutex_trylock;
>         pthread_mutex_unlock;
> These functions are all in FBSD_1.0, but they were introduced after the
> branch and never MFCed, so if I understand how we've implemented symbol
> versioning, they should be in FBSD_1.1.
> Unless someone argues credibly for keeping them in FBSD_1.0, I will move
> them to FBSD_1.1 in a few days.

I'm not sure I see the point in that.  Consider the not-moving-to-1.1
case.  If somebody takes an 8.0 binary and runs it on 7.x, then
they'll get a 'symbol not found' error.  On the other hand, if they're
moved and somebody tries the same thing, then they still get the same
kind of 'symbol not found' error but with just one character

The point of symbol versioning is to allow incompatible changes.  eg:
to have a FBSD_1.0 version of  pthread_mutex_getspinloops_np() *AND* a
FBSD_1.1 version of     pthread_mutex_getspinloops_np() in the library
at the same time.  The 1.0 instance would presumably be an API/ABI
conversion wrapper around the newer functions.

Peter Wemm - peter at; peter at; peter at
"All of this is for nothing if we don't go to the stars" - JMS/B5

More information about the freebsd-current mailing list