Homebrew-core: macOS 10.12 and Xcode 8.0 broken formulae

[DomT4]

Please don't try to use Xcode 7 on 10.12. Compiling almost anything will fail in fun ways. Install the Xcode 8 beta or the 8.x CLT package & ensure you've pointed sudo xcode-select --switch at either one.

Like Christmas, once a year a new operating system for Macs swings around... and like Christmas a bunch of toys get broken accidentally. This year's broken toys include:

Broken:

• Qt: https://gist.github.com/anonymous/e19027178831fd17d2e17a9bf65ead02 - Fails to find a header, which does still exist on 10.12, so a bit puzzling. We're migrating things to Qt5 any way, so Qt may not be supported by us on 10.12.
• haskell-stack: https://gist.github.com/8e005710eab17139c02267bac3029e33 - Confusing compiler error. Upstream report: https://ghc.haskell.org/trac/ghc/ticket/12198
• guile: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=23870 - more clock_gettime fun.

Upstream/Homebrew 10.12 support hacks:

• libgcrypt: https://gist.github.com/anonymous/5a60bffda24503a6f478c0c6baa2594a - make check dies, we saw something similar when El Cap came out so not a big surprise. Hacked a solution in https://github.com/Homebrew/homebrew-core/commit/831157188c6abd91bd63aa990a95ebc5edea2f18 temporarily.
• wxmac: https://github.com/Homebrew/homebrew-core/issues/1996, https://gist.github.com/anonymous/5d22977c76e44ffd920a99ba0ec061ec - --devel works, patch is too big to backport to stable.

Resolved:

• perl: https://gist.github.com/mistydemeo/37cb3474a09c51b7356683a31b41352b - Looks like another time bug. Has been patched in the formula.
• tor: https://gist.github.com/mistydemeo/6bc4f2fc724ee0c2b9ba86205c431aef - Another time-related bug, assumes another function is available if clock_gettime is. Upstream patch was merged into latest release.
• libevent: https://github.com/Homebrew/homebrew-core/issues/2869 - Marked fixed by upstream & patch backported to formula.
• go - Fixed by Go 1.7's release.

_Just so people are aware: Comments highlighting issues that turn out not to be actual formulae issues, i.e. user configuration problems, will be chopped after a couple of days to keep this thread from getting drowned._

[MikeMcQuaid]

I'd like to suggest we actively disable Qt on 10.12. There will be no way in hell upstream will officially support it and we're in the process of trying to kill it anyway.

[DomT4]

Agreed. That does effectively set a hard deadline on migrating across as much stuff to qt5 as we can before GM. It's not a difficult timetable, but will require a fair bit of work.

[jeregrine]

@DomT4 I have xcode7 installed I also have xcode-beta (xcode8) installed

[DomT4]

@jeregrine You probably need to sudo xcode-select --switch over to the beta Xcode & ensure the CLT (If you have them installed) are the 8.0 version. Xcode 7 will break almost everything on 10.12, pretty much.

[zhiayang]

since this appears to be a general issue thread, i'll just add to it:

GHC fails to build, erroring with this:

Last 15 lines from /Users/zhiayang/Library/Logs/Homebrew/ghc/08.make:

rts/posix/GetTime.c:42:44: error:  error: expected expression

rts/posix/GetTime.c:43:44: error:
     error: use of undeclared identifier 'info'; did you mean 'int'?
        timer_scaling_factor_denom = (uint64_t)info.denom;
                                               ^~~~
                                               int

rts/posix/GetTime.c:43:44: error:  error: expected expression
6 errors generated.
`clang' failed in phase `C Compiler'. (Exit code: 1)
make[1]: *** [rts/dist/build/posix/GetTime.p_o] Error 1
make[1]: *** Waiting for unfinished jobs....
make: *** [all] Error 2

Just a hunch, but maybe some includes aren't being included properly, and some types aren't defined properly.

Did a gist-logs: https://gist.github.com/anonymous/2e04db4167fd75d8b9104be5a0b0c65e
Not entirely urgent since I'll just install Haskell Platform using the pkg.

[jeregrine]

wxmac as well https://gist.github.com/jeregrine/b05f992e535def00bcc85942f4d01dac

[mistydemeo]

@zhiayang Looks like the actual error came slightly earlier in the output:

rts/posix/GetTime.c:40:5: error:
     error: use of undeclared identifier 'mach_timebase_info_data_t'
        mach_timebase_info_data_t info;
        ^

[mistydemeo]

I can repro; looking into it.

[DomT4]

wxmac is a known issue at least, fixed in head apparently. Will add it my the top comment.

[mistydemeo]

I see what's wrong with GHC. This is an upstream bug, I'll submit a patch upstream.

Sierra introduces clock_gettime, which wasn't included in previous versions of OS X. It's a POSIX function to retrieve time, either realtime or monotonic. OS X also includes a Mach-specific monotonic time function.

The initializeTimer function in GHC's rts/posix/GetTime.c has some Darwin-specific behaviour using the mach time structs/functions:

#ifdef darwin_HOST_OS
static uint64_t timer_scaling_factor_numer = 0;
static uint64_t timer_scaling_factor_denom = 0;
#endif

void initializeTimer()
{
#ifdef darwin_HOST_OS
    mach_timebase_info_data_t info;
    (void) mach_timebase_info(&info);
    timer_scaling_factor_numer = (uint64_t)info.numer;
    timer_scaling_factor_denom = (uint64_t)info.denom;
#endif
}

However, everywhere else that uses time functions guards against _both_ darwin_HOST_OS and HAVE_CLOCK_GETTIME. This includes Clock.h, which guards its includes like so:

#ifdef HAVE_CLOCK_GETTIME
# ifdef _POSIX_MONOTONIC_CLOCK
#  define CLOCK_ID CLOCK_MONOTONIC
# else
#  define CLOCK_ID CLOCK_REALTIME
# endif
#elif defined(darwin_HOST_OS)
# include <mach/mach.h>
# include <mach/mach_time.h>
#endif

e.g., the mach_time header won't get included if clock_gettime is available. This can be fixed by improving the guard in initializeTimer, so it skips using any of the mach functions if clock_gettime is available.

[zhiayang]

Ah, thank you @mistydemeo. seems weird apple adds POSIX compliance somewhere, then breaks it elsewhere (read: nm issues over with ghc people)

