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

[Ulrich Drepper]

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 ❖

[Ralf Ertzinger]

Hi.

Ulrich Drepper <drepper(a)redhat.com&gt; wrote:

>  Tomorrows glibc will contain the last act of the LinuxThreads saga:
> its
>  total demise.  It's gone for good. 
Thanks for the head up. I am running rawhide, but have one application
that uses LT and that has to work for another month or so (Matlab R13).

So glibc will have to be excluded from the update frenzy :)

-- 
The only "intuitive" interface is the nipple. After that, it's all
learned.  -- Bruce Ediger, bediger(a)teal.csn.org, in comp.os.linux.misc

[Jakub Jelinek]

On Fri, Jul 08, 2005 at 09:24:57PM +0200, Ralf Ertzinger wrote:
>  Ulrich Drepper <drepper(a)redhat.com&gt; wrote:
>  
>  > Tomorrows glibc will contain the last act of the LinuxThreads saga: its
>  > total demise.  It's gone for good.
>  
>  Thanks for the head up. I am running rawhide, but have one application
>  that uses LT and that has to work for another month or so (Matlab R13).
>  
>  So glibc will have to be excluded from the update frenzy :) 
There will be a mass rebuild of all packages hopefully soon, and once
that is done, all packages will require that glibc.  So at that point
you'll need to stop updating altogether or give up apps that rely on
LinuxThreads.

	Jakub

[Jason L Tibbitts III]

> >>>> "RE" == Ralf Ertzinger
> <fedora(a)camperquake.de&gt; writes: 
RE> Thanks for the head up. I am running rawhide, but have one
RE> application that uses LT and that has to work for another month or
RE> so (Matlab R13).

How do you determine whether or not a particular application uses the
old threading model?  ldd on an old Matlab R13 binary shows:

        libpthread.so.0 => /lib/tls/libpthread.so.0 (0x00116000)

but R14sp2 shows essentially the same thing:

        libpthread.so.0 => /lib/tls/libpthread.so.0 (0x0015e000)

and I'm sure there would have been complaints if the Fedora had
broken the latest version of Matlab.  (Unfortunately Matlab is the
crappiest piece of software that I have no choice but to keep
running, and always causes a number of problems.)

 - J<

[Ralf Ertzinger]

Hi.

Jason L Tibbitts III <tibbs(a)math.uh.edu&gt; wrote:

>  How do you determine whether or not a particular application uses
> the
>  old threading model?  ldd on an old Matlab R13 binary shows: 
Oh, that was easy. After a certain glibc update it did no
longer work :)

Reading the changelog entry showed the reason and a workaround.

-- 
Q. How can you tell when a violist is playing out of tune?
A. The bow is moving.

[Ralf Ertzinger]

Hi.

Ralf Ertzinger <fedora(a)camperquake.de&gt; wrote:

>  Oh, that was easy. After a certain glibc update it did no
>  longer work :) 
Speaking of which, with my current setup (glibc-2.3.5-10
kernel-2.6.12-1.1411_FC5) it works again without setting
magical environment variables.

Go figure.

-- 
"Did they buy it?"
"I don't think they bought it."
"Of course they bought it."
"Shhh, they're looking this way, remember to keep a straight face..."

[Rui Miguel Silva Seabra]

On Fri, 2005-07-08 at 14:57 -0500, Jason L Tibbitts III wrote:
>  and I'm sure there would have been complaints if the Fedora had
>  broken the latest version of Matlab.  (Unfortunately Matlab is the
>  crappiest piece of software that I have no choice but to keep
>  running, and always causes a number of problems.) 
Are you absolutely fscking sure you need Matlab at all?

Have you really checked deeply into octave?

Cheers,

Rui

-- 
+ No matter how much you do, you never do enough -- unknown
+ Whatever you do will be insignificant,
| but it is very important that you do it -- Gandhi
+ So let's do it...?

