Re: Wrong definition of APR_OFF_T_FMT in apr.h

[William A Rowe Jr]

On Fri, Mar 15, 2019 at 7:04 PM Jim Jagielski  wrote:

> macOS is not truly BSD... it's mach and so while there are a lot of
> similarities, one cannot equate the 2... this just may be one of those
> areas where macOS/Mach != BSD
>

That's true.The point I raised is that without DARWIN defines, the
logic which wuzhouhui observed is likely the same as Stefan's report
based an actual BSD, with the very same error. APR configure is
making a wrong decision in both cases, except that with DARWIN
(now also derived from APPLE) we hide that wrong detection. No
issue with the fix, I think your patch is correct; but the underlying
defect needs to be fixed.

I'm going through the results of wuzhouhui's initial configure before
the overrides to see what I can glean what happened without any
config output from Stefan.

>From those files, we clearly have a 64LP environment where long
is the same as long long. There is no difference between %ld and
%lld, but clever compiler writers still treat the two types distinctly
when it comes to pointer indirection to avoid issues when long long
becomes a 128 bit, so they emit warnings appropriately. Testing
that the sizeof() matches long or long long isn't sufficient.

I'm working through the many many paths within configure.in logic
to change only the election between 'long' and 'long long' without
touching the many other paths through various int/undetected
and apr_int64_t which could change other platforms.

The biggest risk are incompatible binaries between 1.6 and 1.7
builds. The fix for APPLE clearly is one of these, but it is one that
we have to document in the release notes and move on, since
Apple dropped the DARWIN significator right out from under
developers and maintainers. I think we just warn that APR 1.6
or earlier built against new toolchains which dropped DARWIN
macros may be incompatible with any APR 1.6 and earlier
built with any toolchain that features the DARWIN macros and
any APR 1.7 or later.

Re: Wrong definition of APR_OFF_T_FMT in apr.h

[Jim Jagielski]

macOS is not truly BSD... it's mach and so while there are a lot of 
similarities, one cannot equate the 2... this just may be one of those areas 
where macOS/Mach != BSD

> On Mar 15, 2019, at 2:39 PM, William A Rowe Jr  wrote:
> 
> That's outstanding, thanks again for sharing your config! Thanks Jim for the 
> Apple fix.
> 
> Since we didn't see your environment as Darwin, it was treated as a generic 
> BSD. Which, still should have worked, but we clearly have a flaw on BSD 
> environments in general, as Stefan has reported.
> 
> Brings me back to the question, Stefan could you share your 
> config.log/config.status, and resulting app.h file, so I can diagnose the 
> misassumption here?
> 
> 
> 
> 
> On Fri, Mar 15, 2019, 06:44 wuzhouhui  > wrote:
> 
> > On Mar 15, 2019, at 8:02 AM, Jim Jagielski  wrote:
> > 
> > Yeppers. It's because gcc for Homebrew still sets DARWIN automatically 
> > whereas for clang (Xcode), the canon macro is now __APPLE__
> > 
> > I've updated all APR's to be aware of __APPLE__ and, if set, it auto 
> > defines DARWIN and DARWIN_10 in apr.h
> > 
> > This should fix the issues w/ all compilers.
> 
> I patch apr-1.6.5 with r1855560 that jim committed, and no warning produced.
> 

Re: Wrong definition of APR_OFF_T_FMT in apr.h

[wuzhouhui]

> On Mar 15, 2019, at 8:02 AM, Jim Jagielski  wrote:
> 
> Yeppers. It's because gcc for Homebrew still sets DARWIN automatically 
> whereas for clang (Xcode), the canon macro is now __APPLE__
> 
> I've updated all APR's to be aware of __APPLE__ and, if set, it auto defines 
> DARWIN and DARWIN_10 in apr.h
> 
> This should fix the issues w/ all compilers.

I patch apr-1.6.5 with r1855560 that jim committed, and no warning produced.

Re: Wrong definition of APR_OFF_T_FMT in apr.h

[wuzhouhui]

> On Mar 15, 2019, at 5:44 AM, William A Rowe Jr  wrote:
> 
> Jim, Stefan, wuzhouhui...
> 
> On Wed, Mar 13, 2019 at 3:13 PM Jim Jagielski  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  
> > > wrote:
> > >
> > > ~/Downloads/apr-1.6.5$ gcc -I./include a.c
> > > a.c:7:33: warning: format specifies type 'long' but the argument has type
> > >  '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 
> > > --with-gxx-include-dir=/Library/Developer/CommandLineTools/SDKs/MacOSX10.14.sdk/usr/include/c++/4.2.1
> > > 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?
I use gcc-8.3.0 to compile a.c, but no warning produced:

~/Downloads/apr-1.6.5$ gcc-8 --version
gcc-8 (Homebrew GCC 8.3.0) 8.3.0
Copyright (C) 2018 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

~/Downloads/apr-1.6.5$ /usr/local/bin/gcc-8 -I./include a.c
~/Downloads/apr-1.6.5$

