libc_r no longer in DragonFly

It hasn’t been updated or used for some time, but libc_r was 20+ years old.  Now it’s gone.  You know someone younger than this code, or maybe even younger than the last time I talked about it.

Getting rid of libc_r

If you’ve got a really, really old DragonFly installation that been upgraded from… 1.8?  Perhaps earlier?  The system will be using libc_r instead of lib_xu.  If you want to change to lib_xu, which is the long-term goal, Hasso Tepper has the simple steps listed.

Libpthread changes

Threading libraries libc_r and libthread_xu have been synchronized by Hasso Tepper; this shouldn’t cause noticeable issues.  The potential issues he mentions for pkgsrc appear fixed, as I haven’t had any significant trouble (from that, at least)  during bulk builds.

How badly did that break things?

Hasso Tepper reported on the results of Peter Avalos’s major libc changes; someone retiring libc_r would help, as would someone figuring out why unistd.h isn’t found on DragonFly.

Graphs for fork profiling

Robert Luciani, one of the Summer of Code students for DragonFly, did some initial testing of the libc_r and libthread_xu libraries, with some graphable results. Unfortunately, there’s some degree of error, but that’s OK – I just like having tests performed and images created.

Floating point error and fix

Joerg Anslik found a strange error that turns out to have been a problem in handling floating point states; it’s fixed, but you will need to recompile kernel and libc_r if you are running bleeding edge code.

Benchmarking threading results

Antonio Huete used sysbench to benchmark a DragonFly system running either libc_r or libthread_xu. Aggelos Economopoulos graphed the results so far. Huete mentions that more results are forthcoming on more operating systems (same hardware), and they’ll be found here:

Libcr gone away

Matthew Dillon has removed libcr, since libc_r now links correctly against libc, and libcr is no longer needed.