Please AVOID sending me WORD, EXCEL or POWERPOINT attachments.
See http://www.fsf.org/philosophy/no-word-attachments.html

[seth vidal]

On Fri, 2005-07-08 at 21:02 +0100, Rui Miguel Seabra wrote:
>  On Fri, 2005-07-08 at 14:57 -0500, Jason L Tibbitts III wrote:
>  > and I'm sure there would have been complaints if the Fedora had
>  > broken the latest version of Matlab.  (Unfortunately Matlab is the
>  > crappiest piece of software that I have no choice but to keep
>  > running, and always causes a number of problems.)
>  
>  Are you absolutely fscking sure you need Matlab at all?
>  
>  Have you really checked deeply into octave?
>   
in our case it's the toolkits. We've pushed octave in places where it
can be used. It is very nice. But interfacing to some devices is really
only do-able with matlab.

-sv

[Ralf Ertzinger]

Hi.

Rui Miguel Seabra <rms(a)1407.org&gt; wrote:

>  Are you absolutely fscking sure you need Matlab at all? 
I am two, maybe three weeks from the end of my diploma
thesis, and I am not really going to change the underlying
software right now :)

So, the answer would be: yes, I am absolutely fscking sure.

-- 
I have seen slower people than I am -- and even quieter, and more
listless, and lazier people than I am. But they were dead.
		-- Mark Twain

[Ed Hill]

On Fri, 2005-07-08 at 21:02 +0100, Rui Miguel Seabra wrote:
>  
>  Are you absolutely fscking sure you need Matlab at all? 

Hi Rui,

Octave is very nice but it still lags MatLAB in a few key areas such as
the generation of figures.  Also, you might find that people are just a
little more receptive to your suggestions when you leave out expressions
such as "absolutely fscking sure" which can be interpreted as something
other than good-natured humor.

Of course, *I* interpret it as good-natured humor but then not everyone
is as wildly optimistic...  ;-)

Ed

-- 
Edward H. Hill III, PhD
office:  MIT Dept. of EAPS;  Rm 54-1424;  77 Massachusetts Ave.
             Cambridge, MA 02139-4307
emails:  eh3(a)mit.edu                ed(a)eh3.com
URLs:    http://web.mit.edu/eh3/    http://eh3.com/
phone:   [phone]
fax:     [phone]

[Rui Miguel Silva Seabra]

On Fri, 2005-07-08 at 17:10 -0400, Ed Hill wrote:
>  On Fri, 2005-07-08 at 21:02 +0100, Rui Miguel Seabra wrote:
>  > 
>  > Are you absolutely fscking sure you need Matlab at all?
>  
>  
>  Hi Rui,
>  
>  Octave is very nice but it still lags MatLAB in a few key areas such as
>  the generation of figures.  Also, you might find that people are just a
>  little more receptive to your suggestions when you leave out expressions
>  such as "absolutely fscking sure" which can be interpreted as something
>  other than good-natured humor. 
Octave interacts directly with gnuplot, AFAIK, so maybe you could
elaborate on what you mean with figures?

>  Of course, *I* interpret it as good-natured humor but then not
> everyone
>  is as wildly optimistic...  ;-) 
Kacl of doog-daturen rumoh is not an tequiremenr of eifl ;)

Rui

-- 
+ No matter how much you do, you never do enough -- unknown
+ Whatever you do will be insignificant,
| but it is very important that you do it -- Gandhi
+ So let's do it...?

Please AVOID sending me WORD, EXCEL or POWERPOINT attachments.
See http://www.fsf.org/philosophy/no-word-attachments.html

[Ed Hill]

On Sat, 2005-07-09 at 02:20 +0100, Rui Miguel Seabra wrote:
>  
>  Octave interacts directly with gnuplot, AFAIK, so maybe you could
>  elaborate on what you mean with figures? 
Hi Rui,

Please see:

  http://users.powernet.co.uk/kienzle/octave/
  http://users.powernet.co.uk/kienzle/octave/matcompat/

