Impacts of libc versioning (just committed)

John Marino dragonflybsd at
Sat Sep 12 07:59:40 PDT 2015

I just made a commit that will cause libc to be built with symbol
versions from now on.  Among other benefits, this means that libc will
never be "bumped" again, so the library's name is frozen at /lib/

All third-party programs should continue to work (with a possible
exception of a program wrongly using a libc variable or function that
shouldn't have been exposed and which is no longer exposed).

It is possible that a quickworld build is sufficient to upgrade.
However, this is neither tested nor recommended.  You should plan on
your next build being the "full" build type just to be on the safe side.

All dports "master" packages (4.4) built after this date will not
function on older systems that have not been upgraded past this commit:

Consequently, when the next bulk build for "master" is published, the
current build will be moved from:

This "OLD_LIBC" directory will be frozen and will remain in place until
DragonFly 4.4 is officially released.  It is only for people that
haven't the time to upgrade to the latest master version, but still need
to install some new packages.

When the new packages are available, it would be a good idea to
explicitly replace *ALL* packages on the master system.  To do that, you
can use the "Bullet-proof upgrade technique" outlined here:

Hopefully everything will go smoothly with this transition, but
understand that this is a pretty significant change to libc.

- John

More information about the Users mailing list