On Sat, Feb 14, 2009 at 05:00:06PM -0600, Rob Landley wrote:
>Svn 24052 is a poorly-defined patch mixes at least four seemingly unrelated 
>things:
>
>1) It adds UCLIBC_HAS_SSP support to various makefile  like nsl and libresolv.

r24955
>
>2) It uses #if 0/#endif to chop out a largeish portion of 
>include/sys/sysinfo.h (no idea why), and it adds 8 zillion #ifdef 
>__UCLIBC_LINUX_SPECIFIC__ things when linux is the only target uClibc has 
>historically _ever_ supported.

The target has nothing to do with that knob, just the API.

>3) It renames a local variable in libc/inet/ifaddrs.c:map_newlink() from 
>"index" to "idx".

r24025

>4) It adds and #ifdef __UCLIBC_LINUX_SPECIFIC__ to a lot of places that 
>already have a __USE_GNU.  Apparently, this needed a synonym.
>
>I'm confused why UCLIBC_LINUX_SPECIFIC exists in the first place since Linux 
>is the only platform uClibc has ever supported and you can't build the sucker 

This has nothing to do with the target platform but allows for removing linux
specific API hunks that are non-standard.

>without Linux kernel headers, but I guess it's just one more way of defining a 
>set of optional functionality to remove for size reasons.  But in this case, 
>it's adding stuff to _headers_ (making them larger, not removing any code from 
>the binary).
>
>I also note that the help for the config entry for UCLIBC_LINUX_SPECIFIC from 
>0.9.30 provides an explicit list of functions to be inexplicably removed: 
>fstatfs(), inotify_*(), ioperm(), iopl(), madvise(), modify_ldt(), 
>personality(), ppoll(), setresuid(), signalfd().  This presumably extends that 
>list (one of the few places it's not merely a synonym for __USE_GNU is where 
>it inexplicably chops out vhangup()), but this patch does not modify that help 
>entry.

Right, i've apparently forgotten to add them to the helptext, i'll add
them unless you beat me to it.
>
>This patch is a bugfix?  For _what_?

cleanness.
_______________________________________________
uClibc mailing list
[email protected]
http://lists.busybox.net/mailman/listinfo/uclibc

Reply via email to