Also another broken package: homebrew-versions/llvm37
Error here:

Last 15 lines from /Users/zhiayang/Library/Logs/Homebrew/llvm37/04.make:
SYMROOT=/private/tmp/llvm37-20160616-84812-n12rra/llvm-3.7.1.src/projects/libcxx

cd lib && ./buildit
+ for FILE in '../src/*.cpp'
+ /Applications/Xcode-beta.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang++ -c -g -Os -arch i386 -arch x86_64 -nostdinc++ -std=c++11 -fstrict-aliasing -Wall -Wextra -Wshadow -Wconversion -Wpadded -Wstrict-aliasing=2 -Wstrict-overflow=4 -isysroot /Applications/Xcode-beta.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk -I../include ../src/algorithm.cpp
In file included from ../src/algorithm.cpp:11:
In file included from ../include/random:1645:
../include/string:1938:44: error: 'basic_string<_CharT, _Traits, _Allocator>' is missing exception specification 'noexcept(is_nothrow_copy_constructible<allocator_type>::value)'
basic_string<_CharT, _Traits, _Allocator>::basic_string(const allocator_type& __a)
                                           ^
../include/string:1326:40: note: previous declaration is here
    _LIBCPP_INLINE_VISIBILITY explicit basic_string(const allocator_type& __a)
                                       ^
1 error generated.
make: *** [install] Error 1

Appears something in libcxx broke. Worked in 10.11, obviously. Gist is here:
https://gist.github.com/anonymous/b01ec33f72ed02ee66aaaac068332e4f#file-02-make-cc

Again not _that_ urgent, because it turns out llvm38 installs, so I have something else to use.
Thanks again.

[mistydemeo]

libgcrypt builds with optimization turned off. Something's clearly different about clang 8.0, wonder if the bug's on the clang side.

EDIT: also builds -O1; it's just broken with -Os and -O2.

[mistydemeo]

haskell-stack is broken: https://gist.github.com/a2633dccfb4adef13cce3975f3032d2d

[DomT4]

Feel free to edit my original post to add/remove to/from the list as desired Misty, and other maintainers.

[mistydemeo]

After getting through haskell-stack's dependencies by retrying a few times, stack itself fails with an interesting error:

[ 4 of 87] Compiling System.Process.Read ( src/System/Process/Read.hs, dist/dist-sandbox-2c433b3d/build/System/Process/Read.o )
ghc: panic! (the 'impossible' happened)
  (GHC version 8.0.1 for x86_64-apple-darwin):
    Loading temp shared object failed: dlopen(/var/folders/4d/rttdp_9d2s7f36zplgwnqrgr0000gn/T/ghc79664_0/libghc_44.dylib, 5): no suitable image found.  Did find:
    /var/folders/4d/rttdp_9d2s7f36zplgwnqrgr0000gn/T/ghc79664_0/libghc_44.dylib: malformed mach-o: load commands size (40192) > 32768

https://gist.github.com/8e005710eab17139c02267bac3029e33

[mistydemeo]

@DomT4 wxmac 3.1.0 (the --devel version) builds fine on 10.12. I'm going to guess that this was fixed by https://github.com/wxWidgets/wxWidgets/commit/5ba67c67e47d069f65d648ab16dfc505c5400bfc, which removed Carbon support and in the process excised a lot of places that used Quicktime. That's far too big to backport to 3.0.2, but with any luck there will be a stable wx that includes this by the time Sierra is out.

[mistydemeo]

GTK+3 fails trying to find CUPS: https://gist.github.com/fa1be8e62572fcfa2c4ea1b6ecc8ff29

checking for cups-config... /usr/bin/cups-config
configure: error: CUPS >= 1.2 not found

I'm guessing it may be a regex bug, since CUPS on El Cap is 1.6 whereas CUPS on Sierra is 2.2.

[mistydemeo]

The CUPS issue is known, Macports carries a patch: https://trac.macports.org/browser/trunk/dports/gnome/gtk3/files/cups.patch Doesn't look like it was reported upstream though.

[DomT4]

@mistydemeo You are magical; thank you for hunting a bunch of these down.

[mistydemeo]

perl is broken: https://gist.github.com/mistydemeo/37cb3474a09c51b7356683a31b41352b

"../../miniperl" "-I../../lib" "-I../../lib" "../../lib/ExtUtils/xsubpp"  -typemap "../../lib/ExtUtils/typemap" -typemap "typemap"  HiRes.xs > HiRes.xsc && mv HiRes.xsc HiRes.c
cc -c   -fno-common -DPERL_DARWIN -mmacosx-version-min=10.12 -fno-strict-aliasing -pipe -fstack-protector-strong -I/usr/local/include -DPERL_USE_SAFE_PUTENV -Wall -Werror=declaration-after-statement -Wextra -Wc++-compat -Wwrite-strings -Wthread-safety -O3   -DVERSION=\"1.9733\" -DXS_VERSION=\"1.9733\"  "-I../.."  -DTIME_HIRES_NANOSLEEP -DTIME_HIRES_CLOCK_GETTIME -DTIME_HIRES_CLOCK_GETRES -DTIME_HIRES_CLOCK_NANOSLEEP -DTIME_HIRES_CLOCK -DTIME_HIRES_STAT=1 -DATLEASTFIVEOHOHFIVE HiRes.c
HiRes.xs:945:15: error: use of undeclared identifier 'darwin_time_mutex'
  MUTEX_INIT(&darwin_time_mutex);
              ^
1 error generated.
make[1]: *** [HiRes.o] Error 1
cc -c   -fno-common -DPERL_DARWIN -mmacosx-version-min=10.12 -fno-strict-aliasing -pipe -fstack-protector-strong -I/usr/local/include -DPERL_USE_SAFE_PUTENV -Wall -Werror=declaration-after-statement -Wextra -Wc++-compat -Wwrite-strings -Wthread-safety -O3   -DVERSION=\"1.9733\" -DXS_VERSION=\"1.9733\"  "-I../.."  -DTIME_HIRES_NANOSLEEP -DTIME_HIRES_CLOCK_GETTIME -DTIME_HIRES_CLOCK_GETRES -DTIME_HIRES_CLOCK_NANOSLEEP -DTIME_HIRES_CLOCK -DTIME_HIRES_STAT=1 -DATLEASTFIVEOHOHFIVE HiRes.c
HiRes.xs:945:15: error: use of undeclared identifier 'darwin_time_mutex'
  MUTEX_INIT(&darwin_time_mutex);
              ^

