Homebrew-core: macOS 10.14 tracking issue

I can't get subversion to build on 10.14. It craps out during the swig bindings stage IIRC. I'll try and produce a full build log whenever I work out why my VM has suddenly lost the ability to connect to the internet 🙃.

did you install /Library/Developer/CommandLineTools/Packages/macOS_SDK_headers_for_macOS_10.14.pkg yet?

No. I'll do that & see how it goes. (I really can't work out what they're trying to achieve with the CLT changes in 10.14 but 🤷‍♂️)

Yeah, that resolved the issue.

does https://github.com/Homebrew/brew/pull/4299 also resolve it without macOS_SDK_headers_for_macOS_10.14.pkg ?

Is there a clean way to uninstall macOS_SDK_headers_for_macOS_10.14.pkg without having to disable system integrity & manually wipe out /usr/include?

I don't know whether pkgutil --unlink still works despite having been made undocumented. Maybe?

btw csrutil enable --without fs can ease testing without complete SIPlessness

sudo pkgutil --unlink com.apple.pkg.CLTools_Executables seems to do nothing at least, and apparently that's the right one to aim for:

pkgutil --file-info /Library/Developer/CommandLineTools/Packages/macOS_SDK_headers_for_macOS_10.14.pkg

pkgid: com.apple.pkg.CLTools_Executables
pkg-version: 10.0.0.0.1.1527767617
install-time: 1528420005
uid: 0
gid: 80
mode: 644

I don't mind disabling SIP entirely/partially as it's only a VM; was just wondering if I could avoid rebooting the thing really, heh.

Somehow subversion is now building fine, without that PR & with /usr/include killed. Cue confusion.

nettle fails to build on the make check stage:

PASS: ecdh
PASS: eddsa-compress
PASS: eddsa-sign
PASS: eddsa-verify
PASS: ed25519
PASS: cxx
PASS: sexp-conv
PASS: pkcs1-conv
PASS: nettle-pbkdf2
Exported symbols in libnettle.a, lacking the nettle prefix:
00000000000001b0 T ____chkstk_darwin
0000000000000230 T ____chkstk_darwin
0000000000000350 T ____chkstk_darwin
0000000000000360 T ____chkstk_darwin
0000000000000380 T ____chkstk_darwin
FAIL: symbols
PASS: dlopen
====================
1 of 94 tests failed
====================
make[1]: *** [check] Error 1
make: *** [check] Error 2

00000000000001b0 T ____chkstk_darwin
0000000000000230 T ____chkstk_darwin
0000000000000350 T ____chkstk_darwin
0000000000000360 T ____chkstk_darwin
0000000000000380 T ____chkstk_darwin

This may be from the new LLVM version; it looks like the ___chkstk_darwin function was added as a part of stack checking. Essentially every binary compiled with Xcode 10 has ___chkstk_darwin.

I found a reference to this in this LLVM code review: https://reviews.llvm.org/D40857

Thanks! That does indeed seem to be the case, poking around with nm. It looks like it only creeps into most rather than all libraries/binaries; I'm not sure why it doesn't appear completely consistently.

I've opened a PR with a tested fix in https://github.com/Homebrew/homebrew-core/pull/28958. Are we reporting this stuff upstream yet or waiting to see what happens over time?

Are we reporting this stuff upstream yet or waiting to see what happens over time?

I'm reporting things that have been documented in release notes or otherwise seem to be intentional, and stuff that might not be I'm going to let sit for a few betas to see what happens. Not sure where this one falls, tbh!

There is an issue with tar archives containing multiple files with different cases on APFS case-insensitive filesystems, such as gobject-introspection (gobject-introspection-1.56.1/docs/reference/html/gi-gitypelib.html). It will fail with "Can't unlink already-existing object".

EASY WAY OUT for users: brew install <formulae_name> --force-bottle

FIX for developers/build-from-source: Install 10.14 Beta 6.

HACK for developers/build-from-source for 10.14 Beta 5 and lower: Install libarchive, then in /usr/local/Homebrew/Library/Homebrew/unpack_strategy/tar.rb in line 17 change "xf" to "xfk" and in line 17 change "tar" to "/usr/local/opt/libarchive/bin/tar".

Hi @uyjulian I'm trying to install emacs-plus from d12frosted/emacs-plus cask... I'm getting gobject-introspection-1.56.1/docs/reference/html/gi-gitypelib.html: Can't unlink already-existing object

How wouid I go about fixing this? Where do I find download_strategy.rb? I'm really new to homebrew, any help would be greatly appreciated. Cheers!

@lukeberry99 /usr/local/Homebrew/Library/Homebrew/download_strategy.rb

