Jim, Stefan, wuzhouhui...

On Wed, Mar 13, 2019 at 3:13 PM Jim Jagielski <j...@jagunet.com> wrote:
> FWIW, I have apr-1.6 here and cannot confirm the below. When compiling w/
httpd, DARWIN_10 is defined as required.
> > On Mar 3, 2019, at 9:26 AM, wuzhouhui <wuzhouhu...@mails.ucas.ac.cn>
> >
> > ~/Downloads/apr-1.6.5$ gcc -I./include a.c
> > a.c:7:33: warning: format specifies type 'long' but the argument has
> >      'apr_off_t' (aka 'long long') [-Wformat]
> >        printf("%" APR_OFF_T_FMT "\n", a);
> >                ~~~                    ^
> >
> > Outputs of `uname -a`:
> > Darwin wzhdeMacBook-Pro.local 18.2.0 Darwin Kernel Version 18.2.0: Mon
Nov 12 20:24:46 PST 2018; root:xnu-4903.231.4~2/RELEASE_X86_64 x86_64

Sounds like the same kernel...

> > Outputs of `gcc --version`:
> > Configured with: --prefix=/Library/Developer/CommandLineTools/usr
> > Apple LLVM version 10.0.0 (clang-1000.10.44.4)
> > Target: x86_64-apple-darwin18.2.0
> > Thread model: posix
> > InstalledDir: /Library/Developer/CommandLineTools/usr/bin

Seems like this is a quirk that has been fixed between clang-1000.10.44.4
and clang-1000.11.45.5? Could you possibly update and recheck, wuzhouhui?

So why would DARWIN_10 affect this? No indication that

Then I realized everyone reporting this is likely tripping over the
_FILE_OFFSET_BITS confusion inherent in normal vs LFS code. wuzhouhui's
example is a specific c snippet, Jim, did you test that specifically? I'm
going back over the entire logic that gets us to apr_off_t, because it was
very fragile in the first place.

I'd be very appreciative if each of you could send me your config.status
and config.log results from ./configure of apr 1.6.5 so I can see what is
miscalculated, where between the apr_int64_t and apr_off_t, on BSD and OSX.
Then look at what sort of horrible mess the apr.h.in leaves us with on
osx/darwin, given the zany exceptions listed there.



Reply via email to