search

Homebrew / homebrew-core

🍻 Default formulae for the missing package manager for macOS (or Linux)
https://brew.sh
BSD 2-Clause "Simplified" License
13.69k stars 12.4k forks source link

macOS 10.12 and Xcode 8.0 broken formulae #1957

Closed DomT4 closed 8 years ago

DomT4 commented 8 years ago

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:

Upstream/Homebrew 10.12 support hacks:

Resolved:

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 commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

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

DomT4 commented 8 years ago

@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 commented 8 years ago

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 commented 8 years ago

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

mistydemeo commented 8 years ago

@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 commented 8 years ago

I can repro; looking into it.

DomT4 commented 8 years ago

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

mistydemeo commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

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

DomT4 commented 8 years ago

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

mistydemeo commented 8 years ago

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 commented 8 years ago

@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 commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

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

mistydemeo commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

@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 commented 8 years ago

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 commented 8 years ago

@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 commented 8 years ago

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

DomT4 commented 8 years ago

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 commented 8 years ago

@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 commented 8 years ago

@tdsmith Yup, nuked homebrew before upgrading.

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

AlexanderNeilson commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

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

tdsmith commented 8 years ago

Please make sure you have the newest Xcode installed.

mateusdelbianco commented 8 years ago

@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 commented 8 years ago

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

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.

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 commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

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

ts826848 commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

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

deepj commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

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

theeternalsw0rd commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

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

mistydemeo commented 8 years ago

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.