You could have also found it yourself by running mdfind download_strategy.rb

I've noticed a few weird issues. Files and directories are installing with weird permissions. Sometimes 0444, sometimes 0555. I've also had a similar issue to https://github.com/Homebrew/legacy-homebrew/issues/40653 when trying to compile exa and the same workaround worked.

Exa also won't reinstall if its bin directory is not empty and won't install if it's bin directory does not exist. I had to uninstall exa and manually create the /usr/local/Cellar/exa/0.8.0/bin directory and then use brew reinstall instead of install because I guess the existence of the /usr/local/Cellar/exa/0.8.0 is enough to make brew think it is already installed.

I've also had issues where a package will fail to reinstall only to work the next time without changing anything.

Figured maybe something was wrong with my environment but brew doctor only gives a few warnings about some third party libraries present and the fact I'm running 10.14. I'm not sure what else to check.

I've also had a similar issue to Homebrew/legacy-homebrew#40653 when trying to compile exa and the same workaround worked.

Filed a radar: rdar://41651999. It looks like libgcc_s.10.4 and libgcc_s.10.5 are missing. Certain clang flags causes it to try to link against them - specifically values for --target. Namely:

• --target=x86_64-apple-darwin - tries to link against libgcc_s.10.4
• --target=x86_64-apple-darwin4 through --target=x86_64-apple-darwin8 - tries to link against libgcc_s.10.4
• --target=x86_64-apple-darwin9 - tries to link against libgcc_s.10.5

This makes sense since Mac OS X 10.0 was Darwin 4, 10.4 was Darwin 8, 10.5 was Darwin 9, etc. It tracks that it tries to link against those specific libgcc_s versions for those targets. exa trying to pass --target=x86_64-apple-darwin is probably having the unexpected effect of it ending up targeting a very old OS X libc version, which is not obvious. It works as long as the stub libgcc_s files exist, and fails if they're gone.

@uyjulian @lukeberry99 This is the same issue as the texi2html bug we've got in the list. I've filed a radar already, so I expect to see it fixed in an upcoming beta.

@theeternalsw0rd I can't reproduce your permissions issues. I'll need your brew gist-logs exa and some more info about your setup to diagnose.

Hi @uyjulian regarding the gobject-introspection-1.56.1/docs/reference/html/gi-gitypelib.html). It will fail with "Can't unlink already-existing object issue, i am facing this error too and trying to edit the .rb file. When you say add "k" at line 236 you are saying "xk" or replace the "x" with "k" or some << k. I did not get that part. I am stuck at this error.

@karanmartian Set it to "xk"

@mistydemeo my other permissions issues didn't show up after the latest Xcode beta update. Still have the issue with exa though https://gist.github.com/theeternalsw0rd/d714c0935c32ef4a15516cca52e4e9cd (I get the same error whether installing or reinstalling so I'm only including an attempted reinstall)

exiftool won't build due to a lack of config.h for the system perl. I'm waiting on filing a bug with Apple until I've installed the latest OS build.

@uyjulian I made the required change using nano editor on the two lines in homebrew’s download_strategy.rb. nano allows me to save it but somehow the file is reverted back to the original version when the error shows up again on bash. Its not sticking..

You have to set HOMEBREW_DEVELOPER=1 in the environment or have used any brew developer command ever to suppress that behavior.

Ok I set the that env variable to 1 and edited and now I get all sorts of errors in the syntax on bash:

/System/Library/Frameworks/Ruby.framework/Versions/2.3/usr/lib/ruby/2.3.0/rubygems/core_ext/kernel_require.rb:55:in require': /usr/local/Homebrew/Library/Homebrew/download_strategy.rb:194: syntax error, unexpected << (SyntaxError) <<<<<<< Updated upstream

Please fix your comment by adding `` around the output.

Do cd /usr/local/Homebrew && git checkout master * then try again.

Hi thanks that worked. It was different line numbers though and not 236 and 248 and I had to change "tar" to "/usr/local/bin/tar" and "xf" to "xkf"

exiftool won't build due to a lack of config.h for the system perl. I'm waiting on filing a bug with Apple until I've installed the latest OS build.

Ref: https://github.com/Homebrew/homebrew-core/issues/29835#issuecomment-403239244. Seems to be in the CLT but not in /System.

@karanmartian can you do the following and paste? Thanks!

git diff /usr/local/Homebrew/Library/Homebrew/download_strategy.rb

@DomT4 it seems they have forgotten about perl in their macOS_SDK_headers_for_macOS_10.14.pkg installer. I'm wondering though if with 10.14 it might be prudent to update include paths to use the CLT directories instead of /usr. Wouldn't surprise me if they stopped including a headers package entirely in a future release.

