[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