Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 70255 - New nptlonly useflag in glibc breaks expected behaviour
Summary: New nptlonly useflag in glibc breaks expected behaviour
Status: RESOLVED WONTFIX
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: [OLD] Core system (show other bugs)
Hardware: All All
: High minor (vote)
Assignee: Gentoo Toolchain Maintainers
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2004-11-06 05:20 UTC by Daniel Thaler
Modified: 2004-11-06 16:21 UTC (History)
0 users

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Daniel Thaler 2004-11-06 05:20:05 UTC
People who have 'nptl' set will not be delighted to find they suddenly have linuxthreads libs on their system. Especially if the system has never had and therefore does not need linuxthreads.
Please rename the flag to "linuxthreads-too" and change its function accordingly, so that people can safely emerge world without being hit by this ... "feature" ...
Comment 1 Travis Tilley (RETIRED) gentoo-dev 2004-11-06 14:01:17 UTC
i have the ebuild beep furiously with a nice long warning about this. and technically the 'expected' behavior is exactly what it does now, as this is what most other nptl-using dists do. the behavior is hard-coded into glibc itself to check /lib/tls/ first and use the nptl libs there if they exist and LD_ASSUME_KERNEL isnt set to <2.6.0.
Comment 2 Daniel Thaler 2004-11-06 16:21:22 UTC
Beep eh? I never heard that, I don't have CONFIG_INPUT_PCSPKR in my kernel :-P

"Expected" behaviour, AFAIC is what it was when I set my useflags...

And finally: I think this is a step backwards, after all why have linuxthreads when you've compiled everything against nptl already?

But, frankly, I could care less now that  I _do_ have nptlonly in my useflags (and other people hopefully _will_ hear the beep ...)