I'm wondering though if with 10.14 it might be prudent to update include paths to use the CLT directories instead of /usr

Misty has been doing some work on this IIRC and I don't want to leap over that so I'll let Misty comment as desired.

Homebrew has done a number of things over time with setting SDK paths/hints/etc and it has tended to cause significant complication & confusion, so making major brew changes this early in the release cycle makes me a _tad_ nervous, but I'm content deferring to Misty's massively superior know-how here.

On the Perl issue alone I would be amazed if this wasn't fixed fairly quickly. As a personal aside I'm certainly not about to start writing Apple thank you messages if they make Homebrew enforce a perl dependency universally.

Still seeing this issue in the new OSX beta 18A326h

I'm wondering though if with 10.14 it might be prudent to update include paths to use the CLT directories instead of /usr

This is the plan. It doesn't appear that the header package will be available going forward, so I've prepared a PR that treats the CLT with the SDK and no /usr headers the same way that we treat Xcode-only systems today. https://github.com/Homebrew/brew/pull/4335

We may also look at alternate ways of implementing this.

I've got an issue with upgrading packages. I'm running the latest beta versions of MacOs and Xcode (10.14 Public beta 2 and 10.0 beta 3).

However whenever I'm trying to run brew upgrade. Homebrew reports that I'm running an older version of Xcode (9.4.1) which I've also got installed:

$ brew upgrade
Updating Homebrew...
==> Auto-updated Homebrew!
Updated 1 tap (homebrew/core).
==> Updated Formulae
skaffold                                                    teleport

==> Upgrading 13 outdated packages, with result:
python@2 2.7.15 -> 2.7.15_1, gdbm 1.14.1_1 -> 1.16, python 3.6.5 -> 3.7.0, mill 0.2.3 -> 0.2.4, maven 3.5.3 -> 3.5.4, icu4c 61.1 -> 62.1, fwup 1.2.0 -> 1.2.1, readline 7.0.3_1 -> 7.0.5, libgpg-error 1.31 -> 1.32, curl 7.60.0 -> 7.61.0, gnupg 2.2.8 -> 2.2.9, fswatch 1.11.3 -> 1.12.0, git 2.17.1 -> 2.18.0
==> Upgrading readline 
Error: Your Xcode (9.4.1) is too outdated.
Please update to Xcode 10.0 (or delete it).
Xcode can be updated from
  https://developer.apple.com/download/more/

Has anyone else had this issue?

@irundaia what does brew config show? And xcode-select -p?

@ilovezfs, ah I see the problem... xcode-select -p returns the default Xcode.

I've updated it with xcode-select -s /Applications/Xcode-beta.app/Contents/Developer. That fixed my issues. Thanks!

For completeness, I've included the output of brew config

$ brew config
HOMEBREW_VERSION: 1.6.15
ORIGIN: https://github.com/Homebrew/brew
HEAD: 5c2aaef22f697d451dc3412b5c6e9a6300e2a809
Last commit: 19 hours ago
Core tap ORIGIN: https://github.com/Homebrew/homebrew-core
Core tap HEAD: 3df9465b4c900bc746fc14e52bf1b0a30ed1e538
Core tap last commit: 62 minutes ago
HOMEBREW_PREFIX: /usr/local
CPU: octa-core 64-bit haswell
Homebrew Ruby: 2.3.7 => /System/Library/Frameworks/Ruby.framework/Versions/2.3/usr/bin/ruby
Clang: 9.1 build 902
Git: 2.17.1 => /usr/local/bin/git
Curl: 7.54.0 => /usr/bin/curl
Java: 9, 1.8.0_102
macOS: 10.14-x86_64
CLT: 10.0.0.0.1.1530455945
CLT headers: 10.0.0.0.1.1530455945
Xcode: 9.4.1
XQuartz: 2.7.11 => /opt/X11

I couldn't get Cairo to compile. It was returning an error like:

"XXX: No mutex implementation found.  Cairo will not work with multiple threads.  Define CAIRO_NO_MUTEX to 1 to acknowledge and accept this limitation and compile cairo without thread-safety support.

It turns out that Cairo has some very draconian checks to see if ld returns any errors, and some unrelated ruby errors were getting caught in the crossfire.

The gems errors looked like this for me:

Ignoring bcrypt-3.1.11 because its extensions are not built.  Try: gem pristine bcrypt --version 3.1.11
Ignoring bcrypt_pbkdf-1.0.0 because its extensions are not built.  Try: gem pristine bcrypt_pbkdf --version 1.0.0

the fix was removing the gems that were compiled against the previous ruby. Especially the ones that got installed to the strange Library path when I must have accidentally ran 'sudo gem install' in the past.