Looks like a clock_gettime bug again.

[mistydemeo]

Yup:

#if defined(PERL_DARWIN)
#  ifdef USE_ITHREADS
  MUTEX_INIT(&darwin_time_mutex);
#  endif
#endif

As with GHC, the code that defines the struct is guarded by an #ifdef that checks for whether realtime clock functions are available, but code that uses the struct is used unconditionally on Darwin.

[mistydemeo]

@DomT4 No problem! I'm going to try to get as much fixed as I can. At least so far, I'm not seeing signs of massive breakage due to issues on Apple's side.

[rahulg]

When installing ansible, the step that installs python's cffi module fails to find ffi.h.

pip is able to install cffi, but it uses a wheel built for 10.10 (cffi-1.6.0-cp27-cp27m-macosx_10_10_intel.whl).

Last 15 lines from ~/Library/Logs/Homebrew/ansible/09.python:
copying cffi/vengine_gen.py -> build/lib.macosx-10.12-intel-2.7/cffi
copying cffi/verifier.py -> build/lib.macosx-10.12-intel-2.7/cffi
copying cffi/_cffi_include.h -> build/lib.macosx-10.12-intel-2.7/cffi
copying cffi/parse_c_type.h -> build/lib.macosx-10.12-intel-2.7/cffi
copying cffi/_embedding.h -> build/lib.macosx-10.12-intel-2.7/cffi
running build_ext
building '_cffi_backend' extension
creating build/temp.macosx-10.12-intel-2.7
creating build/temp.macosx-10.12-intel-2.7/c
clang -fno-strict-aliasing -fno-common -dynamic -arch i386 -arch x86_64 -g -Os -pipe -fno-common -fno-strict-aliasing -fwrapv -DENABLE_DTRACE -DMACOSX -DNDEBUG -Wall -Wstrict-prototypes -Wshorten-64-to-32 -DNDEBUG -g -fwrapv -Os -Wall -Wstrict-prototypes -DENABLE_DTRACE -arch i386 -arch x86_64 -pipe -DUSE__THREAD -I/usr/include/ffi -I/usr/include/libffi -I/System/Library/Frameworks/Python.framework/Versions/2.7/include/python2.7 -c c/_cffi_backend.c -o build/temp.macosx-10.12-intel-2.7/c/_cffi_backend.o
c/_cffi_backend.c:15:10: fatal error: 'ffi.h' file not found
#include <ffi.h>
         ^
1 error generated.

[tdsmith]

@rahulg Please make sure you have the latest Xcode or Xcode CLT installed. Please provide brew gist-logs ansible if you'd like help diagnosing.

[rahulg]

Xcode 8 beta is installed. Here're the gist-logs: https://gist.github.com/anonymous/f372fa693e3adf4a1349e6a73a7f60c5.

[DomT4]

Smells more like a missing CLT issue (Which is a valid configuration) more than a 10.12 issue. May need something like we do here for mitmproxy. Tim can confirm either way though, he's the 🐍 expert.

[tdsmith]

@rahulg Thanks. Have you reinstalled Python since you upgraded? The distutils configuration is different for CLT vs Xcode-only setups and it's memorized whenever Python is installed, so switching from a CLT to a Xcode-only setup will break subsequent compiled module builds that depend on the OS X APIs.

[rahulg]

@tdsmith Yup, nuked homebrew before upgrading.

@DomT4 Yeah, that fixes it. Seems it was unrelated to 10.12 after all.

[AlexanderNeilson]

Hi All

I have been working on Wine build issues. I found two during my build process and with the help of upstream (I didn't write the patches) patches have been built for both of them.

WineHQ Bug Number 40830 kVK_RightCommand was originally not defined in the Carbon Framework however Apple has now defined it in 10.12. The patch by Ken in there applies a test for 10.12 at build time and skips defining it again. This has been included in head and 1.9.13 release (Current Devel)

WineHQ Bug Number 40851 Some Deprecated cups functions have been moved by Apple to cups/ppd.h (rather than cups/cups.h). Ken has produced a patch for this and this fixed my build failures in 10.12 DP1. This patch wasn't confirmed until too late to make 1.9.13 release however this will hopefully make it for 1.9.14 (in a week and a half's time if they continue on schedule) however both patches are probably required to build wine (non devel).

I am looking at an updated formula to integrate these in however I am suffering a deeper problem after build. If I try and execute (the one I have tried - one I use daily) I receive shadow memory map errors and it fails to execute. Talking with the Wine team indicates this is Address Sanitizer being configured at build and this is causing the problems.

Looking into the Address Sanitizer it appears that its a build time call which I don't believe has been on previous builds and I believe I have added the correct call to explicitly not build with the Address Sanitizer by adding -fno-sanitizer=address into the CFLAGS section (which appears to add this as an option to every CLANG build call made during the build).

I am wondering if the CLT for Xcode-beta 8 are hard coded to activate address sanitizer or if I am running this incorrectly so I wanted to ask two fold. Can anyone else running 10.12 install wine --devel through homebrew and advise if they have crashes on load? and if anyone else knows the correct way to force no address sanitizer on the builds?

Apologies if this isn't valid to raise here and I can open a ticket with build output however I thought update on Wine state in this ticket and an initial question to confirm would be ok then a separate ticket if required.

Regards
Alexander

[mistydemeo]

Thanks for the detailed report, @AlexanderNeilson! I'm applying those patches, and I'll look into the option. From skimming Apple's Xcode 8 release notes, I don't immediately see anything that suggests a change in the defaults for the address sanitizer.

[rahulg]

guile seems to be broken because of a clock_gettime-related bug. It assumes that clock_getcpuclockid exists if _POSIX_CPUTIME and CLOCK_PROCESS_CPUTIME_ID are defined.

I've got it working by patching out that call on macOS, but that patch feels like a terrible hack. I've reported this upstream, for good measure.

[mistydemeo]

Great! Thanks for finding both that and the guile bug; I've added guile to the list we're tracking above, and I'll backport the rust patch to stable.

[mateusdelbianco]

I found a bug in python and python3 formulae. It doesn't fail while installing, but somehow it fails to detect and compile sqlite3. To detect the issue, we just need to open the python or python3 binary compiled by homebrew and run import _sqlite3.