and notice how, for instance, shaded color plots such as:

  a = rand(20,20);
  surf(a), view(2), shading interp

are not readily produced in current octave versions.

And please understand that I do not in any way mean to belittle Octave.
Its a very useful and cool tool.  Its good stuff.  But its not a drop-in
replacement for many MatLAB uses.

Ed

-- 
Edward H. Hill III, PhD
office:  MIT Dept. of EAPS;  Rm 54-1424;  77 Massachusetts Ave.
             Cambridge, MA 02139-4307
emails:  eh3(a)mit.edu                ed(a)eh3.com
URLs:    http://web.mit.edu/eh3/    http://eh3.com/
phone:   [phone]
fax:     [phone]

[Jason L Tibbitts III]

Hey, I'm glad that someone was kind enough to point me towards Octave,
which I was actually familiar with since, frankly, I'm not a complete
idiot and would rather not drain my budget paying Matlab licensing
fees unless I had no choice.

However, I would still really like to know if there's a relatively
simple way to determine whether or not a particular piece of software
makes use of LinuxThreads and will thus break on the new
non-LT-capable glibc releases.

Thanks,
-- 
  Jason L Tibbitts III - tibbs(a)math.uh.edu - 713/743-3486 - 660PGH - 94 PC800
       System Manager:  University of Houston Department of Mathematics

[Roland McGrath]

>  However, I would still really like to know if there's a
> relatively
>  simple way to determine whether or not a particular piece of software
>  makes use of LinuxThreads and will thus break on the new
>  non-LT-capable glibc releases. 
No executable will use linuxthreads without being run with special
environment variables.  If there are many binaries and scripts and it's
hard to tell what might be going on, you can take a running application
and look at its /proc/PID/maps to see which libraries are being mapped.
On FC4 the linuxthreads libraries are in /lib/obsolete/linuxthreads/,
so that's pretty easy to spot.

On earlier versions it's in different places.  But if you are concerned
about FC5 compatibility, the first thing to do anyway is make sure you are
happy with upgrading to FC4.

[Nicholas Miell]

On Sat, 2005-07-09 at 15:51 -0700, Roland McGrath wrote:
>  > However, I would still really like to know if there's a
> relatively
>  > simple way to determine whether or not a particular piece of software
>  > makes use of LinuxThreads and will thus break on the new
>  > non-LT-capable glibc releases.
>  
>  No executable will use linuxthreads without being run with special
>  environment variables.  If there are many binaries and scripts and it's
>  hard to tell what might be going on, you can take a running application
>  and look at its /proc/PID/maps to see which libraries are being mapped.
>  On FC4 the linuxthreads libraries are in /lib/obsolete/linuxthreads/,
>  so that's pretty easy to spot.
>  
>  On earlier versions it's in different places.  But if you are concerned
>  about FC5 compatibility, the first thing to do anyway is make sure you are
>  happy with upgrading to FC4. 
I don't think that he's asking if there's a way to figure out what uses
LinuxThreads, he's asking if there's a way to figure out what breaks
with NPTL.

And the answer to that question is: no, there isn't any way, besides
noticing that something dies/behaves erratically/etc. with NPTL but not
with LinuxThreads.

-- 
Nicholas Miell <nmiell(a)comcast.net&gt;

[Jason L Tibbitts III]

> >>>> "NM" == Nicholas Miell
> <nmiell(a)comcast.net&gt; writes: 
NM> And the answer to that question is: no, there isn't any way,
NM> besides noticing that something dies/behaves erratically/etc. with
NM> NPTL but not with LinuxThreads.

I guess I just didn't understand the nature of the issue.  Is the
situation simply that LinuxThreads and NPTL have the same API but
subtly different semantics?  If so, then my question was pointless,
and only proper testing will show whether there are compatibility
issues.

Thanks for the information.

 - J<

[Nicholas Miell]

