Replacing glibc using linuxthreads for glibc using nptl (native positx thread library
 

Hi everyone

I built my LFS system using LFS 5 months ago. I've been enjoying the near-psychotic amount of effort I've put into it. No textbook could ever teach me as much about the internals of my linux system as using LFS full time ever could.

I recently started to do work more seriously on having Cedega work on my system. While the program runs, it always issues a warning about a 2052kb stack size limitation for my current pthread implementation.

Upon review of the transgaming forums, I found that Gentoo users suffer from the same problem. The instructions for those users have them re-emerge glibc using nptl, which is a much better threading implementation for POSIX threads.

My previous version of glibc was 2.3.2 using linuxthreads - I would like to move to using 2.3.3 with nptl. However, my own attempts to make this work have not succeeded.

I worked off this TLDP Howto for my instructions. I was able to generate my static versions of coreutils, bash and make, and do the initial make for glibc. To configure, I used:
This ran fine, and so did make.

After booting back into the minimal run state (by using "init=/bin/bash" and manually mounting my partitions), I sued to root and did the "make install" for glibc. At this point, I'm glad I made backups prior to my experiment.

All of my binaries save for the static binaries I had made previously gave me errors regarding relocation in ld-linux.so.2. I was able to successfully restore my previous state using my backups, but am now confused as to whether or not I can proceed. I was under the impression that moving from linuxthreads to nptl would leave me binary compatible, with a much more efficient threading implementation? Is this not the case, or am I missing some critical step?

did you install the previous glibc into /usr prefix? installing with "--prefix=/" would leave you with two conflicting glibc installs.

No, I've only found libc and libm showing up once, and that's under "/", not "/usr". Besides which, shouldn't libc be placed under /lib anyways? If libc isn't integral to being able to boot your system (my /usr is on a different partition), I don't know what is.

The next thing I'm going to try is static compiling my binutils as well, and seeing if doing an ldconfig will fix things (I'm still not quite sure about the specifics of dynamic shared object loading, so maybe this will fix things?)

thanks for the detailed post, I failed to get help on this stack size anywhere, and I ended up getting the solution this way..

there seems to be a problem with binutils-2.14's assembler while passing nptl as the threading library:
http://www.linuxquestions.org/questi...hreadid=216511

Anybody got a workaround other than using 2.15 instead of 2.14?