[DomT4]

@mateusdelbianco Do you have build logs showing the failure to compile the sqlite3 element?

[tdsmith]

Please make sure you have the newest Xcode installed.

[mateusdelbianco]

@DomT4 @tdsmith here it is: https://gist.github.com/mateusdelbianco/3f8c08d6ce82ea489b1a55573bcd7ff2

The most relevant error (I guess):

*** WARNING: renaming "_sqlite3" since importing it failed: dlopen(build/lib.macosx-10.12-x86_64-2.7/_sqlite3.so, 2): Symbol not found: _sqlite3_enable_load_extension
  Referenced from: build/lib.macosx-10.12-x86_64-2.7/_sqlite3.so
  Expected in: flat namespace
 in build/lib.macosx-10.12-x86_64-2.7/_sqlite3.so

[ts826848]

Tried building qt5 on 10.12 from a slightly modified qt5 formula. The changes I made were:

• Change HEAD to point to the dev branch instead of the 5.6 tag. With Qt 5.7 in the works, it doesn't really make sense for HEAD to be building an older version than stable.
• Add the following before ./configure:

if build.head?
  args << "-L/usr/local/opt/openssl/lib"
end

The current versions of Qt 5.7+ (I think?) add OpenSSL support. The build looks for libssl, if I remember correctly, and fails to find it without passing the OpenSSL lib directory as an explicit library search directory.

• Remove patches in formula, as the corresponding issues no longer appear to be in the dev branch.

Unfortunately, the build still does not complete. The error I see consistently is that the Core Bluetooth UUID class CBUUID is forward declared but never included, resulting in errors when the compiler sees code that attempts to access a member of CBUUID.

I have seen a few other errors concerning missing headers, but I'm not sure if they are consistent. I'll report back when I can get around to investigating

[DomT4]

The current versions of Qt 5.7+ (I think?) add OpenSSL support.

It's the other way around, unless Qt have done a complete u-turn. Qt 5.5 introduced an optional usage of Apple's SecureTransport, and 5.6 turned it on by default. It very much shouldn't be necessary to build with OpenSSL any more.

[ts826848]

It very much shouldn't be necessary to build with OpenSSL any more.

Oh really? Could have sworn I had a missing libssl error or something like that... I'll try compiling again

[DomT4]

If it mandates libssl on OS X/macOS either Qt have done a complete u-turn or that's an impressive upstream bug.

[ts826848]

You're right, OpenSSL is not required. Not sure what happened earlier, but seeing as I can't reproduce it, isn't much I can do.

On the other hand, I get a bunch of new errors. Here is the gist. The interesting part is around line 7066-7114 in 02.make.

Aside from that, I really should run brew doctor more frequently... But it seems to me that nothing there would affect this kind of error.

[DomT4]

libgcrypt builds with optimization turned off. Something's clearly different about clang 8.0, wonder if the bug's on the clang side.

Part of me is just tempted to set ENV.no_optimization on libgcrypt for Sierra until we know a bit more here 😕. It's quite an annoying bug as-is.

[DomT4]

https://github.com/Homebrew/homebrew-core/commit/831157188c6abd91bd63aa990a95ebc5edea2f18. Let's see how that goes.

[deepj]

liblwgeom fails:

==> Installing postgis dependency: liblwgeom
==> Downloading http://download.osgeo.org/postgis/source/postgis-2.1.5.tar.gz
######################################################################## 100.0%
==> Downloading https://gist.githubusercontent.com/dakcarto/7458788/raw/8df39204eef5a1e5671828ded7f377ad0f61d4e1/postgis-config_strip-pgsql.diff
######################################################################## 100.0%
==> Patching
==> Applying postgis-config_strip-pgsql.diff
patching file configure.ac
Hunk #1 succeeded at 361 (offset 36 lines).
Hunk #2 succeeded at 771 (offset 32 lines).
Hunk #3 succeeded at 1017 (offset 32 lines).
Hunk #4 succeeded at 1073 (offset 32 lines).
==> ./autogen.sh
Last 15 lines from /Users/deepj/Library/Logs/Homebrew/liblwgeom/01.autogen.sh:
glibtoolize: copying file './config.sub'
glibtoolize: copying file './install-sh'
glibtoolize: copying file './ltmain.sh'
glibtoolize: putting macros in AC_CONFIG_MACRO_DIRS, 'macros'.
glibtoolize: copying file 'macros/libtool.m4'
glibtoolize: copying file 'macros/ltoptions.m4'
glibtoolize: copying file 'macros/ltsugar.m4'
glibtoolize: copying file 'macros/ltversion.m4'
glibtoolize: copying file 'macros/lt~obsolete.m4'
glibtoolize: Consider adding '-I macros' to ACLOCAL_AMFLAGS in Makefile.am.
* Running /usr/local/opt/automake/bin/aclocal (1.15)
aclocal: error: aclocal: file '/usr/local/share/aclocal/wxwin.m4' does not exist

  Something went wrong, giving up!


READ THIS: https://git.io/brew-troubleshooting
If reporting this issue please do so at (not Homebrew/brew):
  https://github.com/Homebrew/homebrew-core/issues

[DomT4]

aclocal: error: aclocal: file '/usr/local/share/aclocal/wxwin.m4' does not exist

This is part of wxmac. As far as I'm aware wxmac isn't in the standard dependency tree of liblwgeom, so bit of a strange error. Can you produce the full brew gist-logs for that? Thanks.

[deepj]

@DomT4 Here https://gist.github.com/deepj/98617cbdc25fef59be9a4eff213a374a

[theeternalsw0rd]

I had a similar issue with missing m4 files with curlftpfs where some of the packages didn't make sense. That's why I kind of put it down to my installation being hosed at the time. https://github.com/Homebrew/homebrew-x11/issues/220

[mistydemeo]

Luajit fails: https://gist.github.com/af4a9c03a2db0641ff2025fdb9d99eff

ld: library not found for -lgcc_s.10.4

The /usr/lib/libgcc_s.10.4.dylib file is no longer shipped as of 10.12.

[mistydemeo]

It builds in stdenv, so this may be something that the flags we've introduced are causing.

[mistydemeo]

After discussion with @DomT4, this looks like a problem with 10.12 and/or the CLT. The Xcode 8 10.12 SDK includes libgcc_s.10.4 as well as 10.5, whereas the lib doesn't exist in /usr/lib. There is also a library which exists as a broken symlink in /usr/lib, so it definitely feels like this needs some attention from Apple. I submitted a radar.

