Release criteria for libkse -> libpthread switch?

[Robert Watson]

On Thu, 8 Jan 2004, Daniel Eischen wrote:

> > When we build packages, etc, that rely on threading, a library name is
> > built into each binary and library depending on it identifying the
> > dependency.  Currently, the packages built in the package cluster use
> > "libc_r" as the name to depend on for threads.  I think the right
> > long-term answer is for thread-dependent packages to simply link against
> > "libpthread".  People can rebuild locally to use something else, rename
> > libraries, or use libmap.conf to select alternatives.  What I don't want
> > to see happen is lots of binaries and libraries with conflicting
> > dependencies, and I want to avoid a lot of applications linking against a
> > name that will go away, be insufficiently supported, etc. 
> 
> Right, I think this is mostly solved by changing gcc -pthread to use
> -lpthread (at the same time as the libkse switchover) and changing the
> default PTHREAD_LIBS to -lpthread.  That gets you most of the way there,
> but there may still be ports that know about the existence of libc_r and
> pick that up as well.  I think we need a portbuild run to find possible
> offenders.  Perhaps you could remove libc_r from the system during the
> run to force those ports to fail. 

Sounds good.

> I think we resolved to keep -pthread and have it cause a link to -lc_r
> (and -lpthread after the switchover).  I'd like to noop -pthread when
> linking shared libraries (so you can have application A use libc_r,
> application B use libpthread, and both applications use libGL.so) but
> that could be up for discussion. 

Also sounds good.

> > Well, it means that we have to document, loudly and carefully somewhere,
> > that in the default configuration, gdb on threaded applications is no
> > longer supported...? 
> 
> The goal is to have gdb support for 5.3.

Sounds great :-).

> Other than debugging, sparc64 & alpha support, I think it already has
> more features than libc_r.  Judging by the last reaction I got when
> -pthread was removed, I'd suggest we first try to see how the switchover
> is going to affect ports.  Is Kris due back soon? 

I'm not sure what Kris's schedule is, but I agree that sparc64 and alpha
support sound like the last remaining piece.  I think we need to move
ahead with the default change for the rest of the platforms without
waiting for them, however.  I think it would be reasonable to throw the
switch once the press release is out the door for 5.2 (hopefully very
early next week). 

Has anyone experimented with profiling applications running KSE with
multiple CPUs in use?

Robert N M Watson             FreeBSD Core Team, TrustedBSD Projects
robert at fledge.watson.org      Senior Research Scientist, McAfee Research