Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

First issues with macOS 10.13 High Sierra #14418

Closed
fxcoudert opened this issue Jun 9, 2017 · 122 comments

Comments

Projects
None yet
@fxcoudert
Copy link
Member

commented Jun 9, 2017

This is with Developer Beta of macOS 10.13, using Xcode 9 beta, Apple LLVM version 9.0.0 (clang-900.0.22.8).

@MikeMcQuaid

This comment has been minimized.

Copy link
Member

commented Jun 9, 2017

libunistring fails to build because make check has 28 failing tests (Illegal instruction errors)

Are you running in a VM?

@fxcoudert

This comment has been minimized.

Copy link
Member Author

commented Jun 9, 2017

Are you running in a VM?

No, it's a mac mini. Smells like miscompilation to me :(

@MikeMcQuaid

This comment has been minimized.

Copy link
Member

commented Jun 9, 2017

@fxcoudert Cool, just checking given that's sometimes what it is for that error.

@fxcoudert

This comment has been minimized.

Copy link
Member Author

commented Jun 9, 2017

The libunistring failures all come from the system's snfprintf:

(lldb) target create ".libs/test-u16-asnprintf1"
Current executable set to '.libs/test-u16-asnprintf1' (x86_64).
(lldb) r
Process 27203 launched: '/Users/fx/Downloads/libunistring-0.9.7/tests/.libs/test-u16-asnprintf1' (x86_64)
Process 27203 stopped
* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_INSTRUCTION (code=EXC_I386_INVOP, subcode=0x0)
    frame #0: 0x00007fffc01cc89b libsystem_c.dylib`__vfprintf + 16437
libsystem_c.dylib`__vfprintf:
->  0x7fffc01cc89b <+16437>: ud2    
    0x7fffc01cc89d <+16439>: nopl   (%rax)
    0x7fffc01cc8a0 <+16442>: retq   
Target 0: (test-u16-asnprintf1) stopped.
(lldb) bt
* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_INSTRUCTION (code=EXC_I386_INVOP, subcode=0x0)
  * frame #0: 0x00007fffc01cc89b libsystem_c.dylib`__vfprintf + 16437
    frame #1: 0x00007fffc01f1431 libsystem_c.dylib`__v2printf + 473
    frame #2: 0x00007fffc01d62e7 libsystem_c.dylib`_vsnprintf + 415
    frame #3: 0x00007fffc01d6344 libsystem_c.dylib`vsnprintf_l + 41
    frame #4: 0x00007fffc01c7364 libsystem_c.dylib`snprintf + 180
    frame #5: 0x00000001000ba114 libunistring.2.dylib`u16_vasnprintf(resultbuf=<unavailable>, lengthp=0x00007fff5fbffac0, format="12345", args=<unavailable>) at vasnprintf.c:0 [opt]
    frame #6: 0x00000001000b3e32 libunistring.2.dylib`u16_asnprintf(resultbuf=<unavailable>, lengthp=<unavailable>, format=<unavailable>) at u-asnprintf.h:34 [opt]
    frame #7: 0x0000000100000b89 test-u16-asnprintf1`main at test-u16-asnprintf1.h:30 [opt]
    frame #8: 0x0000000100000b70 test-u16-asnprintf1`main [inlined] test_asnprintf at test-u16-asnprintf1.c:38 [opt]
    frame #9: 0x0000000100000b70 test-u16-asnprintf1`main(argc=<unavailable>, argv=<unavailable>) at test-u16-asnprintf1.c:44 [opt]
    frame #10: 0x00007fffc013d515 libdyld.dylib`start + 1
    frame #11: 0x00007fffc013d515 libdyld.dylib`start + 1

@ilovezfs ilovezfs added the 10.13 label Jun 9, 2017

@chapeladmin

This comment has been minimized.

Copy link

commented Jun 9, 2017

bison keg has illegal instruction issues (this is exhibited in all bison version >= 2.5). Looks like Apple made some changes to the printf stack. I've reported this to Apple. Could be a bug, or they could just need to release some documentation on what changed.

imagemagick fails to build.