[yurikoles]

gtk+

/System/Library/Frameworks/Foundation.framework/Headers/NSObject.h:44:12: error: unknown property attribute 'class'
@property (class, readonly) BOOL supportsSecureCoding;

and bunch of other similar issues
https://gist.github.com/85670ad8ce93903b266bb7147d855687

[DomT4]

There are some subtle hints in your brew doctor:

Warning: You are using OS X 10.12.
We do not provide support for this pre-release version.
You may encounter build failures or other breakages.
Please create pull-requests instead of filing issues.

Warning: Your Xcode (7.3.1) is outdated
Please update to Xcode 8.0.
Xcode can be updated from
  https://developer.apple.com/xcode/downloads/

Warning: Your Homebrew is outdated.
You haven't updated for at least 24 hours. This is a long time in brewland!
To update Homebrew, run `brew update`.

[yurikoles]

Thanks you for figuring out, I had forgot that I removed Xcode8, I will retry now with 8-DP5.

up: It builds successfully with Xcode8.

[theeternalsw0rd]

For qt5, I also tried the dev branch. It appears <CoreBluetooth/CoreBluetooth.h> need to be imported in some files from submodule qtconnectivity. I can only think that was pulled in from some other path before.

There's also some deprecated cups functionality (getCupsPPD and getCupsPPD2) that has now been removed that is affecting submodule qtwebengine's build of chromium. Chromium upstream bug at https://bugs.chromium.org/p/chromium/issues/detail?id=622493. I'm checking on the cups stuff now.

There may be more issues that the build hasn't gotten to yet. Will report back.

Edit: wrap some code properly

[theeternalsw0rd]

qtwebengine also has the bluetooth header issue.

[theeternalsw0rd]

Upstream chromium does still have the issue with cups. Not a simple fix as there's no drop in replacement. So we first need an update from chromium and wait for the fix to reach qtwebengine. This could take a while.

[jbergstroem]

So, the latest toolchain change seems to have introduce some headaches with beta 6 [10.12 Beta (16A294a)]. Posting these since I can only assume that scattered bugs might land as a result.

Example output:

c++ -o unrar -pthread rar.o strlist.o strfn.o pathfn.o smallfn.o global.o file.o filefn.o filcreat.o archive.o arcread.o unicode.o system.o isnt.o crypt.o crc.o rawread.o encname.o resource.o match.o timefn.o rdwrfn.o consio.o options.o errhnd.o rarvm.o secpassword.o rijndael.o getbits.o sha1.o sha256.o blake2s.o hash.o extinfo.o extract.o volume.o list.o find.o unpack.o headers.o threadpool.o rs16.o cmddata.o ui.o filestr.o recvol.o rs.o scantree.o qopen.o 
ld: unknown option: -no_weak_imports
clang: error: linker command failed with exit code 1 (use -v to see invocation)

checking for gcc... clang
checking whether the C compiler works... no
configure: error: in `/private/tmp/sqlite-20160818-43453-1kn1cos/sqlite-autoconf-3140100':
configure: error: C compiler cannot create executables
See `config.log' for more details

Since auto* seems to die, I can only assume it affects a fair amount of packages. Here's my toolchain:

$ clang --version
Apple LLVM version 8.0.0 (clang-800.0.24.1)
Target: x86_64-apple-darwin16.0.0
Thread model: posix
InstalledDir: /Applications/Xcode-beta.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin

Edit: there's a new Xcode out too; currently downloading -- will update shortly.

[tdsmith]

@jbergstroem The change was Homebrew/brew@6878577d129833b59f82c4872b49e97ba5cec499; new Xcode should fix the problem (but maybe we want to have better granularity for that flag for now?)

[UniqMartin]

@jbergstroem It looks like your Xcode 8 beta and/or Command Line Tools are outdated (most recent clang --version should report clang-800.0.36.1). You might want to also check the version of your linker (ld -v); the option that is causing the failure here was added in ld64-274.

[jbergstroem]

@UniqMartin yes, I noticed that after my comment (made a note at the end)! I can confirm that the auto* and ld stuff is back in shape. Will run through other packages.

[gwaaf]

gcc fails to build:

warning: gcc/cc1obj-checksum.o differs
warning: gcc/cc1objplus-checksum.o differs
warning: gcc/cc1plus-checksum.o differs
Bootstrap comparison failure!
gcc/crttme.o differs
gcc/crttms.o differs
gcc/i386/crttme.o differs
gcc/i386/crttms.o differs
x86_64-apple-darwin16.0.0/i386/libgcc/crttme.o differs
x86_64-apple-darwin16.0.0/i386/libgcc/crttms.o differs
x86_64-apple-darwin16.0.0/libgcc/crttme.o differs
x86_64-apple-darwin16.0.0/libgcc/crttms.o differs
make[2]: *** [compare] Error 1
make[1]: *** [stage3-bubble] Error 2
make: *** [bootstrap] Error 2

logs: https://gist.github.com/08fd8f67d22fe3c3360567da1156e8ca

Edit:
The newest gcc (6.2.0) builds fine on Sierra.

[MikeMcQuaid]

The weak import errors will be fixed as-of https://github.com/Homebrew/brew/pull/782

[jbergstroem]

@MatthewCallis can you verify that your toolchain is up to date? A few people (including me) have seen similar issues as a result of this. You probably want to see something like Apple LLVM version 8.0.0 (clang-800.0.38) invoking clang --version. If not, make sure your Xcode is up to date and try again.

[whitfin]

@MatthewCallis can confirm that all of those install just fine for me on latest betas.

Do you have your Xcode tools set to those of Xcode 8?

[DomT4]

Yeah, your problem will be either still using Xcode 7 or not having sudo xcode-select --switch'd over to Xcode 8 yet @MatthewCallis. I've built most of those formulae within the last 48 hours just fine.

[MatthewCallis]

@jbergstroem @zackehh @DomT4 thanks, will do! You might consider adding a note about switching to the initial comment, missed it being a few down and brew doctor doesn't say how to switch. 👍

[whitfin]

@DomT4 FWIW you can move go to the resolved section now; they released and everything is fine when installing.

[jbergstroem]

@MatthewCallis You're running beta after all -- should shift a bit more responsibility back on the user/setup! :)

