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