pthreads, RH Ent3 and kernel 2.4.27

[marsd]

Using a vanilla kernel (2.4.27) on RH ent3. The reasons
for this can't be explained, but accept that it is needful
and unavoidable for the time being.
It seems like any multihreaded app utilizing pthreads
segfaults uncontrollably. I've also read of at least one
other case like mine with 2.4.26.

Any experience or theories? Mine is, considering
the experience I had recompiling from RH update sources
and watching the incredible output from gcc at
make_modules, that RH has purposefully broken certain
things, either in the name of greed or by optimizing
to the point of complete departure from the mainstream
open distributions.

 

[ericbrunson]

I think you're way off base. I've never had problems compiling with threads, "p" or otherwise. I don't have specific experience with the exact version of the kernel you're using, but I used 2.4.x for a long time. I am actually running 2.4.20 on a server happily executing several multi-threaded applications at this very moment.

 

[sedj]

I've also had no problems running apps that use pthread on RH9 and fedora core 1 & 2.

Click here to learn Ways to help with Tsunami Relief
--------------------------------------------------
Free Database Connection Pooling Software

http://www.primrose.org.uk

 

[ericbrunson]

It could be that your pthreads libraries are not compatible with your kernel version, or perhaps your glibc.

 

[marsd]

Hmm. I'll modify my initial post.
Only a couple of apps are affected...so far.
See this:

https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=122528

In response to everyone else, Thanks for the input but:
Kernel versioning makes no difference unless the
kernel is forked and heavily modified, as it is
with RH Enterprise solutions. Not RH9 or Fedora, etc,
afaik.
Glibc changes between 2.4.20 and 2.4.27?
Maybe I've been asleep, but I don't think so.

Also a major PITA is the fact that the upgrade src.rpms
for the kernel upgrade successfully builds bzImage(??)
but throw ridiculously careless errors on making modules
in module.h. It's senseless. RH 'X"3 is a supported
release for enterprise and should not behave this way.

Thanks to all, though. You've been helpful and
encouraged me to narrow down my search for the
problem.