[DomT4]

I keep considering just making it a hard fail if people try to brew install stuff with Xcode 7 on 10.12, because people do tend to try and build a bunch of things before poking at it a bit more. There's a balance between being helpful & being annoying though, and it's hard to whack sometimes.

[DomT4]

FWIW you can move go to the resolved section now; they released and everything is fine when installing.

Thanks for the nudge. Top section updated.

[imajes]

Hey guys, heads up that @jemalloc/jemalloc is currently broken in 10.12, which affects quite a few downstream products (including e.g. ruby) that rely on it. The fix is in the dev branch, and i've echoed requests to the maintainer to consider rolling a patch release fix [[@jemalloc/jemalloc#420](https://github.com/jemalloc/jemalloc/issues/420)]

once something comes of it i'll submit a PR; till then, getting the word out.

cc @mistydemeo, @DomT4 - thanks for all the other formulae; you guys are killing it!

[kode54]

Well, this looks like an interesting one:

 /usr/bin/install -c -m 644 fc-validate.1 '/usr/local/Cellar/fontconfig/2.12.1/share/man/man1'
libtool: install: /usr/bin/install -c .libs/fc-validate /usr/local/Cellar/fontconfig/2.12.1/bin/fc-validate
Making install in conf.d
/Applications/Xcode-beta.app/Contents/Developer/usr/bin/make  install-am
make[3]: Nothing to be done for `install-exec-am'.
 .././install-sh -c -d '/usr/local/etc/fonts/conf.d'
 .././install-sh -c -d '/usr/local/Cellar/fontconfig/2.12.1/share/fontconfig/conf.avail'
 /usr/bin/install -c -m 644 README '/usr/local/etc/fonts/conf.d'
 install: /usr/local/etc/fonts/conf.d/README: Permission denied
 make[3]: *** [install-configDATA] Error 71

Shouldn't that be installing to the sandbox?

[zmwangx]

Woohoo, PyPy is failing on Sierra 2: https://bot.brew.sh/view/Testing/job/Homebrew%20Sierra%20Testing/473/. Failure in the linking step it seems, didn't check the details.

[DomT4]

@zmwangx Give me a bit. Going to update the VM so we're actually testing the latest Xcode/GM, just in case.

[zmwangx]

@DomT4 Cool. Cancel my queued job if you wish.

[DomT4]

@zmwangx Thanks, just cleared the queue. Waiting for the core go PR to finish & then I'm going to pause CI entirely temporarily. The VMs are unbearably slow whilst CI is active.

[mistydemeo]

The /usr/lib/libgcc_s.10.4.dylib file is no longer shipped as of 10.12.

This is fixed in the latest Xcode 8 CLT beta.

[kode54]

Well, this looks like an interesting one:

Fixed by the Xcode 8 GM, assuming that was controlled by my use of xcode-select pointing to Xcode and not the CLT, which I just updated less than an hour ago anyway.

[kode54]

Now sane-backends/1.0.25 is failing:

ld: library not found for -lcrypto.35

And I clearly have:

-rw-r--r--  1 root  wheel  4209776 Aug 20 01:53 /usr/lib/libcrypto.35.dylib

Oh, it's not +x. And I don't think I can fix that.

E: It appears to be trying to use its own OpenSSL, which does not include a libcrypto.35.dylib.

E2: No idea. That's probably not it.

[zmwangx]

Damn, PyPy still failing: https://bot.brew.sh/view/Testing/job/Homebrew%20Sierra%20Testing/477/

This time I took a closer look:

[translation:ERROR] CompilationError: CompilationError(err="""
    ld: library not found for -lrt
    clang: error: linker command failed with exit code 1 (use -v to see invocation)
    make: *** [libpypy-c.dylib] Error 1
    """)

Looks like more clock_gettime fun!

[kode54]

ld: library not found for -lcrypto.35

Needs net-snmp, but that's failing because ruby is apparently broken:

BuildError: Failed executing: ./configure --disable-debugging --prefix=/usr/local/Cellar/net-snmp/5.7.3 --enable-ipv6 --with-defaults --with-persistent-directory=/usr/local/var/db/net-snmp --with-logfile=/usr/local/var/log/snmpd.log --with-mib-modules=host ucd-snmp/diskio --without-rpm --without-kmem-usage --disable-embedded-perl --without-perl-modules

Yeah, I think there are supposed to be double-quotes around that --with-mib-modules=host ucd-snmp/diskio. At least this from the Formula would imply that:

    args = %W[
      --disable-debugging
      --prefix=#{prefix}
      --enable-ipv6
      --with-defaults
      --with-persistent-directory=#{var}/db/net-snmp
      --with-logfile=#{var}/log/snmpd.log
      --with-mib-modules=host ucd-snmp/diskio
      --without-rpm
      --without-kmem-usage
      --disable-embedded-perl
      --without-perl-modules
    ]

This seems to imply that my version of Ruby is not treating each of those individual lines as single arguments, but whitespace tokenizing each of them. Which sounds broken.

Running:

ruby 2.0.0p648 (2015-12-16 revision 53162) [universal.x86_64-darwin16]

[DomT4]

@kode54 https://github.com/Homebrew/homebrew-core/pull/4603

[zmwangx]

@kode54

This seems to imply that my version of Ruby is not treating each of those individual lines as single arguments, but whitespace tokenizing each of them. Which sounds broken.

Your Ruby is not broken; it's c366cf1 5484070 that screwed up.

[yurikoles]

How about forcing/reminding users to use Xcode 8 in xcode-select? Because there is many issues with Xcode 7 on Sierra.

As for now brew is forcing to install Xcode 8, but does not check it's activation in xcode-select.

[DomT4]

We do, to some extent: https://github.com/Homebrew/brew/blob/master/Library/Homebrew/extend/os/mac/diagnostic.rb#L66-L71. Helpfully Apple has now dropped the -beta element, so I'll have to go update that message again.

[yurikoles]

@DomT4 let's discuss it here: #4664

[zmwangx]

haskell-stack is broken, both locally and on the test bot. https://bot.brew.sh/job/Homebrew%20Sierra%20Testing/704/version=sierra_2/testReport/junit/brew-test-bot/sierra/install_haskell_stack/. Upstream bug report: https://github.com/commercialhaskell/stack/issues/2577.

Edit: Forgot this is an old issue.

[ilovezfs]

@zmwangx you may want to try the suggestion here: https://ghc.haskell.org/trac/ghc/ticket/12479#comment:2

[ilovezfs]

@mistydemeo it looks like upstream marked your issue as a duplicate and is also requesting additional information:
https://ghc.haskell.org/trac/ghc/ticket/12479
https://ghc.haskell.org/trac/ghc/ticket/12198

[zmwangx]

@ilovezfs Marking 12198 as duplicate of 12479... WTF...

Not in the mood of recompiling GHC right now. But

Is it possible that your libghc is built with -split-sections? It sounds like we are producing too many sections for Darwin's linker.

Are we? Not sure.

[ilovezfs]

Not in the mood of recompiling GHC right now

does such a mood exist?

Are we? Not sure.

no idea.

[mistydemeo]

As far as I'm able to determine, --split-sections is off by default and we don't enable it.

[ghost]

@mateusdelbianco @DomT4 @tdsmith: also getting the error with building python using Homebrew. I have the latest Xcode and Xcode command line tools installed.

Sqlite seem to fail while building python

See logs: https://gist.github.com/extink/be39e9142e53ea390281cb79c31867f1

[daenney]

@extink That's odd. I just built Python 2 and 3 on Sierra with no issue 😕.

[ghost]

@daenney: building does nog give any errors, but using sqlite with an import fails. Can you check that as well?

[zmwangx]

FYI, I was able to build ansible successfully on our CI today, despite it failing just a day or two ago. Sierra bottle uploaded, testing is welcome.

[zmwangx]

@extink import sqlite3 is part of our tests for python and python3 so they do work.

[ghost]

@zmwangx: so why does it fail for @mateusdelbianco and me?

[zmwangx]

@extink I can't say much except at least our bottles are fine. And I probably won't take a two-month old report seriously during the macOS beta period. Without new logs (from a machine with both latest Xcode and latest CLT) we probably won't advance very far.

[daenney]

@extink Checked and it works in my case:

[I] 16:12:32 ~/h/bin (master) $ pwd
/Users/daenney/homebrew/bin

[I] 16:12:33 ~/h/bin (master) $ ./python
Python 2.7.12 (default, Sep 14 2016, 11:03:49)
[GCC 4.2.1 Compatible Apple LLVM 8.0.0 (clang-800.0.38)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import sqlite3
>>>

[I] 16:12:43 ~/h/bin (master) $ ./python3
Python 3.5.2 (default, Sep 14 2016, 11:06:15)
[GCC 4.2.1 Compatible Apple LLVM 8.0.0 (clang-800.0.38)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import sqlite3
>>>

[chdiza]

I think we can add screenresolution to the bunch, when it's built from HEAD. On the Sierra GM with the offical Xcode 8 release I get:

==> make CC=clang
sed -e "s/@VERSION@/\"1.7dev\"/" < version-tmpl.h > version.h
clang   -arch i386 -arch x86_64 main.c -c -o main.o
clang   -arch i386 -arch x86_64 cg_utils.c -c -o cg_utils.o
clang   -arch i386 -arch x86_64 -framework Foundation -framework ApplicationServices main.o cg_utils.o -o screenresolution
Undefined symbols for architecture x86_64:
  "_MIN", referenced from:
      _listAvailableModes in main.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make: *** [screenresolution] Error 1

I'll report upstream if you want, but I thought I'd post here for reproduction and in case this smells like something HB needs to do something about.

[ts826848]

Installing qt5 from a fresh install, and I'm getting (among other things) linker errors due to missing libssl. gist

Edit: Maybe from MySQL/Postgresql, not Qt itself? Take out those options and the compilation seems to continue fine

Edit 2: Seems like it? Need to pull in OpenSSL if either SQL is used, looks like

[chdiza]

screenresolution problem reported upstream. Not holding my breath: no commits since May 2014.

[ilovezfs]

same GHC panic attempting to build git-annex :see_no_evil:

stack itself is off the hook.

[zmwangx]

Looks like we'll have to do the unavoidable: rebuild GHC, possibly a dozen times.

[ilovezfs]

upstream GHC is looking into it as well since Stack has been ruled out as the cause.

so splendid: https://gist.github.com/ilovezfs/67795d2df41f74fc25f448d48600671d

[zmwangx]

GHC just won the annual best fatal error message award:

ghc: panic! (the 'impossible' happened)

[zmwangx]

Not sure if there's any more value in spamming this issue, but jack is broken:

https://bot.brew.sh/view/Testing/job/Homebrew%20Sierra%20Testing/782/version=sierra_2/testReport/junit/brew-test-bot/sierra/install_jack/

TIMER_ABSTIME is undefined for clock_nanosleep. I thought OS X conforms to POSIX 2001?

[zmwangx]

open-scene-graph broken: https://bot.brew.sh/view/Testing/job/Homebrew%20Sierra%20Testing/790/version=sierra_2/testReport/junit/brew-test-bot/sierra/install_open_scene_graph/

Rather interesting:

CMake Error at CMakeLists.txt:183 (LIST):
  list index: 2 out of range (-2, 1)

[zmwangx]

irrlicht is broken: https://bot.brew.sh/view/Testing/job/Homebrew%20Sierra%20Testing/796/version=sierra_2/testReport/junit/brew-test-bot/sierra/install_irrlicht/

/tmp/irrlicht-20160917-64459-123oi19/irrlicht-1.8.3/source/Irrlicht/zlib/inflate.c:1491:61: warning: shifting a negative signed value is undefined [-Wshift-negative-value]
    if (strm == Z_NULL || strm->state == Z_NULL) return -1L << 16;
                                                        ~~~ ^

[zmwangx]

alergo broken in Xcode 8 due to including QuickTime/QuickTime.h: https://bot.brew.sh/view/Testing/job/Homebrew%20Sierra%20Testing/797/version=sierra_2/testReport/junit/brew-test-bot/sierra/install_allegro/

[zmwangx]

dshb is in Swift 2.2 so it clearly won't build against Xcode 8. Reported upstream https://github.com/beltex/dshb/issues/36. Will boneyard if there's no response for a while.

[lightsing]

Is this is a problem of Xcode?

System: OS X EI Captian 10.11.6
Xcode: Version 7.3.1 (7D1014)

`brew install wine --devel
==> Installing dependencies for wine: pkg-config
==> Installing wine dependency: pkg-config
==> Downloading https://homebrew.bintray.com/bottles/pkg-config-0.29.1_2.el_capitan.bottle.tar.gz

