[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

new in 2005-7-9 glibc: no more LinuxThreads



Tomorrows glibc will contain the last act of the LinuxThreads saga: its
total demise.  It's gone for good.

By the time FC5 will hit the street people had more than three years
time to adapt their code to NPTL.  In the last year we've hardly heard
about any problem related to LT vs NPTL and the F4 switch to default to
linking with NPTL also didn't cause any problems we know of.

So, that's it then.  LT is really gone for good.  It is not possible to
resurrect it as an optional add-on or so.  The trunk glibc used in
rawhide and FC5 is already diverging so that in a couple of days (when
we make our usual adjustments to the build environment) almost no
application will run with LT.

Another change caused by this is that it is not possible anymore to use
custom kernels which don't have NPTL support.  I.e., no kernels before
2.6 (or 2.4 with NPTL backport) can be used ever again.  I don't think
this should be a problem since nobody running such old kernels should
update the userlevel code but people do stupid things so I thought I
mention it.

Those who really need LT for whatever reason have two options:

1. Don't update.  Or at least keep a FC4 partition around.

2. Use Xen with a FC4 guest domain.  For x86-64 and ppc this should also
   be possible in the not too distant future.


I hope everybody who's updating their FC installation from rawhide daily
is reading this.  It makes no sense whining about this here or anywhere
else.  LT is discontinued upstream, the same changes apply to all
distributions.  The good thing is that the spreading of misinformation
about LD_ASSUME_KERNEL is coming to an end.  That envvar is still there
and can cause havoc but it cannot do anything useful anymore (for now).
 If somebody has scripts or macros which automatically set this envvar,
you better adjust all that code.

As usual, be careful with glibc updates.  Especially this one for the
aforementioned reasons and because implementing these changes required
substantial modification of the build process.  It's simpler now but
obviously not as well tested.

-- 
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖

Attachment: signature.asc
Description: OpenPGP digital signature


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]