search

Homebrew / homebrew-core

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

First issues with macOS 10.13 High Sierra #14418

Closed fxcoudert closed 6 years ago

fxcoudert commented 6 years ago

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

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

Are you running in a VM?

fxcoudert commented 6 years ago

Are you running in a VM?

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

MikeMcQuaid commented 6 years ago

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

fxcoudert commented 6 years ago

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
chapeladmin commented 6 years ago

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

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 commented 6 years ago
fxcoudert commented 6 years ago
DomT4 commented 6 years ago

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

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

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

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:

fxcoudert commented 6 years ago

Other failures and links to logs:

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

fxcoudert commented 6 years ago

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

MikeMcQuaid commented 6 years ago

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

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

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

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

chapeladmin commented 6 years ago

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

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

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

Anyway to manually build this particular item?

sunipkm commented 6 years ago

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

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

DomT4 commented 6 years ago

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

idyll commented 6 years ago

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

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

FYI: lftp is also broken 😕

savemeaspark commented 6 years ago

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
DomT4 commented 6 years ago

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.

It's not you. It's because the mod_suexec formula has macOS version-specific url and sha256 blocks, and currently does not have one for High Sierra, thus, the syntax is "invalid". It's a simple fix for someone but that tap seems to be at least semi-dead.

JCount commented 6 years ago

If anyone would like to test the fixes in #15129 it would be most welcome.

selfagency commented 6 years ago

bison appears to be working now thanks to a snfprintf patch from macports. libunistring is still shot so no gpg still. 😕

ilovezfs commented 6 years ago

@selfagency correct. libunistring wasn't in JCount's PR, so we know that.

JCount commented 6 years ago

@selfagency See #15174

david50407 commented 6 years ago

cmake broken:

==> Installing crystal-lang dependency: cmake
==> Downloading https://cmake.org/files/v3.8/cmake-3.8.2.tar.gz
######################################################################## 100.0%
==> ./bootstrap --prefix=/usr/local/Cellar/cmake/3.8.2 --no-system-libs --parall
Last 15 lines from /Users/Davy/Library/Logs/Homebrew/cmake/01.bootstrap:
  but not all the files it references.

Call Stack (most recent call first):
  /usr/local/lib/cmake/Qt5Core/Qt5CoreConfigExtras.cmake:50 (_qt5_Core_check_file_exists)
  /usr/local/lib/cmake/Qt5Core/Qt5CoreConfig.cmake:141 (include)
  Tests/RunCMake/CMakeLists.txt:248 (find_package)

-- Configuring incomplete, errors occurred!
See also "/tmp/cmake-20170701-6259-1aapz08/cmake-3.8.2/CMakeFiles/CMakeOutput.log".
See also "/tmp/cmake-20170701-6259-1aapz08/cmake-3.8.2/CMakeFiles/CMakeError.log".
---------------------------------------------
Error when bootstrapping CMake:
Problem while running initial CMake
---------------------------------------------

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

These open issues may also help:
glog.rb add test, use cmake build to generate cmake config files. https://github.com/Homebrew/homebrew-core/pull/14379
CMake modules for TBB do not get installed https://github.com/Homebrew/homebrew-core/issues/14938

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.

And there is no log files on mentioned location.

wyteco commented 6 years ago

Got it fixed! Add OS_ACTIVITY_MODEas an environment variable with the value disable in the scheme editor at "Run". That might not be a permanent fix but for now it works, I guess.

selfagency commented 6 years ago

gnupg installs successfully with the fix to libunistring! thanks for all your work on this y'all.

ilovezfs commented 6 years ago

I can avoid the "brew test glib fails because it cannot find -lglib-2.0 (no -L is provided in the test)" issue by setting

    ENV["SDKROOT"] = "/"

at the top of the test block. Setting that for all test blocks globally might be preferable to running around adding -L#{lib} everywhere.

ilovezfs commented 6 years ago

@fxcoudert are you still able to reproduce the issue with Python? It appears to be fine to me.

ilovezfs commented 6 years ago

These all probably need fixing due to the -L#{lib} apocalypse:

ilovezfs commented 6 years ago

@fxcoudert are you still able to reproduce the shared-mime-info issue? It seems fine to me.

ilovezfs commented 6 years ago

@fxcoudert same question regarding macvim. Seems fine.

ilovezfs commented 6 years ago

@Korni22 @JCount it looks like lftp is yet another %n issue.

idyll commented 6 years ago

The Erlang team has a PR open with a fix for the BoringSSL linking issue. https://github.com/erlang/otp/pull/1501/commits/882c90f72ba4e298aa5a7796661c28053c540a96

It may be useful for other projects with this issue so I wanted to crosspost here.

I am going to try to update the erlang@19 and erlang formula to include a patch and test on 10.12 to verify things work and then open a PR with them.

ilovezfs commented 6 years ago

@idyll thanks! No love for erlang@18? :smiling_imp:

idyll commented 6 years ago

Do you want love for erlang@18? I don't use it. But I can back port for it too...

ilovezfs commented 6 years ago

It would be much appreciated!

JCount commented 6 years ago

@Korni22 #15306 should make lftp runnable if you want to try testing/using it. The test block now passes, but I haven't done any testing beyond that.

Korni22 commented 6 years ago

@JCount 

korni22@Erics-MBPr ~ $ brew install --build-from-source lftp
==> Using the sandbox
==> Downloading https://lftp.yar.ru/ftp/lftp-4.7.7.tar.bz2
Already downloaded: /Users/korni22/Library/Caches/Homebrew/lftp-4.7.7.tar.bz2
==> Downloading https://raw.githubusercontent.com/macports/macports-ports/edf0ee1e2cf/devel/m4/files/secure_snprintf.patch
######################################################################## 100,0%
==> Patching
==> Applying secure_snprintf.patch
patching file lib/vasnprintf.c
Hunk #1 succeeded at 4858 (offset -11 lines).
==> ./configure --prefix=/usr/local/Cellar/lftp/4.7.7 --with-openssl=/usr/local/opt/openssl --with-readline=/usr/local/opt/readline --with-libidn=/usr/local/opt/libidn
==> make install
🍺  /usr/local/Cellar/lftp/4.7.7: 21 files, 2.5MB, built in 1 minute 54 seconds
korni22@Erics-MBPr ~ $ lftp
lftp :~> exit

works fine, thanks a lot!

zmwangx commented 6 years ago

optipng #15419.

copumpkin commented 6 years ago

The libunistring failures all come from the system's snfprintf

@fxcoudert I'm seeing the exact same thing in a non-homebrew setting in 10.13, so I'm guessing something deeper has changed in 10.13.

@chapeladmin any word on the Apple bug you submitted on that illegal instruction?

Edit: just saw this, sorry!

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.