################################################################## 100.0%

==> Pouring pkg-config-0.29.1_2.el_capitan.bottle.tar.gz
🍺 /usr/local/Cellar/pkg-config/0.29.1_2: 10 files, 627.3K
==> Installing wine
==> Using the sandbox
==> Downloading https://dl.winehq.org/wine/source/1.9/wine-1.9.19.tar.bz2
Already downloaded: /Users/Tsing/Library/Caches/Homebrew/wine-1.9.19.tar.bz2
==> Downloading https://bugs.winehq.org/attachment.cgi?id=52384
Already downloaded: /Users/Tsing/Library/Caches/Homebrew/wine--patch-30766403f5064a115f61de8cacba1defddffe2dd898b59557956400470adc699.cgi
==> Patching
==> Applying attachment.cgi
patching file dlls/wined3d/surface.c
Hunk #1 succeeded at 1465 (offset -816 lines).
Hunk #2 succeeded at 1811 (offset -816 lines).
==> ./configure --prefix=/usr/local/Cellar/wine/1.9.19 --without-mpg123
==> make install
Last 15 lines from /Users/Tsing/Library/Logs/Homebrew/wine/02.make:
bison -p parser_ -o parser.tab.c parser.y
clang -m32 -c -o parser.yy.o parser.yy.c -I. -I../../include -D__WINESRC__ -Wall -pipe -fno-strict-aliasing \
-Wdeclaration-after-statement -Wempty-body -Wignored-qualifiers -Wstrict-prototypes -Wtype-limits \
-Wvla -Wwrite-strings -Wpointer-arith -gdwarf-2 -gstrict-dwarf -fno-omit-frame-pointer -g -O2 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=0
clang -m32 -c -o parser.tab.o parser.tab.c -I. -I../../include -D__WINESRC__ -Wall -pipe -fno-strict-aliasing \
-Wdeclaration-after-statement -Wempty-body -Wignored-qualifiers -Wstrict-prototypes -Wtype-limits \
-Wvla -Wwrite-strings -Wpointer-arith -gdwarf-2 -gstrict-dwarf -fno-omit-frame-pointer -g -O2 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=0
clang -m32 -c -o parser.tab.o parser.tab.c -I. -I../../include -D__WINESRC__ -Wall -pipe -fno-strict-aliasing \
-Wdeclaration-after-statement -Wempty-body -Wignored-qualifiers -Wstrict-prototypes -Wtype-limits \
-Wvla -Wwrite-strings -Wpointer-arith -gdwarf-2 -gstrict-dwarf -fno-omit-frame-pointer -g -O2 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=0
clang -m32 -o wrc dumpres.o genres.o newstruc.o po.o readres.o translation.o utils.o wrc.o writeres.o \
parser.tab.o parser.yy.o ../../libs/port/libwine_port.a ../../libs/wpp/libwpp.a
clang -m32 -o widl client.o expr.o hash.o header.o proxy.o register.o server.o typegen.o typelib.o \
typetree.o utils.o widl.o write_msft.o parser.tab.o parser.yy.o ../../libs/port/libwine_port.a \
../../libs/wpp/libwpp.a