> 
> 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
Put config.status and config.log inline is too long, and I'm not sure whether 
this
mailing list support attachment. Anyway, I attach config.status and config.log 
and
please remind me if you don't get them.

>  ./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.
> 
> Thanks,
> 
> Bill
> 
> 

Re: Wrong definition of APR_OFF_T_FMT in apr.h

[Jim Jagielski]

Yeppers. It's because gcc for Homebrew still sets DARWIN automatically whereas 
for clang (Xcode), the canon macro is now __APPLE__

I've updated all APR's to be aware of __APPLE__ and, if set, it auto defines 
DARWIN and DARWIN_10 in apr.h

This should fix the issues w/ all compilers.

Thx for the extra info!

> On Mar 14, 2019, at 7:49 PM, wuzhouhui  wrote:
> 
>> 
>> On Mar 15, 2019, at 5:44 AM, William A Rowe Jr  wrote:
>> 
>> Jim, Stefan, wuzhouhui...
>> 
>> On Wed, Mar 13, 2019 at 3:13 PM Jim Jagielski  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  wrote:
 
 ~/Downloads/apr-1.6.5$ gcc -I./include a.c
 a.c:7:33: warning: format specifies type 'long' but the argument has type
 '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 
 --with-gxx-include-dir=/Library/Developer/CommandLineTools/SDKs/MacOSX10.14.sdk/usr/include/c++/4.2.1
 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?
> I use gcc-8.3.0 to compile a.c, but no warning produced:
> 
> ~/Downloads/apr-1.6.5$ gcc-8 --version
> gcc-8 (Homebrew GCC 8.3.0) 8.3.0
> Copyright (C) 2018 Free Software Foundation, Inc.
> This is free software; see the source for copying conditions.  There is NO
> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
> 
> ~/Downloads/apr-1.6.5$ /usr/local/bin/gcc-8 -I./include a.c
> ~/Downloads/apr-1.6.5$
> 
>> 
>> 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
> Put config.status and config.log inline is too long, and I'm not sure whether 
> this
> mailing list support attachment. Anyway, I attach config.status and 
> config.log and
> please remind me if you don't get them.
> 
>> ./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.
>> 
>> Thanks,
>> 
>> Bill

Re: Wrong definition of APR_OFF_T_FMT in apr.h

[Jim Jagielski]

I think what is going on is that Apple recently changed from using the DARWIN 
pre-defined macro
to the __APPLE__. 

No doubt, this is causing issues if one doesn't include the right *.h files. 
Let me address this.

> On Mar 14, 2019, at 5:44 PM, William A Rowe Jr  wrote:
> 
> Jim, Stefan, wuzhouhui...
> 
> On Wed, Mar 13, 2019 at 3:13 PM Jim Jagielski  > 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  > > > wrote:
> > >
> > > ~/Downloads/apr-1.6.5$ gcc -I./include a.c
> > > a.c:7:33: warning: format specifies type 'long' but the argument has type
> > >  '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 
> > > --with-gxx-include-dir=/Library/Developer/CommandLineTools/SDKs/MacOSX10.14.sdk/usr/include/c++/4.2.1
> > > 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.
> 
> Thanks,
> 
> Bill
> 
> 

Re: Wrong definition of APR_OFF_T_FMT in apr.h

[William A Rowe Jr]

Jim, Stefan, wuzhouhui...

On Wed, Mar 13, 2019 at 3:13 PM Jim Jagielski  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 
wrote:
> >
> > ~/Downloads/apr-1.6.5$ gcc -I./include a.c
> > a.c:7:33: warning: format specifies type 'long' but the argument has
type
> >  '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
--with-gxx-include-dir=/Library/Developer/CommandLineTools/SDKs/MacOSX10.14.sdk/usr/include/c++/4.2.1
> > 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.

Thanks,

Bill

Re: Wrong definition of APR_OFF_T_FMT in apr.h

[Jim Jagielski]

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  wrote:
> 
> Hi,
> 
> I found a compile warning in APR, following is a C program that will 
> report warning when compiled in my system:
> 
> ~/Downloads/apr-1.6.5$ cat a.c
> #include 
> #include 
> 
> int main(void)
> {
>apr_off_t a = 0;
>printf("%" APR_OFF_T_FMT "\n", a);
>return(0);
> }
> ~/Downloads/apr-1.6.5$ gcc -I./include a.c
> a.c:7:33: warning: format specifies type 'long' but the argument has type
>  'apr_off_t' (aka 'long long') [-Wformat]
>printf("%" APR_OFF_T_FMT "\n", a);
>~~~^
> 1 warning generated.
> 
> I checked apr.h and found it define APR_OFF_T_FMT as "ld" because macro
> DARWIN_10 is not defined.
> 
> APR version: 1.6.5
> 
> 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
> 
> Outputs of `gcc --version`:
> Configured with: --prefix=/Library/Developer/CommandLineTools/usr 
> --with-gxx-include-dir=/Library/Developer/CommandLineTools/SDKs/MacOSX10.14.sdk/usr/include/c++/4.2.1
> 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 
>