[PATCH] support kernels without __ARCH_WANT_SYSCALL_OFF_T
dalias at aerifal.cx
Fri Apr 27 05:00:44 UTC 2012
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
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..
More information about the uClibc