libtool: link: clang  -o coders/.libs/png.so -bundle  coders/.libs/coders_png_la-png.o   MagickCore/.libs/libMagickCore-7.Q16HDRI.dylib -L/usr/local/opt/freetype/lib -L/usr/local/Cellar/xz/5.2.3/lib -lfreetype -lbz2 -lltdl -L/usr/local/Cellar/libpng/1.6.29/lib -lpng16 -ljpeg -llzma -lm  -g -O2 -mtune=haswell -pthre
ad   -pthread -Wl,-exported_symbols_list,coders/.libs/png-symbols.expsym
Undefined symbols for architecture x86_64:
  "_crc32", referenced from:
      _WriteMNGImage in coders_png_la-png.o
      _ReadOnePNGImage in coders_png_la-png.o
      _ReadOneJNGImage in coders_png_la-png.o
      _WriteOnePNGImage in coders_png_la-png.o
      _Magick_png_write_chunk_from_profile in coders_png_la-png.o
      _WriteOneJNGImage in coders_png_la-png.o
  "_zlibVersion", referenced from:
      _RegisterPNGImage in coders_png_la-png.o
      _ReadOnePNGImage in coders_png_la-png.o
      _WriteOnePNGImage in coders_png_la-png.o
ld: symbol(s) not found for architecture x86_64

The built-in telnet client appears to have been dropped, so a telnet package may be desirable now. I'm going to try to get the telnet client gentoo linux uses patched up to work.

@DomT4

This comment has been minimized.

Copy link
Contributor

commented Jun 9, 2017

brew test pkg-config fails because it cannot find openssl.pc (build logs)

Apple killed the file. It can be replaced in the test with libiodbc or something.

@fxcoudert

This comment has been minimized.

Copy link
Member Author

commented Jun 11, 2017

  • yaml test fails with ld: library not found for -lyaml
  • gcc fails with fatal error: unordered_map: No such file or directory building libstdc++-v3/include/precompiled/stdc++.h
@fxcoudert

This comment has been minimized.

Copy link
Member Author