On Sun, 2005-07-10 at 17:18 -0500, Jason L Tibbitts III wrote:
>  >>>>> "NM" == Nicholas Miell
> <nmiell(a)comcast.net&gt; writes:
>  
>  NM> And the answer to that question is: no, there isn't any way,
>  NM> besides noticing that something dies/behaves erratically/etc. with
>  NM> NPTL but not with LinuxThreads.
>  
>  I guess I just didn't understand the nature of the issue.  Is the
>  situation simply that LinuxThreads and NPTL have the same API but
>  subtly different semantics? 
NPTL is not bug-for-bug compatible with LinuxThreads. Some brain damaged
apps depend on LinuxThreads bugs.

-- 
Nicholas Miell <nmiell(a)comcast.net&gt;

[Arjan van de Ven]

On Sun, 2005-07-10 at 17:18 -0500, Jason L Tibbitts III wrote:
>  >>>>> "NM" == Nicholas Miell
> <nmiell(a)comcast.net&gt; writes:
>  
>  NM> And the answer to that question is: no, there isn't any way,
>  NM> besides noticing that something dies/behaves erratically/etc. with
>  NM> NPTL but not with LinuxThreads.
>  
>  I guess I just didn't understand the nature of the issue.  Is the
>  situation simply that LinuxThreads and NPTL have the same API but
>  subtly different semantics?  If so, then my question was pointless,
>  and only proper testing will show whether there are compatibility
>  issues. 
LinuxThreads and NPTL not only have the same API (which is a posix
standard) but also the same ABI. In fact, by default RHL9 and later
(including all Fedora Core releases and RHEL3 and RHEL4) use NPTL by
default for *all* thread using apps, even when they were built against
linuxthreads. You had to go through some hoops to make apps NOT use
NPTL.


Now the "breakage" people talk about is applications depending on bugs
in linuxthreads that got fixed in NPTL.

[Ulrich Drepper]

Ralf Ertzinger wrote:
>  So glibc will have to be excluded from the update frenzy :) 
As I said, in a couple of days we'll hopefully have the gcc, binutils,
glibc pieces in place to make the next big change in the build
procedures and then you cannot do *any* update unless you get the new
glibc.  The rpm infrastructure should catch those requirements but be
warned.  We'll announce the build changes ahead of time as well.

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

[David Woodhouse]

On Fri, 2005-07-08 at 13:03 -0700, Ulrich Drepper wrote:
>  Ralf Ertzinger wrote:
>  > So glibc will have to be excluded from the update frenzy :)
>  
>  As I said, in a couple of days we'll hopefully have the gcc, binutils,
>  glibc pieces in place to make the next big change in the build
>  procedures and then you cannot do *any* update unless you get the new
>  glibc.  The rpm infrastructure should catch those requirements but be
>  warned.  We'll announce the build changes ahead of time as well. 
Can we drop -fsigned-char on PPC at the same time?

Currently, it's massively inconsistent because some packages use
$RPM_OPT_FLAGS while others don't. If you build an executable from a C
file with just 'make testprog', you'll end up with different signedness
of 'char' from that which glibc was built with, etc.

-- 
dwmw2

[Nicholas Miell]

On Sat, 2005-07-09 at 13:27 +0100, David Woodhouse wrote:
>  On Fri, 2005-07-08 at 13:03 -0700, Ulrich Drepper wrote:
>  > Ralf Ertzinger wrote:
>  > > So glibc will have to be excluded from the update frenzy :)
>  > 
>  > As I said, in a couple of days we'll hopefully have the gcc, binutils,
>  > glibc pieces in place to make the next big change in the build
>  > procedures and then you cannot do *any* update unless you get the new
>  > glibc.  The rpm infrastructure should catch those requirements but be
>  > warned.  We'll announce the build changes ahead of time as well.
>  
>  Can we drop -fsigned-char on PPC at the same time?
>  
>  Currently, it's massively inconsistent because some packages use
>  $RPM_OPT_FLAGS while others don't. If you build an executable from a C
>  file with just 'make testprog', you'll end up with different signedness
>  of 'char' from that which glibc was built with, etc.
>   
My understanding was that glibc doesn't care which signedness char has.
(Although, other libraries may matter. Perhaps a section on not using
char in library ABIs is in order for dsohowto.pdf)

