RE: NGPT with 2.4.20

Saurabh Desai <[email protected]> Fri, 24 Jan 2003 16:34:41 -0600
Newsgroups gmane.linux.ngpt.user
Message-ID <[email protected]>




Dave,
      I also noticed the 'undefined reference to errno" build problem
on RH8.1 while building the NGPT. What I can see is, under glibc2.3.1,
the "extern int errno" from /usr/include/bits/errno.h is gone, so the
"errno"
is not visible outside the glibc code. In the Glibc, it's defined in the
sysdeps/generic/errno.c as (for the NON-tls case),
int errno __attribute__ ((section (".bss")));

So, I changed the "extern int errno" with above line in the ngpt's
pthread.c
and that seems working. I am not sure whether that's the right fix or not??

With the TLS support, the errno is defined as "__thread int errno" in
Glibc.

Also, by default none of the ngpt program will run on RH8.1 because it
uses TLS library and NGPT does not have support for it.
To run NGPT programs, you have to export the LD_ASSUME_KERNEL=2.2.5.

Thanks,
- - - - -
Saurabh Desai
POSIX Threading for Linux
IBM  Linux Technology Center
e-mail: [email protected] OR [email protected]
phone: 512-838-2655, T/L: 678-2655




"Howell, David P" <[email protected]>@www-124.ibm.com on 01/23/2003
10:55:25 AM

Sent by:    [email protected]


To:    Philipp <[email protected]>, [email protected]
cc:
Subject:    RE: [pthreads-users] NGPT with 2.4.20


Philipp,
See my comments mixed in below with [DPH].

Thanks,
Dave Howell

These are my opinions and not official opinions of Intel Corp.

David Howell
Intel Corporation
Telco Server Development
Server Products Division
Voice: (803) 461-6112  Fax: (803) 461-6292

Intel Corporation
Columbia Design Center, CBA-2
250 Berryhill Road, Suite 100
Columbia, SC 29210

[email protected]

      -----Original Message-----
      From: Philipp [mailto:[email protected]]
      Sent: Wednesday, January 22, 2003 9:33 AM
      To: [email protected]
      Subject: [pthreads-users] NGPT with 2.4.20

      Good Afternoon,


      today i searched the Mailinglist Archive for Information
      about NGPT with linux 2.4.20 because i couldnt find
      the appropriate path.
      i found some mails regarding this issue and found some
      advice to use 2.4.19 patch, too; but i didnt found any
      mails reporting success with this solution.

      is it safe to use this patch or will i have to make changes ?
      i dont think i am skilled enough to do changes to the kernel
      code by myself...
[DPH] The 2.4.19 patch installs with minor failures, as I recall. If
someone who does
          this successfully can contribute a patch for 2.4.20 we should
post it.

          BTW, the Red Hat 8.1 Beta (“Phoebe”) has all of the thread group
and futex
          changes in the distribution kernels and kernel-source rpm. It
uses the Red Hat
          kernel source for 2.4.20-2.2 plus their patches. Bad news is that
I am having
          problems getting ngpt-2.2.0 to build, creating the test APPs with
the ngpt lib
          I’m seeing ‘undefined reference to errno’, needs investigation.

      another question: when i install ngpt it will overwrite my old
      threating library, right (using debian woody at the moment)  ?

      what will happen when i reboot the system with unpatched
      kernel (lets say something went wrong with the new kernel
      and i have to boot an old one) ? will that totally fail or will
      i be able to at least restore the files ngpt replaced ?
[DPH] Out of the box NGPT overlays a minimum of Linuxthreads files, and can
          coexist with Linuxthreads for runtime; my experience is using RH
7.3/8.0.
          The Linuxthreads runtime is kept under /lib and /lib/i686, ngpt
installs under
          /usr/lib, no collisions. Compile/link files are overlayed, but if
you are building
          using the source tarball there is install/uninstall support to
save and put the
          Linuxthreads files back in place.

          So, booting an old kernel is not an issue unless you try to run
NGPT linked
          APPs which will fail, but the standard utilities on the system
will continue
          to work with the Linuxthreads runtime.

      Thank you very much,
      Philipp