+++ This bug was initially created as a clone of Bug #1583854 +++

In bug 1475652 I tried to build recent mozilla-central on macOS using the 10.15 SDK but failed. Apparently this is something that should work as of bug 1583854, so filing this issue to track/fix the failure.

My mozconfig:

. $topsrcdir/browser/config/mozconfig

mk_add_options MOZ_OBJDIR=@TOPSRCDIR@/obj-host-debugopt
mk_add_options AUTOCLOBBER=1

ac_add_options --enable-warnings-as-errors
ac_add_options --enable-debug
ac_add_options --enable-tests
ac_add_options --enable-optimize
ac_add_options --enable-ccache
ac_add_options --disable-crashreporter
# ac_add_options --disable-install-strip
ac_add_options --enable-dump-painting
ac_add_options --with-macos-sdk=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.15.sdk

export MOZ_RUN_GTEST=1
export ENABLE_CLANG_PLUGIN=1

Oh, and the build failure:

 0:12.83 /Users/kats/zspace/gecko-mac/memory/replace/logalloc/replay/Replay.cpp:332:18: error: 'aligned_alloc' is only available on macOS 10.15 or newer [-Werror,-Wunguarded-availability-new]
 0:12.83     aSlot.mPtr = ::aligned_alloc_impl(alignment, size);
 0:12.83                  ^~~~~~~~~~~~~~~~~~~~
 0:12.83 /Users/kats/zspace/gecko-mac/obj-host-debugopt/dist/include/malloc_decls.h:59:1: note: 'aligned_alloc' has been marked as being introduced in macOS 10.15 here, but the deployment target is macOS 10.9.0
 0:12.83 NOTHROW_MALLOC_DECL(aligned_alloc, void*, size_t, size_t)
 0:12.83 ^
 0:12.83 /Users/kats/zspace/gecko-mac/obj-host-debugopt/dist/include/malloc_decls.h:44:33: note: expanded from macro 'NOTHROW_MALLOC_DECL'
 0:12.83 #    define NOTHROW_MALLOC_DECL MALLOC_DECL
 0:12.83                                 ^
 0:12.83 /Users/kats/zspace/gecko-mac/memory/replace/logalloc/replay/Replay.cpp:256:15: note: expanded from macro 'MALLOC_DECL'
 0:12.83   return_type name##_impl(__VA_ARGS__);
 0:12.83               ^
 0:12.83 <scratch space>:18:1: note: expanded from here
 0:12.83 aligned_alloc_impl
 0:12.83 ^
 0:12.83 /Users/kats/zspace/gecko-mac/obj-host-debugopt/dist/include/mozmemory_wrap.h:140:47: note: expanded from macro 'aligned_alloc_impl'
 0:12.83 #define aligned_alloc_impl mozmem_malloc_impl(aligned_alloc)
 0:12.83                                               ^
 0:12.83 /Users/kats/zspace/gecko-mac/memory/replace/logalloc/replay/Replay.cpp:332:18: note: enclose 'aligned_alloc' in a __builtin_available check to silence this warning
 0:12.83     aSlot.mPtr = ::aligned_alloc_impl(alignment, size);
 0:12.83                  ^~~~~~~~~~~~~~~~~~~~
 0:12.83 1 error generated.
 0:12.83 make[4]: *** [Replay.o] Error 1
 0:12.83 make[3]: *** [memory/replace/logalloc/replay/target-objects] Error 2
 0:12.83 make[3]: *** Waiting for unfinished jobs....
 0:13.84     Blocking waiting for file lock on package cache
 0:15.23     Blocking waiting for file lock on package cache
 0:16.45     Finished dev [optimized + debuginfo] target(s) in 4.80s
 0:17.51     Finished dev [optimized + debuginfo] target(s) in 5.85s
 0:17.71 make[2]: *** [compile] Error 2
 0:17.71 make[1]: *** [default] Error 2
 0:17.71 make: *** [build] Error 2
 0:17.72 351 compiler warnings present.

I guess based on the error message the problem is most likely that I'm trying to build on a host running macOS 10.14.6 using a 10.15 SDK.

(In reply to Kartikaya Gupta (email:kats@mozilla.com) from comment #2)

I guess based on the error message the problem is most likely that I'm trying to build on a host running macOS 10.14.6 using a 10.15 SDK.

Ah yes, that's not something that's expected (or guaranteed) to work.

Ok, so if we start requiring the 10.15 SDK that might break local builds for other people like me running older versions of macOS. I believe 10.14 is still supported by Apple. Do we have a policy with respect to this? Would I be expected to build against an older SDK in local builds the way I'm doing now, and then submit patches for breakage that isn't caught in automation?

Let's understand the error anyway. It does seem to have a point: If aligned_alloc really isn't available before 10.15, then we shouldn't be using it without a check. Glandium, do you know if the compiler's claim is true?

(In reply to Kartikaya Gupta (email:kats@mozilla.com) from comment #4)

Ok, so if we start requiring the 10.15 SDK that might break local builds for other people like me running older versions of macOS. I believe 10.14 is still supported by Apple. Do we have a policy with respect to this? Would I be expected to build against an older SDK in local builds the way I'm doing now, and then submit patches for breakage that isn't caught in automation?

I don't believe that we will require the 10.15 SDK for local builds and the policy will be similar to what we have now, just in reverse. Today, if local developers build with 10.14 locally but break our CI builds with the 10.11 SDK, developers are expected to submit a fix for the breakage. If developers are building with 10.14 locally but CI builds break when built with the 10.15 SDK, a similar fix will be expected. It is true that we can ask developers to build locally with the 10.11 SDK today and we may not have the same workaround when developers build on 10.14 and CI use the 10.15 SDK, but try builds should be able to alleviate some of the pain there.

(In reply to Markus Stange [:mstange] from comment #5)

Let's understand the error anyway. It does seem to have a point: If aligned_alloc really isn't available before 10.15, then we shouldn't be using it without a check. Glandium, do you know if the compiler's claim is true?

(forgot needinfo)

Does --enable-dump-painting (or something else in the mozconfig) enable logalloc? If so, that might explain why we don't typically see this build failure.

(In reply to Stephen A Pohl [:spohl] from comment #6)

It is true that we can ask developers to build locally with the 10.11 SDK today and we may not have the same workaround when developers build on 10.14 and CI use the 10.15 SDK

Yeah, this bit was my main concern, I guess. I normally build with the 10.11 SDK in local builds so I know what I'm building is the same as on CI. With 10.15 I won't be able to. I'll probably just end up upgrading macOS to 10.15 as well, but other people may not be able to for whatever reason.

(In reply to Kartikaya Gupta (email:kats@mozilla.com) from comment #9)

(In reply to Stephen A Pohl [:spohl] from comment #6)

It is true that we can ask developers to build locally with the 10.11 SDK today and we may not have the same workaround when developers build on 10.14 and CI use the 10.15 SDK

Yeah, this bit was my main concern, I guess. I normally build with the 10.11 SDK in local builds so I know what I'm building is the same as on CI. With 10.15 I won't be able to. I'll probably just end up upgrading macOS to 10.15 as well, but other people may not be able to for whatever reason.

Understood. In general, it is easier for people to upgrade to a new (free) version of macOS than to jump through all the hoops of finding/downloading/configuring the old 10.11 SDK today. This doesn't address the fact that some people intentionally want to stay on an older version of macOS of course, but the workflow should become easier for the majority of developers.