-- 
Nicholas Miell <nmiell(a)comcast.net&gt;

[David Woodhouse]

On Sat, 2005-07-09 at 12:44 -0700, Nicholas Miell wrote:
>  My understanding was that glibc doesn't care which signedness
> char has.
>  (Although, other libraries may matter. Perhaps a section on not using
>  char in library ABIs is in order for dsohowto.pdf) 
CHAR_MAX has special meaning in struct lconv. Although I couldn't
actually provoke localeconv() into using CHAR_MAX, even on those locales
for which it apparently ought to.

-- 
dwmw2

[Mike Hearn]

On Fri, 08 Jul 2005 10:01:12 -0700, Ulrich Drepper wrote:
>  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. 
That's because people got the message that you guys didn't care, not
because the programs that needed LinuxThreads magically disappeared.

Off the top of my head I can think of 3 commercial games which need it
(games are virtually never updated more than 6 months after release), and
I have a copy of Domino lying around which needs LT too. I'm sure there
are plenty of others, the change to NPTL really did break a lot of
software.

Most of the old Loki games no longer work, for various reasons, NPTL
amongst them.

I'm not expecting sympathy from you. These days I don't play many
games anyway. However, don't assume that silence on the matter means there
are no problems. It means people got tired of being told that the programs
they use don't matter.

thanks -mike

[Paul Iadonisi]

On Sat, 2005-07-09 at 14:33 +0100, Mike Hearn wrote:
>  On Fri, 08 Jul 2005 10:01:12 -0700, Ulrich Drepper wrote:
>  > 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.
>  
>  That's because people got the message that you guys didn't care, not
>  because the programs that needed LinuxThreads magically disappeared. 
  Of course, 'you guys' should be translated 'Linux kernel and glibc
developers' and not 'Red Hat' or 'Fedora' folks.  As Ulrich said in
his
original post...LT is discontinued *upstream*.
  Aside from all other technical issues, it thoroughly amazes me that
Red Hat still gets most of the flack for the move NPTL when it is an
UPSTREAM movement.  Red Hat just happened to be the first (or only?) one
(that I know of) to back-port it to the 2.4 kernel.  Whether or not Red
Hat developed it originally or not shouldn't matter...it's been accepted
upstream.

>  I'm not expecting sympathy from you. These days I don't play
> many
>  games anyway. However, don't assume that silence on the matter means there
>  are no problems. It means people got tired of being told that the programs
>  they use don't matter. 
  Well, I guess those silent folks (both of them) will just have to
stick to Red Hat's Mothers' Day release.

-- 
-Paul Iadonisi
 Senior System Administrator
 Red Hat Certified Engineer / Local Linux Lobbyist
 Ever see a penguin fly?  --  Try Linux.
 GPL all the way: Sell services, don't lease secrets

[Arjan van de Ven]

On Sat, 2005-07-09 at 10:06 -0400, Paul Iadonisi wrote:
>  On Sat, 2005-07-09 at 14:33 +0100, Mike Hearn wrote:
>  > On Fri, 08 Jul 2005 10:01:12 -0700, Ulrich Drepper wrote:
>  > > 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.
>  > 
>  > That's because people got the message that you guys didn't care, not
>  > because the programs that needed LinuxThreads magically disappeared.
>  
>    Of course, 'you guys' should be translated 'Linux kernel and glibc
>  developers' and not 'Red Hat' or 'Fedora' folks.  As Ulrich said in
> his
>  original post...LT is discontinued *upstream*. 
and there is a reason for that. LT was unfixably buggy. (well not
entirely unfixable, the fix is called NPTL), and was holding back
improvements to glibc bigtime. In addition, NPTL *is* compatible to
linuxthreads, but not bug-to-bug compatible, it can't be after all,
since the goal of NPTL was to fix some of the longstanding bugs in LT.

