On Fri, Mar 15, 2019 at 7:04 PM Jim Jagielski <j...@jagunet.com> 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.
