1 |
...ok, not really, but the subject got your attention though, didnt it? :) |
2 |
|
3 |
we're a bit behind the times regarding nptl support. the latest -masked- |
4 |
glibc tries to correct this by changing the default behavior with |
5 |
USE=nptl to that of pretty much every other distribution out there: it |
6 |
builds glibc twice, once with and once without nptl. the nptl libs go |
7 |
into lib/tls where they belong and are used by default when using a 2.6 |
8 |
kernel and LD_ASSUME_KERNEL isnt set. when using a vanilla 2.4 kernel or |
9 |
LD_ASSUME_KERNEL=2.4.*, the non-nptl libs are used. (nptl purists can |
10 |
still set USE=nptlonly to revert to the old behavior) |
11 |
|
12 |
now currently the ebuild still requires 2.6 headers and kernel to |
13 |
compile nptl support. this is mostly because i cant even compile a 2.4 |
14 |
kernel anymore, and if i could it probably wouldnt have real support for |
15 |
my box... nptl could be made to build using suse's, fedora's, |
16 |
mandrake's, etc sanitized 2.4 headers. i would appreciate it if someone |
17 |
did the work for this. :) |
18 |
|
19 |
once an nptl-enabled glibc can be compiled without requiring 2.6 |
20 |
headers, it -may- start making sense to make nptl a default since even |
21 |
users stuck in 2.4-land would be able to use any nptl-enabled glibc |
22 |
binaries shipped in stage tarballs. |
23 |
|
24 |
just a thought. |
25 |
|
26 |
|
27 |
Travis Tilley |
28 |
Gentoo/AMD64 |
29 |
|
30 |
-- |
31 |
gentoo-dev@g.o mailing list |