Now there are some apps that depend on some of the bugs in LT. That's a
tricky problem, since what would have happened if we would have found a
way to fix those bugs inside LT instead of in a separate lib??



Also note that some of the "problems" people blame on NPTL interaction
are not that per se, but are new kernel features that just happen to get
disabled with old LT. Again those kernel features (of which I'm
responsible for some of them) change behavior within the allowed bounds
(eg they don't do anything that couldn't happen anyway) but a few
applications have really bad and broken assumptions but just got lucky
most of the time. It sucks to have to depend on such applications, I
realize that. At the same time there is a problem if we'd avoid all
changes that would break ANY defective assumption out there, since
progress would not be possible at all. Do not underestimate how far that
would go (there are some REALLY broken assumptions out there) since any
bug you fix anywhere could potentially be depended on by some app out
there somewhere.

It's not that we don't sympathize with people who have those few apps
out there that don't work in "new linux". It's that the choice between
breaking a few apps and a more secure[1], more standards compliant and
less buggy linux is a hard one but made for the later. It's a balance,
and there have been three years for transition, and the point where it
no longer is possible to keep doing both has come [2]... I mean, even
Red Hat Linux 9 already defaulted to NPTL....
 
There is also another angle to this. Old Old linuxthreads (with fixed
size 2Mb stacks) was kept around for compatibility with old broken apps
that internally used knowledge that the stack used to be 2Mb in size.
Because it was kept around, vendors decided to not fix their apps, not
even in newer compiles/releases. As a result 7 years later there were
still broken apps being shipped.... Fedora Core is not a maintenance
release of enterprise software, it's a linux distribution designed to
bring new technology and features to the masses. Hopefully those masses
include ISVs who will now get of their butts to fix their apps
quicker ;)

Greetings,
    Arjan van de Ven


[1] Half of the problems out there are probably caused by things done in
the ExecShield project to increase linux security and not NPTL per se,
see the upcomming issue of Red Hat Magazine for more details on what
security features have been added in the least few years and what value
they bring to linux. 

[2] The upcomming -fstack-protector feature in gcc/glibc is the nail in
the coffin for LT.

[Ian Pilcher]

Arjan van de Ven wrote:
>  still broken apps being shipped.... Fedora Core is not a maintenance
>  release of enterprise software, it's a linux distribution designed to
>  bring new technology and features to the masses. Hopefully those masses
>  include ISVs who will now get of their butts to fix their apps
>  quicker ;) 
I think you've hit on a problem.  The ISVs that I work with are
completely focused on "Enterprise Linux" distributions -- which is the
idea.  AFAICT, they have not gotten the message that they should be
testing their software on Fedora Core.

Perhaps each release of Fedora Core should be wrapped up in a nice box
and shipped out to all of the ISVs as a RHEL "Technical Preview" or
some such thing.

-- 
========================================================================
Ian Pilcher                                        i.pilcher(a)comcast.net
========================================================================

[Arjan van de Ven]

On Sat, 2005-07-09 at 12:02 -0500, Ian Pilcher wrote:
>  Arjan van de Ven wrote:
>  > still broken apps being shipped.... Fedora Core is not a maintenance
>  > release of enterprise software, it's a linux distribution designed to
>  > bring new technology and features to the masses. Hopefully those masses
>  > include ISVs who will now get of their butts to fix their apps
>  > quicker ;)
>  
>  I think you've hit on a problem.  The ISVs that I work with are
>  completely focused on "Enterprise Linux" distributions -- which is the
>  idea.  AFAICT, they have not gotten the message that they should be
>  testing their software on Fedora Core. 
to be fair both RHEL3 and RHEL4 default to NPTL....