commented Jun 12, 2017

  • qt fails to build (logs)
  • brew test nettle fails with ld: library not found for -lnettle (#15282.)
  • mpc and mpfr tests fail with ld: library not found for -lgmp (#15283)
  • isl test fails due to not finding -lisl (#15284)
  • carthage fails with:
The following build commands failed:
       CompileSwift normal x86_64
       CompileSwiftSources normal x86_64 com.apple.xcode.tools.swift.compiler
  • brew test shared-mime-info fails with unknown file type: /usr/local/Cellar/shared-mime-info/1.8_1/share/mime
  • tbb test fails due to not finding -ltbb (#15289)
  • macvim fails with
The following build commands failed:
        StripNIB English.lproj/Preferences.nib
  • wine fails while building net-snmp with mibgroup/mibII/ipv6.c:1762:34: error: variable has incomplete type 'struct in6pcb' (logs)
@DomT4

This comment has been minimized.

Copy link
Contributor

commented Jun 12, 2017

brew test nettle fails with ld: library not found for -lnettle

Something... weird is going on with clang et al. Not sure how intentional it is to be honest, but may require some tweaks in Homebrew to handle if it sticks around.

=> clang -x c -v -E /dev/null

Apple LLVM version 9.0.0 (clang-900.0.22.8)
Target: x86_64-apple-darwin17.0.0
Thread model: posix
InstalledDir: /Applications/Xcode-beta.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin
 "/Applications/Xcode-beta.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang" -cc1 -triple x86_64-apple-macosx10.13.0 -Wdeprecated-objc-isa-usage -Werror=deprecated-objc-isa-usage -E -disable-free -disable-llvm-verifier -discard-value-names -main-file-name null -mrelocation-model pic -pic-level 2 -mthread-model posix -mdisable-fp-elim -fno-strict-return -masm-verbose -munwind-tables -target-cpu penryn -target-linker-version 301.1 -v -dwarf-column-info -debugger-tuning=lldb -resource-dir /Applications/Xcode-beta.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/clang/9.0.0 -isysroot /Applications/Xcode-beta.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.13.sdk -fdebug-compilation-dir /Users/testing -ferror-limit 19 -fmessage-length 120 -stack-protector 1 -fblocks -fobjc-runtime=macosx-10.13.0 -fencode-extended-block-signature -fmax-type-align=16 -fdiagnostics-show-option -fcolor-diagnostics -o - -x c /dev/null
clang -cc1 version 9.0.0 (clang-900.0.22.8) default target x86_64-apple-darwin17.0.0
ignoring nonexistent directory "/Applications/Xcode-beta.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.13.sdk/usr/local/include"
ignoring nonexistent directory "/Applications/Xcode-beta.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.13.sdk/Library/Frameworks"
#include "..." search starts here:
#include <...> search starts here:
 /Applications/Xcode-beta.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/clang/9.0.0/include
 /Applications/Xcode-beta.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include
 /Applications/Xcode-beta.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.13.sdk/usr/include
 /Applications/Xcode-beta.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.13.sdk/System/Library/Frameworks (framework directory)
End of search list.
# 1 "/dev/null"
# 1 "<built-in>" 1
# 1 "<built-in>" 3
# 331 "<built-in>" 3
# 1 "<command line>" 1
# 1 "<built-in>" 2
# 1 "/dev/null" 2
=> clang -Xlinker -v

@(#)PROGRAM:ld  PROJECT:ld64-301.1
configured to support archs: armv6 armv7 armv7s arm64 i386 x86_64 x86_64h armv6m armv7k armv7m armv7em (tvOS)
Library search paths:
	/Applications/Xcode-beta.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.13.sdk/usr/lib
Framework search paths:
	/Applications/Xcode-beta.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.13.sdk/System/Library/Frameworks/

It looks like the direct /usr/local & /usr have been punted from the default search paths when using Xcode. This however isn't true when using only the CLT:

=> /Library/Developer/CommandLineTools/usr/bin/clang -x c -v -E /dev/null                                        
Apple LLVM version 9.0.0 (clang-900.0.22.8)
Target: x86_64-apple-darwin17.0.0
Thread model: posix
InstalledDir: /Library/Developer/CommandLineTools/usr/bin
 "/Library/Developer/CommandLineTools/usr/bin/clang" -cc1 -triple x86_64-apple-macosx10.13.0 -Wdeprecated-objc-isa-usage -Werror=deprecated-objc-isa-usage -E -disable-free -disable-llvm-verifier -discard-value-names -main-file-name null -mrelocation-model pic -pic-level 2 -mthread-model posix -mdisable-fp-elim -fno-strict-return -masm-verbose -munwind-tables -target-cpu penryn -target-linker-version 301.1 -v -dwarf-column-info -debugger-tuning=lldb -resource-dir /Library/Developer/CommandLineTools/usr/lib/clang/9.0.0 -fdebug-compilation-dir /Users/testing -ferror-limit 19 -fmessage-length 120 -stack-protector 1 -fblocks -fobjc-runtime=macosx-10.13.0 -fencode-extended-block-signature -fmax-type-align=16 -fdiagnostics-show-option -fcolor-diagnostics -o - -x c /dev/null
clang -cc1 version 9.0.0 (clang-900.0.22.8) default target x86_64-apple-darwin17.0.0
#include "..." search starts here:
#include <...> search starts here:
 /usr/local/include
 /Library/Developer/CommandLineTools/usr/lib/clang/9.0.0/include
 /Library/Developer/CommandLineTools/usr/include
 /usr/include
 /System/Library/Frameworks (framework directory)
 /Library/Frameworks (framework directory)
=> /Library/Developer/CommandLineTools/usr/bin/clang -Xlinker -v
@(#)PROGRAM:ld  PROJECT:ld64-301.1
configured to support archs: armv6 armv7 armv7s arm64 i386 x86_64 x86_64h armv6m armv7k armv7m armv7em (tvOS)
Library search paths:
	/usr/lib
	/usr/local/lib
Framework search paths:
	/Library/Frameworks/
	/System/Library/Frameworks/

If the Xcode model did become the default: It's possible that would render system-protective keg_only choices like openssl on macOS 10.13 almost unimportant, although I don't expect Homebrew to make any drastic choices on that given it would cause discrepancies between the newest and older macOS versions.

@mistydemeo

This comment has been minimized.

Copy link
Member

commented Jun 13, 2017

This however isn't true when using only the CLT:

However, it is true when using the /usr/bin version of clang when the CLT is the active xcode_select path:

$ /usr/bin/clang -Xlinker -v
@(#)PROGRAM:ld  PROJECT:ld64-301.1
configured to support archs: armv6 armv7 armv7s arm64 i386 x86_64 x86_64h armv6m armv7k armv7m armv7em (tvOS)
Library search paths:
	/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/lib
Framework search paths:
	/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/System/Library/Frameworks/
@DomT4

This comment has been minimized.

Copy link
Contributor

commented Jun 13, 2017

Interesting, I missed that. Nice find! I wonder if both of those exhibiting the same behaviour semi-confirms this might be an intentional choice/direction on Apple's part.

@mistydemeo

This comment has been minimized.

Copy link
Member

commented Jun 13, 2017

The behaviour between /usr/bin/clang and /Library/Developer/CommandLineTools/usr/bin/clang feels backward, which makes me wonder if it's a packaging mistake. Assuming that's the case, the intention I'm reading is:

  • The Xcode version of the tool, with no headers in /usr/include, is configured only to look inside the Xcode SDK by default. This makes sense for a tool intended primarily to be used by Xcode itself, along with other software building in an Xcode-centric context.
  • The /Library version of the tool is configured only to look inside its own "SDK" by analogy.
  • The /usr/bin/clang version works for Unix-style CLI builds as it always did.
@fxcoudert

This comment has been minimized.

Copy link
Member Author

commented Jun 13, 2017

Other failures and links to logs:

wxmac, bison, thefuck (test failure), swiftlint, qt, swig (test failure, cannot find ruby.h).

@fxcoudert

This comment has been minimized.

Copy link
Member Author

commented Jun 13, 2017

ghc fails to build (clang preprocessor bug already reported by @mistydemeo), apache-spark test fails, midnight-commander fails to build

@MikeMcQuaid

This comment has been minimized.

Copy link
Member

commented Jun 13, 2017

It's worth noting based on previous usage that many of the weird behaviour we're seeing now will be changed in later betas of macOS and Xcode. I don't think it's worth either worrying or fixing many of these for a while.

@theeternalsw0rd

This comment has been minimized.

Copy link

commented Jun 13, 2017

I have packaged a telnet client and built a tap for it available at https://github.com/theeternalsw0rd/homebrew-telnet since the built-in one is mia.

I wouldn't think any package would depend on the built-in client but in case there's some obscure package I'm unaware of that utilizes it, this works as a drop-in replacement.

@DomT4

This comment has been minimized.

Copy link
Contributor

commented Jun 13, 2017

I don't think it's worth either worrying or fixing many of these for a while.

Agree with this on the formulae side of things. Making assumptions about High Sierra behaviour quite this early is asking to have to reverse or re-tweak things more going forwards 😓. As long as there's enough support for it on the brew side of things I think if you're actually running 10.13 as your main driver you should absolutely expect so much to break for a while.

I have packaged a telnet client

Doesn't surprise me Apple killed this to be honest. There's still the version from 10.12 on Apple's OpenSource website Homebrew could simply compile with Xcode if the demand reaches whatever level is deemed sufficient. It's not like the world is lacking third-party telnet clients though, so.

@chenillen

This comment has been minimized.

Copy link

commented Jun 15, 2017

@theeternalsw0rd the missing telnet made me feel so weird. Thanks for the tap.

@chapeladmin

This comment has been minimized.

Copy link

commented Jun 15, 2017

According to Apple, the issue with bison (and I'm assuming libunistring) is %n in formatted strings that are in dynamic memory. Waiting to hear anything further from Apple, but it seems like something they are planning on fixing as they said they are continuing to work on it.

@idyll

This comment has been minimized.

Copy link
Contributor

commented Jun 15, 2017

Also of note. Apple has bundled LibreSSL on the system but is using a custom version BoringSSL internally as well.

This causes issues with dynamic linking as some things grab the wrong SSL. (Erlang for example.)
I am hoping Apple fixes this in the next beta because they don't want people using their BoringSSL.

Anything that isn't TWOLEVEL has issues right now. Aka FLATNAMESPACE.
You can check with otool -hV

I will report back on this once I have more info.

@kylebrowning

This comment has been minimized.

Copy link

commented Jun 16, 2017

Cant install gpg because of libunistring which means anything for git commits its broken :(

Anyway to manually build this particular item?

@sunipkmukherjee

This comment has been minimized.

Copy link

commented Jun 18, 2017

All versions of gcc are failing to build (at least without multilib support).
Nano builds successfully but does not work, i.e. segfaults when a buffer is flushed to a file (which is unsuccessful).

@ilovezfs

This comment has been minimized.

Copy link
Contributor

commented Jun 22, 2017

@kylebrowning you can brew install --force-bottle foo for anything you're having trouble building and it should pour the Sierra bottle.

@DomT4

This comment has been minimized.

Copy link
Contributor

commented Jun 22, 2017

Has everyone else noticed that curl no longer uses SecureTransport? That's quite some shift.

@idyll

This comment has been minimized.

Copy link
Contributor

commented Jun 22, 2017

I am seeing no changes in current beta. Anything that points to OpenSSL compiled as FLATNAMESPACE instead of TWOLEVEL is probably going to hit Apple's private BoringSSL now. :(

A an example, right now this affects all versions of Erlang. And I can't seem to fix it with their compiler flags.

@DomT4

This comment has been minimized.

Copy link
Contributor

commented Jun 22, 2017

curl got an update, and now seems to have gained HTTP2 support, which will please @vszakats if my memory of an old PR serves me correctly. Not much else seems to have changed. libunistring still fails to build at the make check stage.

@Korni22

This comment has been minimized.

Copy link

commented Jun 24, 2017

FYI: lftp is also broken 😕

@savemeaspark

This comment has been minimized.

Copy link

commented Jun 25, 2017

Found some errors in working with apache. It might be my machine, or it may be a product of the beta testing, but I thought I would mention it here just in case. I've attached a screen shot for clarification.

screenshot 2017-06-25 12 56 05

@fxcoudert fxcoudert referenced this issue Sep 4, 2017

Closed

xctool 0.3.3 #17456

@kcoop

This comment has been minimized.

Copy link

commented Sep 5, 2017

Having issues installing heroku.

First problem was icu4c, couldn't find include files (specifically unicode/uversion.h). Workaround was to do a brew link --force icu4c

Current problem is node:

brew install heroku --HEAD
==> Installing dependencies for heroku: node
==> Installing heroku dependency: node
==> Downloading https://nodejs.org/dist/v8.4.0/node-v8.4.0.tar.xz
Already downloaded: /Users/kencooper/Library/Caches/Homebrew/node-8.4.0.tar.xz
==> ./configure --prefix=/usr/local/Cellar/node/8.4.0 --without-npm --with-intl=system-icu
==> make install
Last 15 lines from /Users/kencooper/Library/Logs/Homebrew/node/02.make:
      v8::internal::(anonymous namespace)::SetResolvedDateSettings(v8::internal::Isolate*, icu_59::Locale const&, icu_59::SimpleDateFormat*, v8::internal::Handle<v8::internal::JSObject>) in libv8_base.a(intl-objects.o)
      v8::internal::(anonymous namespace)::SetResolvedNumberSettings(v8::internal::Isolate*, icu_59::Locale const&, icu_59::DecimalFormat*, v8::internal::Handle<v8::internal::JSObject>) in libv8_base.a(intl-objects.o)
      v8::internal::(anonymous namespace)::SetResolvedCollatorSettings(v8::internal::Isolate*, icu_59::Locale const&, icu_59::Collator*, v8::internal::Handle<v8::internal::JSObject>) in libv8_base.a(intl-objects.o)
      v8::internal::(anonymous namespace)::SetResolvedBreakIteratorSettings(v8::internal::Isolate*, icu_59::Locale const&, icu_59::BreakIterator*, v8::internal::Handle<v8::internal::JSObject>) in libv8_base.a(intl-objects.o)
      v8::internal::Runtime_CanonicalizeLanguageTag(int, v8::internal::Object**, v8::internal::Isolate*) in libv8_base.a(runtime-intl.o)
      v8::internal::Stats_Runtime_CanonicalizeLanguageTag(int, v8::internal::Object**, v8::internal::Isolate*) in libv8_base.a(runtime-intl.o)
      v8::internal::Runtime_AvailableLocalesOf(int, v8::internal::Object**, v8::internal::Isolate*) in libv8_base.a(runtime-intl.o)
      ...
  "_ulocdata_getCLDRVersion_59", referenced from:
      node::i18n::(anonymous namespace)::GetVersion(v8::FunctionCallbackInfo<v8::Value> const&) in node_i18n.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[1]: *** [/private/tmp/node-20170904-56294-1qjc8jf/node-v8.4.0/out/Release/node] Error 1
rm 58c822d65a20139d08a95902da4644da971bee39.intermediate
make: *** [node] Error 2

Any hints? TIA, scratching my head now. Config follows.

screen shot 2017-09-04 at 5 27 03 pm

brew config
HOMEBREW_VERSION: 1.3.2-2-ge777010
ORIGIN: https://github.com/Homebrew/brew.git
HEAD: e77701075606cbcf3075d7fcc123556b63977bcf
Last commit: 7 hours ago
Core tap ORIGIN: https://github.com/Homebrew/homebrew-core
Core tap HEAD: 75d2a4a97f5e008120a603807131c185bf18dc00
Core tap last commit: 88 minutes ago
HOMEBREW_PREFIX: /usr/local
HOMEBREW_REPOSITORY: /usr/local/Homebrew
HOMEBREW_CELLAR: /usr/local/Cellar
HOMEBREW_BOTTLE_DOMAIN: https://homebrew.bintray.com
CPU: octa-core 64-bit dunno
Homebrew Ruby: 2.3.3 => /System/Library/Frameworks/Ruby.framework/Versions/2.3/usr/bin/ruby
Clang: 9.0 build 900
Git: 2.14.1 => /usr/local/bin/git
Perl: /usr/bin/perl
Python: /usr/bin/python
Ruby: /usr/bin/ruby => /System/Library/Frameworks/Ruby.framework/Versions/2.3/usr/bin/ruby
Java: 1.8.0_60, 1.8.0_05, 1.7.0_51, 1.7.0_21
macOS: 10.13-x86_64
Xcode: 9.0
CLT: N/A
X11: 2.7.11 => /opt/X11
@SConaway

This comment has been minimized.

Copy link
Contributor

commented Sep 5, 2017

OpenSSL seems to fail to build on 10.13db9 17A360a but it works fine with --force-bottle.

Output:

Stevens-MacBook-Pro:~ steven$ brew install python python3
==> Installing dependencies for python: openssl
==> Installing python dependency: openssl
==> Downloading https://www.openssl.org/source/openssl-1.0.2l.tar.gz
Already downloaded: /Users/steven/Library/Caches/Homebrew/openssl-1.0.2l.tar.gz
^C
Stevens-MacBook-Pro:~ steven$ brew install openssl
==> Downloading https://www.openssl.org/source/openssl-1.0.2l.tar.gz
Already downloaded: /Users/steven/Library/Caches/Homebrew/openssl-1.0.2l.tar.gz
==> perl ./Configure --prefix=/usr/local/Cellar/openssl/1.0.2l --openssldir=/usr
==> make depend
==> make
Last 15 lines from /Users/steven/Library/Logs/Homebrew/openssl/03.make:
2017-09-04 17:34:32 -0700

make

making all in crypto...
/usr/bin/perl ../util/mkbuildinf.pl "clang -I. -I.. -I../include  -fPIC -fno-common -DOPENSSL_PIC -DZLIB_SHARED -DZLIB -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -arch x86_64 -O3 -DL_ENDIAN -Wall -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM -DECP_NISTZ256_ASM" "darwin64-x86_64-cc" >buildinf.h
make[1]: *** No rule to make target `6.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.13.sdk/usr/include/Availability.h', needed by `cryptlib.o'.  Stop.
make: *** [build_crypto] Error 1

Do not report this issue to Homebrew/brew or Homebrew/core!

These open issues may also help:
Upgrade to mono 5.2.0.215, fsharp 4.1.25 and add msbuild d15.3 https://github.com/Homebrew/homebrew-core/pull/17435
faust. v2.1.0 and v0.9.90 (new formula) https://github.com/Homebrew/homebrew-core/pull/16724
First issues with macOS 10.13 High Sierra https://github.com/Homebrew/homebrew-core/issues/14418
xerces-c 3.2.0 https://github.com/Homebrew/homebrew-core/pull/17371
Formulae affected by Homebrew/brew#2482 https://github.com/Homebrew/homebrew-core/issues/13133
php: 7.1 (new formula) https://github.com/Homebrew/homebrew-core/pull/16067
hadoop 2.8.1 failed to install on 10.12.6 https://github.com/Homebrew/homebrew-core/issues/17065

Error: You are using macOS 10.13.
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.

Error: You are using macOS 10.13.
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.
@DomT4

This comment has been minimized.

Copy link
Contributor

commented Sep 5, 2017

It's useful if people provide brew gist-logs of failed builds. There's a fair bit more information in there than just the failure. Also useful is a reading from xcodebuild -version if you're running a system with Xcode present.

@kcoop

This comment has been minimized.

Copy link

commented Sep 5, 2017

Here's the gist for doing a brew install node directly: https://gist.github.com/1fc2dbabc3b0c1f484fd44cbe016818c

and for Xcode:

xcodebuild -version
Xcode 9.0
Build version 9M214v
@DomT4

This comment has been minimized.

Copy link
Contributor

commented Sep 5, 2017

@kcoop I presume you're not running a Hackintosh? (Apparently not. Your screenshot of the overview didn't load last time for some reason, apologies) The CPU: octa-core 64-bit dunno is a little odd.

@SConaway A full brew gist-logs openssl is more useful than the condensed output.

@DomT4

This comment has been minimized.

Copy link
Contributor

commented Sep 5, 2017

FWIW, I'm unable to reproduce any failures with either node or openssl as per:

HOMEBREW_VERSION: 1.3.2-2-ge777010
ORIGIN: https://github.com/Homebrew/brew.git
HEAD: e77701075606cbcf3075d7fcc123556b63977bcf
Last commit: 8 hours ago
Core tap ORIGIN: https://github.com/Homebrew/homebrew-core
Core tap HEAD: 75d2a4a97f5e008120a603807131c185bf18dc00
Core tap last commit: 3 hours ago
HOMEBREW_PREFIX: /usr/local
HOMEBREW_REPOSITORY: /usr/local/Homebrew
HOMEBREW_CELLAR: /usr/local/Cellar
HOMEBREW_BOTTLE_DOMAIN: https://homebrew.bintray.com
CPU: octa-core 64-bit haswell
Homebrew Ruby: 2.3.3 => /System/Library/Frameworks/Ruby.framework/Versions/2.3/usr/bin/ruby
Clang: 9.0 build 900
Git: 2.14.1 => /usr/local/opt/git/bin/git
Perl: /usr/local/bin/perl => /usr/local/Cellar/perl/5.26.0/bin/perl
Python: /usr/local/opt/python/libexec/bin/python => /usr/local/Cellar/python/2.7.13_1/Frameworks/Python.framework/Versions/2.7/bin/python2.7
Ruby: /usr/local/var/rbenv/shims/ruby => /usr/local/var/rbenv/versions/2.4.1/bin/ruby
Java: 1.8.0_141
macOS: 10.13-x86_64
Xcode: 9.0 => /Applications/Xcode-beta.app/Contents/Developer
CLT: 9.0.0.0.1.1503068762
X11: N/A

I refused the upgrade to APFS though, but if it was related to APFS I'd be surprised if we hadn't heard about it by now with a wad of issue reports despite the "do not report this" message.

@kcoop

This comment has been minimized.

Copy link

commented Sep 5, 2017

@DomtT4, no hackintosh, stock Mid 2017 MBP 15. See screenshot above. Thought that dunno was odd too.

Huh on the lack of repro. Any thoughts on approaches for further debugging this?

@DomT4

This comment has been minimized.

Copy link
Contributor

commented Sep 5, 2017

Yeah reloaded the page & your screenshot popped up. Not sure why it didn't load the first time. Small hunch, what does sysctl -n machdep.cpu.brand_string return for you? If it returns what I think it's going to return it's probably unrelated to the failure, sadly.

Any thoughts on approaches for further debugging this?

Is this the same failure as when icu4c isn't linked or is that failure different?

@DomT4 DomT4 referenced this issue Sep 5, 2017

Merged

mac/hardware/cpu: recognise Kaby Lake #3125

4 of 4 tasks complete
@kcoop

This comment has been minimized.

Copy link

commented Sep 5, 2017

sysctl -n machdep.cpu.brand_string
Intel(R) Core(TM) i7-7700HQ CPU @ 2.80GHz

The icu4c failure was different. Error was that the compiler was missing unicode/version.h. Linking fixed that, put the .h files in the search path. Can add a gist for that if you like, but here's the essence of the failure:

In file included from ../deps/v8/src/assembler.cc:95:
../deps/v8/src/intl.h:14:10: fatal error: 'unicode/uversion.h' file not found
#include "unicode/uversion.h"
         ^~~~~~~~~~~~~~~~~~~~
1 error generated.
make[1]: *** [/private/tmp/node-20170904-19246-r81s6n/node-v8.4.0/out/Release/obj.target/v8_base/deps/v8/src/assembler.o] Error 1
make[1]: *** Waiting for unfinished jobs....
rm ff934aa2c35ff414fa4d1a0f92c22012fa1d3de8.intermediate
make: *** [node] Error 2

I should mention that this is all happening after a transfer using the migration assistant to a new machine (both running High Sierra beta). From a machine that has been building cruft over the years. I ran brew doctor a number of times, fixed a bunch of errors by uninstalling and reinstalling various targets. But as you can see from the gist, it's now down to just the ruby version and the warning about running a beta.

@fxcoudert

This comment has been minimized.

Copy link
Member Author

commented Sep 5, 2017

@SConaway this appears to be an issue specific to your configuration or your machine. Please open a new issue, fill out the complete template (including brew doctor, brew config output), and provide a link to logs.

The error message No rule to make target '6.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.13.sdk/usr/include/Availability.h' makes me think that you have an Xcode app bundle that includes a space in its name (maybe Xcode-beta 6.app?) and openssl build system isn't smart enough to handle it.

@fxcoudert

This comment has been minimized.

Copy link
Member Author

commented Sep 5, 2017

@kcoop this appears to be an issue specific to your configuration or your machine. Please open a new issue (CC'ing me), fill out the complete template (including brew doctor, brew config output), and provide a link to logs.

Also, can you check that you have only one version of icu4c installed, and that it's linked? Can you also reinstall it, building from source?

@kcoop

This comment has been minimized.

Copy link

commented Sep 5, 2017

@fxcoudert, I've uninstalled and reinstalled icu4c using brew install icu4c, which IIRC is compiling from source. If I don't explicitly brew link icu4c, I get that different error installing node (the one mentioned above):

In file included from ../deps/v8/src/assembler.cc:95:
../deps/v8/src/intl.h:14:10: fatal error: 'unicode/uversion.h' file not found
#include "unicode/uversion.h"
         ^~~~~~~~~~~~~~~~~~~~
1 error generated.

BTW, in the process of trying to get as pristine as possible with brew doctor to create a new issue, it tells me to unlink icu4c.

Also, not to pile on, maybe it's relevant, I've been trying to fix this brew doctor warning:

Warning: Ruby version 2.3.3 is unsupported on 10.13. Homebrew
is developed and tested on Ruby 2.0, and may not work correctly
on other Rubies. Patches are accepted as long as they don't cause breakage
on supported Rubies.

I tried updating ruby with brew install ruby (hoping it'd install a version appropriate for brew), but the message persists.

And the following shows

/usr/local/bin/ruby --version
ruby 2.4.1p111 (2017-03-22 revision 58053) [x86_64-darwin17]

but oddly just plain

ruby --version
ruby 2.3.3p222 (2016-11-21 revision 56859) [universal.x86_64-darwin17]

and yet

which ruby
/usr/local/bin/ruby
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
You can’t perform that action at this time.