rm -rf ~/.gems
sudo rm -rf /Library/Ruby/Gems/*

Node's bundled npm has the same version detection bug as node itself

npm 6.2.0 is now stable with an updated node-gyp. We could use this (on 10.14 only?) instead of the current 6.1.0 version to fix these issues.

All variants of --target=x86_64-apple-darwin now work as of the latest beta.

A temp solution

Disk Utility / File / New Image / Blank Image,
create a new "Untitled.dmg" file (format: Mac OS Extended Case-sensitive, Journaled),
and open it.

then:

cd /Volumes/Untitled/

tar_filename="gobject-introspection-1.56.1.tar.xz"
brew_cache_file=~/Library/Caches/Homebrew/$tar_filename

### 1. extarct the .tar archive
cp $brew_cache_file ./
tar xf *.tar.xz
rm $tar_filename

### 2. remove the "bad" file
find . -iname "gi-gitypelib.html"
# remove or rename one dup file above. like this:
find . -name "gi-gitypelib.html" -exec rm {} \;

### 3. copy new re-tar file to dest path
tar cfJ $tar_filename gobject-introspection-1.56.1
cp *.tar.xz $brew_cache_file

### 4. update the sha256sum for "brew install"
shasum -a 256 $brew_cache_file
# update the new sha256sum value to file below:
# /usr/local/Homebrew/Library/Taps/homebrew/homebrew-core/Formula/gobject-introspection.rb:5

HOMEBREW_NO_AUTO_UPDATE=1 brew install gobject-introspection
# DONE

Sorry for disrupting. I have installed the latest version: Mojave beta4 in my MacBook Pro in this morning. When I wanna config gtk+ in my computer and typed "brew install gtk+" in my terminal, it popped up with
"gobject-introspection-1.56.1/docs/reference/html/gi-gitypelib.html: Can't unlink already-existing object
tar: Error exit delayed from previous errors.
Error: Failure while executing: tar xf /Users/wangyifan/Library/Caches/Homebrew/gobject-introspection-1.56.1.tar.xz -C /private/tmp/gobject-introspection-20180718-13791-1cdklc5"
I don't how to fix this problem.

@macwish @HyperopiaEvan Easy/ier fix: https://github.com/Homebrew/homebrew-core/issues/28817#issuecomment-399721574

hi @uyjulian , the HACK not working for my situation.

download_strategy.rb in line 236 add "k" and in line 248 change "tar" to "/usr/local/bin/tar".

There is no "tar" string in my download_strategy.rb file.

@uyjulian I don't find the words I want in the download_strategy.rb file
This is my file (convert into .txt
download_strategy.txt
)

@HyperopiaEvan Wrong file, look at /usr/local/Homebrew/Library/Homebrew/download_strategy.rb
It might be helpful to read the entire thread before you reply to see if it's reported already and the solution

@uyjulian And...what does the " link it with --force" mean...
I have installed the libarchive on my computer with the command line.
Sorry, I am really new to homebrew

@HyperopiaEvan brew link libarchive --force
Would you like to continue this conversation in an e-mail? (my username) at gmail dot com

I don't see "tar" or "xf" in my download_strategy.rb file.

did this get moved to unpack_strategy.rb, around line 180?

HOMEBREW_VERSION: 1.7.0-42-g41680cd
ORIGIN: https://github.com/Homebrew/brew
HEAD: 41680cd23915e8a1cca5f4945d3ec34d7dea3e82
Last commit: 3 hours ago
Core tap ORIGIN: https://github.com/Homebrew/homebrew-core
Core tap HEAD: 43df76afe8839468d7518152ee2cf68d58a161f9
Core tap last commit: 38 minutes ago
HOMEBREW_PREFIX: /usr/local
HOMEBREW_DEV_CMD_RUN: 1
CPU: quad-core 64-bit kabylake
Homebrew Ruby: 2.3.7 => /System/Library/Frameworks/Ruby.framework/Versions/2.3/usr/bin/ruby
Clang: 10.0 build 1000
Git: 2.18.0 => /usr/local/bin/git
Curl: 7.54.0 => /usr/bin/curl
Java: 10.0.1, 1.8.0_181
macOS: 10.14-x86_64
CLT: 10.0.0.0.1.1531453907
CLT headers: 10.0.0.0.1.1531453907
Xcode: N/A
XQuartz: N/A

Probably. Try it out and see if it works

I can't get the CLT Headers to be recognized... I've ran the package at /Library/Developer/CommandLineTools/Packages/macOS_SDK_headers_for_macOS_10.14.pkg several times, before and after rebooting, as well as downloading the installer from the Apple website.

Here's the output from my brew config:

HOMEBREW_VERSION: 1.7.0
ORIGIN: https://github.com/Homebrew/brew.git
HEAD: 7e8fb9a0f8ab5e841763ec6c7fefa72a8462b594
Last commit: 2 days ago
Core tap ORIGIN: https://github.com/Homebrew/homebrew-core
Core tap HEAD: 91591593c509628300204fb6eb6cd0a85f42eb0f
Core tap last commit: 76 minutes ago
HOMEBREW_PREFIX: /usr/local
CPU: quad-core 64-bit kabylake
Homebrew Ruby: 2.3.7 => /System/Library/Frameworks/Ruby.framework/Versions/2.3/usr/bin/ruby
Clang: 10.0 build 1000
Git: 2.18.0 => /usr/local/bin/git
Curl: 7.54.0 => /usr/bin/curl
Java: 1.8.0_152
macOS: 10.14-x86_64
CLT: 10.0.0.0.1.1529074627
CLT headers: N/A
Xcode: 10.0 => /Applications/Xcode-beta.app/Contents/Developer
XQuartz: N/A

brew link libarchive --force

You won't be able to do this on 10.14.

did this get moved to unpack_strategy.rb

Yes. In the case of gobject-introspection though I'd probably just recommend people do brew install gobject-introspection --force-bottle; that seems to work okay for me on my 10.14 VM.

I've ran the package at /Library/Developer/CommandLineTools/Packages/macOS_SDK_headers_for_macOS_10.14.pkg

What's the output of:

sudo installer -pkg /Library/Developer/CommandLineTools/Packages/macOS_SDK_headers_for_macOS_10.14.pkg -target /

?

@DomT4

[~]$ sudo installer -pkg /Library/Developer/CommandLineTools/Packages/macOS_SDK_headers_for_macOS_10.14.pkg -target /
installer: Package name is macOS_SDK_headers_for_macOS_10.14
installer: Upgrading at base path /
installer: The upgrade was successful.

But afterwards still get CLT headers: N/A in brew config

And brew config after that?

No change...

Hmm. Interesting. Are you running the latest beta _(I think it's 4, but I could be remembering incorrectly)_? My CLT version string is different to your's.

@DomT4 thanks
using force-bottle got me through the error

makes me wonder if there is an issue with 10.14, and honoring the k switch

My XCode is Version 10.0 beta 4 (10L213o).

I downloaded the Command Line Tools (macOS 10.14) for Xcode 10 Beta 2, which is the most recent CLT listed at https://developer.apple.com/download/more/

makes me wonder if there is an issue with 10.14, and honoring the k switch

There seems to be a fairly broad issue with the tar on 10.14 currently; people have been flagging it on brew's discourse as well. I assumed it might be fixed by now but apparently not. The version seems to be identical to 10.13.6 so I'm not quite sure what has gone awry.

I downloaded the Command Line Tools (macOS 10.14) for Xcode 10 Beta 2, which is the most recent CLT listed at

Do you have the panel under System Preferences => Software Update? I'm wondering whether you're stuck on the old header package, which Homebrew no longer recognises as valid because the newer header package moved to a new identifier.

_Edit - Accidentally pluralised package._

@DomT4 Thanks! That looks like it did it... I was looking for the update in the standard old place in the App Store

👍 Nice. I'm not sure they announced the new update location under System Preferences so I'm _hoping_ people are generally managing to find it okay.

even after installing macOS_SDK_headers_for_macOS_10.14.pkg
getting same error Error: The Command Line Tools header package must be installed on Mojave.
The installer is located at:
/Library/Developer/CommandLineTools/Packages/macOS_SDK_headers_for_macOS_10.14.pkg

@omi10859:

Check this isn't the case

Do you have the panel under System Preferences => Software Update? I'm wondering whether you're stuck on the old header package, which Homebrew no longer recognises as valid because the newer header package moved to a new identifier.

texi2html's tarball cannot be extracted by the system tar or GNU tar - #29340

This bug is fixed as of beta 6. Confirmed several of the problematic tarballs, including texi2html and Cheetah, now work fine.

I cannot seem to be able to build from source. Using --build-from-source or -s installs bottles from 10.13.

@theeternalsw0rd Enable dev mode.

Can you point me to documentation on this update? There's nothing in the manpage or in the readme. Definitely unintuitive to have to pass another flag or set a config option.

@theeternalsw0rd
From https://docs.brew.sh/Manpage:

HOMEBREW_DEVELOPER: If set, Homebrew will tweak behaviour to be more relevant for Homebrew developers (active or budding) e.g. turning warnings into errors.

It helps if you use ⌘F to search "dev"; it's the 20th result.

Building from source is an advanced/developer option, so it's disabled by default even with HOMEBREW_BUILD_FROM_SOURCE or --build-from-source, and some formulae have issues building from source on Mojave, so the High Sierra bottle is installed.

That does work, so manpage should be updated to reflect that --build-from-source requires HOMEBREW_DEVELOPER to be 1 now. Should I file as separate issue and should it be here or Homebrew/brew ?

System tar does not work with .deb files. Example package zsh-lovers. I switched to using ar x instead of tar xf which works. Not sure of backwards compatibility on that change.

That does work, so manpage should be updated to reflect that --build-from-source requires HOMEBREW_DEVELOPER to be 1 now. Should I file as separate issue and should it be here or Homebrew/brew ?

You could file an issue in homebrew/brew to ask for a clarification but personally I think there's a reasonable expectation to have HOMEBREW_DEVELOPER set if you're running Mojave. Mojave support is still a WIP and waiting between tags opens you up to running into bugs days or weeks after they've been caught & fixed.

System tar does not work with .deb files. Example package zsh-lovers. I switched to using ar x instead of tar xf which works

Can't reproduce this one. Are you running the latest beta, and are you still on stable brew rather than master?

You could file an issue in homebrew/brew to ask for a clarification but personally I think there's a reasonable expectation to have HOMEBREW_DEVELOPER set if you're running Mojave. Mojave support is still a WIP and waiting between tags opens you up to running into bugs days or weeks after they've been caught & fixed.

I only say that because it is a change from the last few weeks in terms of requiring HOMEBREW_DEVELOPER so it was unexpected behavior. I'll file that request there.

Can't reproduce this one. Are you running the latest beta, and are you still on stable brew rather than master?

I am on beta 6, xcode beta 5. I'm not sure which branch of brew I was on at the time. Rebuilding some other packages currently. Will retest when I have a chance under both.

I'm also still having issues with installing exa. Seems to be with system /usr/bin/install though as the same happens independent of brew. If no one else is seeing this, maybe my copy is corrupted. Can someone confirm if openssl dgst -sha256 /usr/bin/install returns f41762d62b935e2abdd89c74773d44870bd963d88e71610051588b75f648edab on their system?

zsh-lovers issue appears to have been due to some caching changes between stable and master brew. Not sure why that was the only package I had problems with or why ar x fixed it the first time I tried as it didn't work on subsequent attempts.

The perl situation is still an active issue, annoyingly. The latest postgresql update dies on:

checking for perl.h... no
configure: error: header file <perl.h> is required for Perl

Suspect most users won't notice because of the forcing of bottle upgrades for non-developers but something to be aware of.

I'm also still having issues with installing exa. Seems to be with system /usr/bin/install though as the same happens independent of brew. If no one else is seeing this, maybe my copy is corrupted. Can someone confirm if openssl dgst -sha256 /usr/bin/install returns f41762d62b935e2abdd89c74773d44870bd963d88e71610051588b75f648edab on their system?

==> Summary
🍺  /usr/local/Cellar/exa/0.8.0: 9 files, 1.4MB, built in 3 minutes 47 seconds

SHA256(/usr/bin/install)= f41762d62b935e2abdd89c74773d44870bd963d88e71610051588b75f648edab

As of today, on the CI machines, Ruby fails its test with the following error (https://jenkins.brew.sh/job/Homebrew%20Mojave%20Testing/138/):

==> /usr/local/Cellar/ruby/2.5.1/bin/gem install json
Building native extensions. This could take a while...
Successfully installed json-2.1.0
Parsing documentation for json-2.1.0
Installing ri documentation for json-2.1.0
Done installing documentation for json after 1 seconds
1 gem installed
==> /usr/local/bin/bundle install --binstubs=/private/tmp/ruby-test-20180820-12394-998su7/bin
Fetching gem metadata from https://rubygems.org/.
Resolving dependencies...
Using bundler 1.16.1
Fetching gemoji 3.0.0
Bundler::GemspecError: Could not read gem at
/private/tmp/ruby-test-20180820-12394-998su7/cache/gemoji-3.0.0.gem. It may be
corrupted.
An error occurred while installing gemoji (3.0.0), and Bundler cannot continue.
Make sure that `gem install gemoji -v '3.0.0'` succeeds before bundling.

In Gemfile:
  gemoji
Error: ruby: failed

Php fails to build with (https://jenkins.brew.sh/job/Homebrew%20Mojave%20Testing/141/):

checking for ZLIB support... yes
checking if the location of ZLIB install directory is defined... no
configure: error: Cannot find libz

Python does not build correctly, and is missing Tk (https://jenkins.brew.sh/job/Homebrew%20Mojave%20Testing/142/):

==> /usr/local/Cellar/python/3.7.0/bin/python3.7 -c import tkinter; root = tkinter.Tk()
Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "/usr/local/Cellar/python/3.7.0/Frameworks/Python.framework/Versions/3.7/lib/python3.7/tkinter/__init__.py", line 36, in <module>
    import _tkinter # If this fails your Python may not be configured for Tk
ModuleNotFoundError: No module named '_tkinter'
Error: python: failed

Same thing for Python 2 (https://jenkins.brew.sh/job/Homebrew%20Mojave%20Testing/143/).

GCC cannot install because (https://jenkins.brew.sh/job/Homebrew%20Mojave%20Testing/144/):

The directory that should contain system headers does not exist:
  /usr/include
make[3]: *** [stmp-fixinc] Error 1

Also: wine cannot be built with Xcode 10, because it requires a 32-bit build.

For Python 3, the build finishes like this:

The necessary bits to build these optional modules were not found:
_dbm                  _uuid                 nis                
ossaudiodev           spwd                  zlib               
To find the necessary bits, look in setup.py in detect_modules() for the module's name.


The following modules found by detect_modules() in setup.py, have been
built by the Makefile instead, as configured by the Setup files:
_abc                  atexit                pwd                
time                                                           


Failed to build these modules:
_tkinter                                                       

I know at least _tkinter and zlib are erroneous and should be fixed. What about the others?

As of today, on the CI machines, Ruby fails its test with the following error

I was able to repro this last night, but I no longer can as of this morning. Is it possible something was wrong with Rubygems itself?

Is it possible something was wrong with Rubygems itself?

Queueing another CI build, time will tell :)

Nope, it's still failing on CI. Same error.

• [x] sqlite-analyzer cannot locate /System/Library/Frameworks/Tcl.framework/tclConfig.sh due to the lack of SDK headers. #31700
• [x] libharu cannot locate zlib headers due to the lack of SDK headers. #31701
• [x] ngrep cannot locate libpcap headers due to the lack of SDK headers. #31559
• [x] luajit cannot find the library gcc_s.10.4 as which is obsoleted as of Xcode 10. #31613
• [x] multimarkdown cannot find the library gcc_s.10.4 as which is obsoleted as of Xcode 10. #31702
• [ ] ldid since libstdc++ is dropped as of Xcode 10. #31703

I've noticed some weird behaviours with the latest Xcode-beta release on Mojave. Basically clang and cc doesn't work, but gcc does. When building inside Homebrew, the build of the emacs-mac package from source (brew install emacs-mac --HEAD) will fail, but it builds fine outside. I've tracked down the differences and details here:

https://github.com/railwaycat/homebrew-emacsmacport/issues/141

Not sure if it affects other packages similarily (failing to link with the macOS stuff), but sharing here in case it does.

• [ ] postgresql cannot find perl.h because it is hidden in /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/System/Library/Perl/5.18/darwin-thread-multi-2level/CORE/perl.h

• [ ] carthage builds fine, but the bottle cannot be built because:

Error: Failed changing dylib ID of /usr/local/Cellar/carthage/0.30.1/Frameworks/CarthageKit.framework/Versions/A/Frameworks/Tentacle.framework/Versions/A/Tentacle
  from @rpath/Tentacle.framework/Versions/A/Tentacle
    to /usr/local/opt/carthage/Frameworks/CarthageKit.framework/Versions/A/Frameworks/Tentacle.framework/Versions/A/Tentacle
Error: Failed to fix install linkage

The behaviour of irssi and postgresql around handling perl is in fact a legitimate upstream bug that will need patching & reporting to them; is not an Apple issue to resolve, at least in those two cases.

Haven't checked exiftool locally yet but seems likely it has fallen into the same pattern of assumptions that irssi and postgresql have.

Today's update: we're at 81% Mojave bottling, with 772 remaining bottles missing.

Trying to track what are the most important remaining ones:

• Of the top 100 formulas, there are 5 missing bottles: postgresql vim ruby php telnet
• Of the top 500 formulas, we are missing: postgresql vim ruby php telnet [email protected] carthage neovim node@8 wine [email protected] [email protected] kubernetes-helm ios-deploy dbus luajit [email protected] phantomjs ntfs-3g ethereum node@6 docker-machine-driver-xhyve sshfs grafana postgis sfcgal v8 kibana

If we want to see which missing bottles are affecting many other formulas, here is the list of missing bottles with the corresponding number of direct dependencies:

39 postgresql
23 ruby
14 luajit
14 gtk-doc
13 opam
13 jack
10 meson
8 libmodplug
7 dbus
6 php
4 unbound
4 gtksourceview
3 opencv@2
3 libre
3 berkeley-db@4

We probably want to prioritise those formulas, and open an issue/PR to track them independently.

postgresql and family are fixed, at the cost of the Mojave bottles lacking installed documentation for now.

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.

An update on the remaining Mojave / Xcode 10 issues, with links to the upstream bug reports. By order of install counts:

More than 100 installs per month

• [x] carthage #32544
• [x] phantomjs #32538
• [x] docker-machine-driver-xhyve https://github.com/machine-drivers/docker-machine-driver-xhyve/issues/210
• [x] [email protected] #32565
• [x] pypy #32574
• [x] xctool https://github.com/Homebrew/homebrew-core/pull/32539
• [x] unar https://github.com/Homebrew/homebrew-core/pull/33176
• [ ] pgloader https://github.com/dimitri/pgloader/issues/832
• [x] cockroach https://github.com/cockroachdb/cockroach/issues/30765
• [x] chisel https://github.com/facebook/chisel/issues/249
• [ ] infer https://github.com/facebook/infer/issues/1001
• [x] duti https://github.com/moretension/duti/issues/31
• [ ] perl-build
• [x] salt #33239
• [x] percona-toolkit #33240
• [x] uwsgi #33235
• [x] pypy3 #32574
• [x] graph-tool #32851
• [x] swift #32223
• [x] crosstool-ng
• [x] fpc
• [x] crf++ #33232
• [x] mapnik #33077
• [ ] irrlicht https://sourceforge.net/p/irrlicht/bugs/442/
• [x] makensis https://github.com/Homebrew/brew/issues/4910

10 to 100 installs per month

• [ ] clozure-cl https://github.com/Clozure/ccl/issues/150
• [x] ngspice
• [ ] [email protected]
• [x] opencascade #32454
• [ ] podofo #33237
• [x] bluepill https://github.com/linkedin/bluepill/issues/279 #33322
• [x] gforth
• [x] mytop
• [x] snap7
• [x] dc3dd #33234
• [x] percona-xtrabackup
• [x] innotop
• [x] vice
• [x] ejabberd
• [x] tcc
• [x] afsctool
• [x] tcptrack
• [ ] riak
• [x] sngrep
• [x] mapserver #33276
• [x] pxz deleted, #33243
• [x] libvoikko
• [x] freeipmi
• [x] platypus
• [x] libmxml https://github.com/michaelrsweet/mxml/issues/231
• [ ] postgrest https://github.com/PostgREST/postgrest/issues/1187
• [x] osc
• [x] [email protected]
• [x] taylor
• [x] gpa #33381
• [x] nethack4
• [x] bup
• [x] puzzles
• [x] ppl #32577
• [x] chuck
• [x] apib
• [x] wesnoth #33277
• [x] trafficserver
• [ ] exiftran
• [ ] sfk #33315
• [x] mariadb-connector-odbc
• [x] blink1
• [ ] bigloo #32044
• [ ] wellington https://github.com/wellington/wellington/issues/213
• [x] siril
• [ ] fstar
• [x] fragroute
• [ ] easyrpg-player
• [x] dante
• [x] cpansearch
• [x] pcapplusplus
• [x] tracebox
• [x] reposurgeon
• [ ] auditbeat license issue, see #28995

Less than 10 installs per month

• [ ] xmoto
• [x] rswift https://github.com/mac-cain13/R.swift/issues/449
• [ ] mlkit
• [ ] cspice
• [x] wordplay
• [x] rom-tools
• [x] libmonome
• [ ] clutter-gst
• [ ] np2
• [ ] dnsdist #33712
• [ ] fdroidserver
• [x] corebird #33278
• [ ] ape
• [ ] yacas
• [x] regex-opt
• [ ] apache-brooklyn-cli
• [ ] mosml
• [x] luvit
• [ ] coccinelle
• [ ] serialosc
• [x] open-vcdiff
• [x] lasso
• [x] fizmo
• [x] opensyobon
• [x] nesemu2
• [ ] libetonyek
• [x] sync_gateway
• [x] sary
• [x] lsh
• [x] le

@fxcoudert https://github.com/facebook/chisel/issues/249#issuecomment-428128739
facebook/chisel
Some compiler errors are caused by Xcode new build system.

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.

Closing as Mojave has been released for a while now and thinks are working well. Great work everyone 🎉

I am getting the postgresql/perl issue still, when running brew install postgresql --with-python on Mojave.

checking for perl.h... no
configure: error: header file <perl.h> is required for Perl