Release criteria for libkse -> libpthread switch?

[Daniel Eischen]

On Wed, 7 Jan 2004, Robert Watson wrote:

> 
> On Wed, 7 Jan 2004, Craig Rodrigues wrote:
> 
> > > other than that the issue probably got addressed too late in the 5.2
> > > release process.  
> > 
> > Well 5.2 has branched, and let's assume that it will be released shortly
> > after the appropriate QA and bugfixing.  Are there any issues that would
> > prevent moving to KSE as the default on -current at this very moment,
> > since 5.2 is on its own branch? 
> 
> Agreed.  I think the waiting was to prevent 5-CURRENT from diverging too
> much from 5.2 before 5.2 is actually out, but I think now would be a fine
> time to do it if the other dependencies are met.
> 
> > > There are a number of running concerns, including: 
> > > 
> > > (1) Avoid building a binary library name dependency into all the pre-built
> > >     packages we distribute. 
> > 
> > Can you explain this?  I don't fully understand. 
> 
> 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.

> > > Also, resolve any lasting concerns about how
> > >     build processes should say "And I want threads, dammit".
> > 
> > This seems to be a point of debate, but it would be nice to resolve
> > this sooner rather than later.  My opinion is to do the following:
> > - move libkse to libpthread
> > - inform users that they must use -lpthread link in thread support
> > - remove -pthread in gcc (maybe deprecate it instead)
> > - fix the ports appropriately with PTHREAD_CFLAGS and PTHREAD_LDFLAGS 
> 
> There seems to be continuing disagreement on the gcc -pthread thing; I
> don't really have much of an opinion on it, except that I think we should
> choose the path of least headache.  And that I suspect that path is to
> keep it around...  The one nice thing about dropping -pthread is it will
> force everyone to go out and update the ports, but that sounds like a
> technical solution to a social problem.  We could as easily take other
> paths visible only to ports developers in the cluster and shoot fewer
> users. 

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.
 
> > > (2) Have services like process debugging, profiling available and known
> > >     fully functional (or close). 
> > 
> > This stuff is good to have, but should the lack of it prevent moving
> > libkse -> libpthread?  It sounds like a lot of work.
> 
> 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.

> > > us are running KSE as our libc_r via libmap.conf on all our machines, and
> > > have been for many months, and it appears to hold up quite well :-).
> > > Resolving how best to declare threading support in binaries will also
> > > facilitate shipping the JDK linked against KSE.
> > 
> > I also use libkse via libmap.conf, and am happy with it.  I also agree
> > that having a KSE-friendly version of the JDK will be very important.
> > Are there any other ports that we should focus our efforts on in getting
> > KSE to work with?  httpd, mysql, ACE,....? 
> 
> That looks like a good starting list :-).  Apache2 + eviljava + mysql
> sounds like a killer combination with kse.
> 
> My leaning is we should throw the switch to libkse sooner rather than
> later to improve exposure, even though it's not quite feature complete. 
> It was basically an accident of timing and intent that we didn't get to
> the rename before 5.2.  For one thing, it will get applications to start
> linking against libpthread sooner.  However, if we're going to throw the
> switch, it would be good to know the features aren't far behind :-). 

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?