1 |
On Thursday 12 May 2005 08:58 am, Francesco Riosa wrote: |
2 |
> Mike Frysinger wrote: |
3 |
> >On Wednesday 11 May 2005 05:20 pm, Francesco Riosa wrote: |
4 |
> >>what we have: |
5 |
> >>At the moment have_NPTL is defined in eclass/eutils.eclass, it compile a |
6 |
> >>small test program to check if glibc have nptl support. |
7 |
> > |
8 |
> >hasnt this been outgrown ? people should `use nptl` now i think |
9 |
> |
10 |
> yes and no, |
11 |
> no, 2005.0 still default to -ntpl and -ntplonly |
12 |
> yes, it's used only by mono project ebuilds (grep has spoken) |
13 |
|
14 |
so what if 2005.0 defaults to -nptl and -nptlonly ? you're trying to decide |
15 |
if you should apply a nptl workaround or not ? USE=nptl makes sense |
16 |
|
17 |
if mono is the only thing [ab]using have_NPTL, then maybe i'll bug |
18 |
latexer/dotnet guys and see why they cant utilize USE=nptl |
19 |
|
20 |
> >>there are drawbacks on the use of getconfig (that come with glibc) ? |
21 |
> >>Maybe it's not supported from *libc ? |
22 |
> > |
23 |
> >well i'd point out that glibc is the only libc atm to implement NPTL ... |
24 |
> > but then i'd point out someone is working on it for uClibc ... |
25 |
> >-mike |
26 |
> |
27 |
> mmh ok, btw all variant of glibc had getconf ? |
28 |
|
29 |
uClibc isnt a 'glibc variant', but to answer your question, getconf is a |
30 |
glibc-ism |
31 |
-mike |
32 |
-- |
33 |
gentoo-dev@g.o mailing list |