[uClibc]Unimplemented feature sets.

[Brian Stafford]

Hi all,

I've been compiling a number of programs against uClibc recently and I'm 
impressed by its quality so far.

I do, however, have an issue with the unimplemented features of the library.  
The problem is that the standard header files declare functions/variables that 
are not actually present in the library.  Although this is mostly harmless, it 
does confuse programs that use autoconf et al. to determine features present 
in the system.  The problem is this: autoconf correctly identifies the missing 
features by attempting to link against the library.  It then undefines the 
appropriate HAVE_XXX_FEATURE or whatever so that the program can supply the 
missing functions or variables.  What happens next is that the declarations or 
some macro definitions conflict with the uClibc headers and compilation 
fails.  Clearly the program being compiled is not at fault.  This scenario is 
my biggest single obstacle to the use of uClibc and I am reluctant to hack a 
program to compile against uClibc when the real solution is to fix uClibc..

It seems to me that the solution to this problem should be implemented through 
features.h.  This currently appears to be minimally different (as do all the 
headers) from the GNU libc ones.  I suggest that features.h is modified to 
define symbols to zero (or undefine them as appropriate) for the sets of 
unimplemented parts of the headers.  These can then be defined as required 
when versions of uClibc do actually implement the feature - only features.h 
needs to match the uClibc version.

The most elegant would be to enable features by Posix/XOpen/Unix98/whatever 
set and ensure that features.h always undefines the symbol for the 
unimplemented ones.  This would avoid having to modify headers other than 
features.h   uClibc development could concentrate on completing a standard 
feature set before moving on to the next one.  A less elegant solution would 
be to ifdef around the unimplemented parts of the headers with uClibc specific 
symbols and have features.h define them appropriately.  This approach might be 
useful if only part of an unimplemented standard feature set is required.

Obviously none of this is difficult to do but it will be a tedious process to 
complete.  I am happy to do this for the parts of the library that have been 
problematic to me, however I doubt I will have the time to do a complete job.  
I would also like to be assured that any changes will make their way into the 
distribution in time.  Would anyone like to coordinate on this task?

Brian Stafford