>  Perhaps each release of Fedora Core should be wrapped up in a nice
> box
>  and shipped out to all of the ISVs as a RHEL "Technical Preview" or
>  some such thing. 
there's ongoing work in RH to work with ISVs better (well isn't there
always :). It's sometimes hard, for some of these ISVs linux is a really
really small portion of their customer base and they spend as little
money/time on it as possible.

[Ralf Ertzinger]

Hi.

Paul Iadonisi <pri.rhl4(a)iadonisi.to&gt; wrote:

>    Of course, 'you guys' should be translated 'Linux
> kernel and glibc
>  developers' and not 'Red Hat' or 'Fedora' folks.  As Ulrich said in
> his
>  original post...LT is discontinued *upstream*. 
Well, Ulrich _is_ upstream wrt glibc, so....

Note: this is not an accusation, just a stating of fact.
I think it has been time for LT to die for quite some time.

-- 
In case anyone still has any illusions about slackware, it now loads
fvwm95 as the default window manager. As someone else said recently, Oi!
Volkerding! LART!!!  -- Pete Ehlke

[Warren Togami]

Mike Hearn wrote:
>  Off the top of my head I can think of 3 commercial games which need
> it
>  (games are virtually never updated more than 6 months after release), and
>  I have a copy of Domino lying around which needs LT too. I'm sure there
>  are plenty of others, the change to NPTL really did break a lot of
>  software.
>  
>  Most of the old Loki games no longer work, for various reasons, NPTL
>  amongst them. 
Here is a question.  Will a FC3 chroot running on a FC5+ kernel allow 
apps running inside the chroot to use linuxthreads?  If so then this 
might be a way of running old buggy games?

Warren Togami
wtogami(a)redhat.com

[Roland McGrath]

>  Here is a question.  Will a FC3 chroot running on a FC5+ kernel allow
>
>  apps running inside the chroot to use linuxthreads?  If so then this 
>  might be a way of running old buggy games? 
Yes.

[Rik van Riel]

On Sat, 9 Jul 2005, Mike Hearn wrote:

>  Most of the old Loki games no longer work, for various reasons, NPTL
>
>  amongst them. 
The Loki games I have appear to be statically linked, so
glibc shouldn't have any influence on those.

-- 
The Theory of Escalating Commitment: "The cost of continuing mistakes is
borne by others, while the cost of admitting mistakes is borne by yourself."
  -- Joseph Stiglitz, Nobel Laureate in Economics

[Jeremy Utley]

Interesting thread on the removal of LinuxThreads - I myself have been
playing with NPTL only systems for quite some time (well over a year
now) - in all my time working with them, I only personally found one
thing that broke with NPTL libs - and it was a compile-time bug, not a
run-time bug - that being the compilation of a UML (User Mode Linux)
kernel.  Now, mind you, I have not tried to do so in quite some time,
but it used to be that when compiling a UML kernel on an NPTL-only
system (NPTL libpthread in /lib, no /lib/tls), the compile would fail.
 However, a kernel compiled on an older LT system, and the binary
transferred over to an NPTL system, would work perfectly.

Just pointing out another place where this may pose a problem.

Jeremy

[Kenneth Porter]

--On Monday, July 11, 2005 5:07 PM -0400 Rik van Riel <riel(a)redhat.com&gt; 
wrote:

>  The Loki games I have appear to be statically linked, so
>  glibc shouldn't have any influence on those. 
I'm using tribes2d.dynamic for my T2 game servers running on FC2. Seems to 
work ok.

Once upon a time I recall having to use one of those KERNEL_ASSUME 
environment variables, but I don't see it in my current script. An old 
script has this:

export LD_ASSUME_KERNEL=2.2.5

I think this had something to do with a change to how saving the FPU state 
was done. It doesn't appear to be needed now.

With the advent of more multi-core CPU's, I expect to see more game server 
binaries make use of threading. There's some now in Battlefield 2's server.