Threading libraries

Hasso Tepper hasso at estpak.ee
Sat Dec 13 23:13:10 PST 2008


Justin C. Sherrill wrote:
> On Sat, December 13, 2008 4:35 pm, Hasso Tepper wrote:
> > Justin C. Sherrill wrote:
> >> What would this mean for the 2.2 release?
> >
> > It would be OK, but ... I'm concerned about the fact that features
> > specific to libthread_xu (for example barriers) haven't got any
> > testing so far, but these will be used by third-party apps if libc_r
> > will be removed. I don't feel comfortable doing this move so close to
> > release, so I'd prefer post 2.2 move.
>
> How can we test?  I'm doing a pbulk build using the _xu library on
> Matthias's system right now, but I'm guessing we would have to actually
> be executing the binaries to find out what works and what doesn't.

We can test by removing libc_r only, that's the point.

> >> Would people who had been upgrading from pre-xu versions need to
> >> recompile everything, including pkgsrc apps?
> >
> > This isn't acceptable IMHO. libpthread.so wrapper should stay.
>
> If I recall correctly, _xu is the default on new installs, so the
> number of people who use/need c_r is declining over time.  At some
> point, people using the old library will have to stop and recompile,
> somehow, won't they?

It's default, but function implemented only in it can't be used by 
applications unless implemented also in libc_r. That's how our threading 
libraries switching works.

There is also the question how we should remove libc_r. Preserving the 
libpthread.so wrapper or not?


-- 
Hasso Tepper





More information about the Kernel mailing list