[uClibc]Re: annoying warning message

Erik Andersen andersen at codepoet.org
Thu Feb 21 10:22:08 UTC 2002


On Thu Feb 21, 2002 at 06:01:27PM +0900, Miles Bader wrote:
> > Finally, if you want to continue this thread, please read and _understand_
> > what is going on in features.h and stdio.h before you reply.  That would
> > save _me_ some time... and annoyance.
> 
> Oh, please quit with the stupid petty insults; I understand very clearly
> what's going on.

Before we get much farther into this...  Lets step back for a
moment and look at the problem at hand.  We are all bright people
-- lets try and come up with solutions.

Manuel added those defines at my direction.  Becuase uClibc is
quite configurable, there were several bug reports coming in that
were the direct result of mismatches between uClibc configuration
and application expectations.  We decided to add a warning to
help people prevent these mismatches, and thereby reduce the
number of bug reports that _I_ inevitably end up dealing with.

Once the defines were in, I too was surprised when the warnings
were being triggered when compiling the uClibc pthreads library,
even though I have not yet added cancelation points for the large
file syscalls.  The pthreads library defines GNU_SOURCE, but does
not (yet) have any large file support.  So right in the uClibc
library itself, we have an example of what Miles is complaining
about -- a warning which is really a false positive.

Since we are all bright people, lets try to find a solution to
this problem that everyone can live with.  Lets start off by
clearly stating what the problem is:
    
    Applications which define _GNU_SOURCE are supposed to
    transparently have about 50 functions mysteriously get
    remapped to thier large file cousins.  uClibc may have large
    file support diabled.  When this happens, the non-large file
    functions are used, which will cause applications that depend
    on the remapping to break.   Other applications define
    _GNU_SOURCE for other reasone, and do not depend on the
    function remapping.

Right now, when GNU_SOURCE is defined, we use the __REDIRECT
macro from /usr/include/sys/cdefs.h to do the function prototype
munging.  The way this macro does the remapping (by creating an
asm alias) means that if, for example, fopen64 is missing, fopen
gets used instead.  Wouldn't it make more sense for use to change
__REDIRECT such that it does a #define when _GNU_SOURCE is
defined, so people will then see the error of their ways at link
time (when fopen64 turns up missing)?

 -Erik

--
Erik B. Andersen             http://codepoet-consulting.com/
--This message was written using 73% post-consumer electrons--



More information about the uClibc mailing list