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
