[uClibc]Re: annoying warning message

Manuel Novoa III mjn3 at codepoet.org
Fri Feb 22 06:21:31 UTC 2002


Miles and Erik,

On Fri, Feb 22, 2002 at 11:45:40AM +0900, Miles Bader wrote:
> Erik Andersen <andersen at codepoet.org> writes:
> >     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.
> 
> I previously did think that _GNU_SOURCE caused some remapping.  However,
> I've now checked very, very carefully (I guess it's the one beneficial
> effect of flame wars :-), including compiling test programs to eliminate
> any confusion caused by nested #ifdefs, and in fact it _doesn't_.  In that
> sense, I guess Manuel was right -- I didn't fully understand things
> (although it seems like no one else did either).

Guilt as charged...  I was confusing the behavior of __USE_LARGEFILE with
that of __USE_FILE_OFFSET64.  It's quite humbling to think that I've
spent more than two months doing a complete rewrite of stdio for,
among other things, large file awareness in the core code, and _still_
made such a stupid mistake.  Well, they say pride goeth before a fall... 

Miles, please accept my apologies.

> Here's the summary:
> 
(analysis omitted)
> 
> So in fact, if the above is correct, all programs that need large-file
> support must either (A) define _FILE_OFFSET_BITS==64 -- in which case the
> existing #error will trigger if DO_LFS=false -- or (B) use one of the ...64
> functions -- in which case, they will fail at link time if DO_LFS=false.

Everything looks right to me too.  Thanks for taking the time to investigate
so thouroughly.

Manuel



More information about the uClibc mailing list