READ THIS: https://git.io/brew-troubleshooting
If reporting this issue please do so at (not Homebrew/brew):
https://github.com/Homebrew/homebrew-core/issues`

[zmwangx]

@lightsing Please follow https://git.io/brew-troubleshooting and post your gist-logs.

[jonct]

so why does it fail for @mateusdelbianco and me?

Indeed. I've been trying to get up to speed on the python/sqlite3 problem for days, off and on. This issue came up in my search and seemed to be my most promising lead toward finding a solution or workaround.

I'm running GM everything. I'd eventually resorted to nuking /usr/local and reinstalling Homebrew. Even then: my python 2 wouldn't import sqlite3. I believe I was facing the same results as @extink.

As it turns out, @zmwangx provided a vital clue above but I'd missed it so I'll be explicit for drive-by readers like me: the CLI tools are no longer considered optional or equivalent to the Xcode app.

Once I used xcode-select --install I was finally able to install and use Python with sqlite3 support.

[daenney]

Ah, that might also explain why it works for me. I have no need for the full Xcode so I generally only xcode-select --install. However that should be equivalent to installing Xcode and then in the preferences checking the box/thing that makes it install the CLT, which afaik always needed to happen to get the CLT in previous Xcode versions too.

[mateusdelbianco]

Actually python and python3 were both working on one of my machines and failing on another. Now that people mentioned, one difference between my machines was exactly the CLT. The one that was working had CLT installed, while the failing had only Xcode. Shame on me for not noticing this huge difference earlier...

[JCount]

It might be worth noting that 10.12 has effectively removed QTKit.framework as well. It still technically exists, but everything besides the QTMovieModernizer class was removed, and what is left is only there to covert "legacy" media resources into a format that AVFoundation.framework can handle. Therefore, any formula that explicitly or implicitly built against QTKit will probably be "broken" to some extent.

EDIT:
Reference: https://developer.apple.com/reference/qtkit

[kode54]

Off topic, but this bodes well for my analog video capture device, which is based on an Empia 28xx chipset, and is only supported by a QuickTime extension that was relicensed from echofx.com by Geniatech and company. I suppose maybe one of them will get off their dead butt and make an AVFoundation driver, if they ever realize that 10.9 is no longer new.

[zmwangx]

shadowsocks-libev failed on 10.11 with Xcode 8, not 10.12.

[chdiza]

Turns out that screenresolution's failure is an Xcode 8 problem, not specifically a Sierra one. It bombs out identically on ElCap with Xcode 8.

I have reported this nugget upstream also.

[mantrasuser]

I am having Qt problem while I am trying to install gnuplot

brew install gnuplot --with-qt5 and brew install gnuplot --with-qt fails I guess it is related to this issue. Do you have any idea?

[zmwangx]

I think this issue is too long right now and approaching worthlessness because the top post hasn't been updated (not OP's fault). @DomT4 What about we lock this and let people open individual reports going forward?

[DomT4]

Aye. This served its purpose well, and I appreciate everyone's contributions and journey with us through 10.12/Xcode 8 being prerelease but let's shuffle things off into individual issues at this point as we have in previous years.