On Thu, Apr 26, 2012 at 11:53:14PM -0400, Mike Frysinger wrote: > this file is getting worse and worse. looking at the LFS logic, i don't see > the point in protecting most of that. when it comes to LFS support on 32bit > targets, we provide the knob to save size. but in this file, there's no > savings -- we just pick between two different numbers. > > further, i'm not quite sure why there is NPTL-specific logic. seems like the > cancellation stuff should be there for any pthread implementation.
I say this as something of an outsider/observer, but to me too this is really disheartening. A large portion of the activity on the mailing list these days seems to center on dealing with breakage and mess caused by #ifdef hell and the complexity of maintaining a huge number of switchable options (not to mention target archs) with subtle, often unnecessary interconnections between them. It's really frustrating to see how much effort is spent keeping (for example) LFS-on-32-bit optional (with the opportunity to save maybe 3-4k total), when MUCH BIGGER issues have gone completely unaddressed - for instance, the fact that giant locale init stuff gets pulled into static binaries whenever locale was enabled in the build system, even if setlocale() is never called (and similar for stdio, although it's less likely to find apps that don't use stdio). It would be great if uClibc could get stuff like that cleaned up, and get efficient (not just copied from glibc) implementations of newer POSIX features it's missing added. I hope this email doesn't come across as too much of a rant/flame. I want to see uClibc do well and get better, and just see it getting bogged down too much in mushrooming combinatorial complexity.. Rich _______________________________________________ uClibc mailing list [email protected] http://lists.busybox.net/mailman/listinfo/uclibc
