Bo98
commented
3 years ago Homebrew’s linkage checker doesn’t support the shared dyld cache yet
It does as of 9c4aaa9719c74b78ff5dca4667788b3426a48678.
Closed claui closed 3 years ago
Bo98
commented
3 years ago Homebrew’s linkage checker doesn’t support the shared dyld cache yet
It does as of 9c4aaa9719c74b78ff5dca4667788b3426a48678.
MikeMcQuaid
commented
3 years ago
- [ ]
install.shdownloads macOS 10.16 CLT
jedisct1
commented
3 years ago libsodium formulae work fine on Apple Silicon.
Both the release and HEAD.
claui
commented
3 years ago Thanks @jedisct1. Noted.
indirect
commented
3 years ago The fiddle issue is fixable by installing HEAD:
$ git clone https://github.com/ruby/fiddle
$ cd fiddle
$ bundle install --path vendor/bundle
$ bundle exec rake build
$ sudo gem install pkg/fiddle-1.0.1.gemOpenSSL works with a workaround config change.
dmzimmerman
commented
3 years ago $ bundle install --vendor/bundle should be $ bundle install --path vendor/bundle, above.
indirect
commented
3 years ago @dmzimmerman thank you, fixed!
claui
commented
3 years ago Updated issue description with @indirect’s workaround. Thanks!
BytesGuy
commented
3 years ago htop seems to work fine, builds to native arm with no problems:
adam@Adams-Mac ~ % file /usr/local/bin/htop
/usr/local/bin/htop: Mach-O 64-bit executable arm64Telnet works but builds for x86_64. PR submitted to build for arm64 https://github.com/Homebrew/homebrew-core/pull/57303
FigBug
commented
3 years ago I'm getting the following error, any idea how to continue?
Error: Could not find an SDK that supports macOS 11.0.
You may have have an outdated or incompatible CLT.
Homebrew found the following SDKs in the CLT install:
10.16
10.15
Please update CLT or uninstall it if no updates are available.@FigBug If you’re on macOS 11, you need Xcode 12 for macOS Universal Apps beta installed. Then run:
sudo xcode-select --switch /Applications/Xcode-beta.app/Contents/Developer@claui I'm running macOS 11.0 Beta (20A5299w) with Xcode 12.0 beta (12A8158a) on the DTK. After running xcode-select as you suggested, I still get the above error.
MikeMcQuaid
commented
3 years ago @FigBug Please don't ask us for help while you're running an unsupported version of macOS.
Bo98
commented
3 years ago I tried to make the error as clear as possible.
Please update CLT or uninstall it if no updates are available.
If it isn't, please open a pull request making it clearer.
axello
commented
3 years ago First timer here: How can we help Big Sur compatibility on ARM Macs if we are indeed running an unsupported version of macOS? I see in this list that cocoapods is unchecked yet. But I needed it, so I tried to install. "Error: Failed to read Mach-O binary." on all the "ffi_c.bundle" files.
Should I create a new 'issue', or is this part of the 'Big Sur compatibility' list?
claui
commented
3 years ago Should I create a new 'issue', or is this part of the 'Big Sur compatibility' list?
Thank you for reaching out, and welcome to the Homebrew community @axello.
Please don’t create an issue. Homebrew does not yet support Big Sur so issues aren’t helpful right now.
cocoapods being unchecked means we didn’t even get around to checking it yet for Big Sur compatibility.
Your options are to either wait until it’s cocoapods’s turn to be checked and fixed, or help us by filing a pull request.
Bo98
commented
3 years ago I believe the Cocoapods issue is known by Apple themselves, as I think it is a system Ruby bug.
MikeMcQuaid
commented
3 years ago How can we help Big Sur compatibility on ARM Macs if we are indeed running an unsupported version of macOS?
Submit PRs to fix things. Almost every issue we have had so far has been already known. We know things aren't working. We need help fixing things not telling us what isn't working.
gregcotten
commented
3 years ago re: ilmbase - looks like this pull request straightens out arm64 macOS support. Once cmake build is fixed there shouldn't be a problem building openexr and ilmbase.
HaydenPeake
commented
3 years ago Is feedback on untested Formula in the above table useful? For example, I've installed and tested zlib on the DTK, and it appears to work correctly.
claui
commented
3 years ago Is feedback on untested Formula in the above table useful? For example, I've installed and tested zlib on the DTK, and it appears to work correctly.
@HaydenPeake Feedback on formulae that work correctly is welcome. It means we can update the table immediately, which benefits everyone.
DodgyTim
commented
3 years ago I've submitted a PR to get pcre working on arm64: https://github.com/Homebrew/homebrew-core/pull/57410 This is only a surface level fix at this point; it just turns off JIT. Edit: disabling JIT also fixes the crash in pcre2, I have yet to submit a PR for this. Again, it seems like a short term fix only.
segiddins
commented
3 years ago brew install cmake --HEAD seems to work for me! (the big sur release notes say Workaround: Update to CMake 3.18rc1. so I'm not terribly surprised)
gregcotten
commented
3 years ago
brew install cmake --HEADseems to work for me! (the big sur release notes sayWorkaround: Update to CMake 3.18rc1.so I'm not terribly surprised)
Not sure how you did that unless python3.8 was patched a few hours ago... Unless you aren’t building on Apple Silicon.
segiddins
commented
3 years ago sorry, should've been more specific -- python@3.8 only required the 3 linked PRs patched in: https://github.com/indirect/homebrew-core/commit/273ca33444d627421992cc71bbe2d597487f94b4
some of the stuff downstream from cmake works as well, such as tmux
DodgyTim
commented
3 years ago Created a PR for the pcre2 segfault -- again, just a workaround: https://github.com/Homebrew/homebrew-core/pull/57419
DodgyTim
commented
3 years ago For table update purposes, here's a list of formula with incomplete status which I happen to have tried on the DTK. I did an install and test and they seemed to function correctly:
frustum
commented
3 years ago BytesGuy
commented
3 years ago I think it would also be good to check whether formula are building arm64 or x86_64. Even though x86_64 will (mostly) work, the way forward is to get everything building natively 🙂
For example, telnet did build and work, but was x86_64 until my patch https://github.com/Homebrew/homebrew-core/pull/57303
Bo98
commented
3 years ago I think it would also be good to check whether formula are building arm64 or x86_64.
I absolutely agree. The wish is to have an audit which verifies if the output binaries are built natively - it's just that no one has done it yet.
The audit likely requires a way to make exceptions because I do think some formulae intentionally build non-native binaries for some cases, like parts of LLVM for iOS or something.
claui
commented
3 years ago PSA: the preliminary fix for python@3.8 has been merged. Should work now except for Tk support.
Formula promoted to 🥉 for now.
BytesGuy
commented
3 years ago I think it would also be good to check whether formula are building arm64 or x86_64.
I absolutely agree. The wish is to have an audit which verifies if the output binaries are built natively - it's just that no one has done it yet.
The audit likely requires a way to make exceptions because I do think some formulae intentionally build non-native binaries for some cases, like parts of LLVM for iOS or something.
I'd be happy to help with this! I've manually gone through some already and a fair number are building arm64 with no updates which is great. If we had an automated setup that would be even better 🙂
BytesGuy
commented
3 years ago FWIW I have been trying to bootstrap go to avoid the x86_64 kill at startup, but with no joy. Just found the tracking issue for this https://github.com/golang/go/issues/38485 Seems like we will be blocked for the moment
frustum
commented
3 years ago PSA: the preliminary fix for
python@3.8has been merged. Should work now except for Tk support. Formula promoted to 🥉 for now.
Thank you! It is possible to build meson with ctype Python fix. Glib and midnight-commander is buildable after that by removing libffi dependency from glib.
brunophilipe
commented
3 years ago After getting GMP to build using https://github.com/Homebrew/homebrew-core/pull/57315/files#diff-e16a29aaf7be91f5224126d4f764738b, nettle fails to build on Apple Silicon because it also uses lots of assembly code. Example:
clang -I. -DHAVE_CONFIG_H -g -O2 -ggdb3 -Wall -W -Wno-sign-compare -Wmissing-prototypes -Wmissing-declarations -Wstrict-prototypes -Wpointer-arith -Wbad-function-cast -Wnested-externs -c aes128-set-encrypt-key.c \
&& true
aes-decrypt-internal.s:67:2: error: unrecognized instruction mnemonic
teq r3, #0
^aes-encrypt-internal.s
:75:2: error: unrecognized instruction mnemonic
teq r3, #0
^After getting GMP to build using https://github.com/Homebrew/homebrew-core/pull/57315/files#diff-e16a29aaf7be91f5224126d4f764738b, nettle fails to build on Apple Silicon because it also uses lots of assembly code. Example:
clang -I. -DHAVE_CONFIG_H -g -O2 -ggdb3 -Wall -W -Wno-sign-compare -Wmissing-prototypes -Wmissing-declarations -Wstrict-prototypes -Wpointer-arith -Wbad-function-cast -Wnested-externs -c aes128-set-encrypt-key.c \ && true aes-decrypt-internal.s:67:2: error: unrecognized instruction mnemonic teq r3, #0 ^aes-encrypt-internal.s :75:2: error: unrecognized instruction mnemonic teq r3, #0 ^
Created a PR with a temporary fix for this issue until arm64 support is available upstream https://github.com/Homebrew/homebrew-core/pull/57455
stuartcarnie
commented
3 years ago OpenSSL 1.1.1 PR openssl/openssl/pull/12369 submitted
adib
commented
3 years ago Reporting issue with cocoapods – building from source would fail due to a missing xcodeprojdependency:
Command:
brew install --build-from-source cocoapodsError:
==> gem install cocoapods-1.9.3.gem
Error: An exception occurred within a child process:
Errno::ENOENT: No such file or directory - /usr/local/Cellar/cocoapods/1.9.3/libexec/bin/xcodeproj
@adib Thank you. We’re really just getting started so reporting breakage isn’t helpful at this time. Appreciate your report but marking it OT to keep the page focused.
BytesGuy
commented
3 years ago Findings from today:
rust - currently not installing. The tracking issue for this is here: https://github.com/rust-lang/rust/issues/73908 The tracking issue says that x86_64 should work fine with Rosetta, but I have been unable to get a successful build for this so far 😞 bash - Currently not installing successfully - tries to build for arm64 and fails, maybe x86_64 will work but have not tested yetnettle - PR filed to disable assembly until available upstream https://github.com/Homebrew/homebrew-core/pull/57455gd - installs fine, passes tests and binaries are arm64libplist - installs fine, passes tests and binaries are arm64libimobiledevice - installs fine, passes tests and binaries are arm64claui
commented
3 years ago PSA: The pcre, pcre2 and gmp fixes have landed.
Special thanks to @BytesGuy and @DodgyTim who helped remove those roadblocks. 🎉
claui
commented
3 years ago
gd- installs fine, passes tests and binaries are arm64libplist- installs fine, passes tests and binaries are arm64
@BytesGuy Noted, thanks for the heads up!
libimobiledevice- installs fine, passes tests and binaries are arm64
~PR filed to make libimobiledevice (stable) pass brew audit: https://github.com/Homebrew/homebrew-core/pull/57555~
Update: Installs and works fine now, both stable and --HEAD.
BytesGuy
commented
3 years ago carthage works with this patch and builds a native binary (also resolves issues on Intel): https://github.com/Homebrew/homebrew-core/pull/57572
BytesGuy
commented
3 years ago fish - Installs fine, passes tests, arm64 binary
perl - Currently doesn't work on Intel or Apple Silicon, PR opened: https://github.com/Homebrew/homebrew-core/pull/57580 (with this fix it passes tests and the binary is arm64 native)
claui
commented
3 years ago It has come to my attention that carthage has landed (thanks again @BytesGuy) and cmake, too.
stuartcarnie
commented
3 years ago I'm going to take a look at the JIT issues for pcre and pcre2 – I found the same issue with Boxer (DosBox) and resolved it in https://github.com/MaddTheSane/dosbox/commit/794513db66e210fbe28c6a1f69d8acd9a8664e30
BytesGuy
commented
3 years ago gnupg is currently blocked by libffivim is currently blocked by perlredis currently will not install and provides the following error: ^
debug.c:1037:47: error: no member named '__gs' in 'struct __darwin_arm_thread_state64'
(unsigned long) uc->uc_mcontext->__ss.__gs
~~~~~~~~~~~~~~~~~~~~~ ^
debug.c:1039:51: error: no member named '__esp' in 'struct __darwin_arm_thread_state64'; did you mean '__sp'?
logStackContent((void**)uc->uc_mcontext->__ss.__esp);
^~~~~
__sp
/Applications/Xcode-beta.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX11.0.sdk/usr/include/mach/arm/_structs.h:139:13: note: '__sp' declared here
__uint64_t __sp; /* Stack pointer x31 */
^
18 errors generated.
make[1]: *** [debug.o] Error 1
make[1]: *** Waiting for unfinished jobs....
make: *** [install] Error 2@BytesGuy regarding redis, it just so happens I fixed a similar issue in iTerm2. I'll take a look at that.
idyll
commented
3 years ago Erlang is currently not compiling on macOS 11 because:
error: static declaration of 'in6addr_any' follows non-static declarationThere are separate issues on Apple Silicon that likely require a more difficult fix.
Tracking here:
Latest news on native ARM compatibility
:arm64_big_surline in the bottle block).mkmfinRuby.frameworkresolved (FB7836181). Allbrewcommands that depend on that gem, e. g.brew audit, seem to work now./opt/homebrew(once support arrives). See https://github.com/Homebrew/brew/issues/7857#issuecomment-727561968 for details.A detailed description of the proposed feature
This is an overview of compatibility issues and work items related to native ARM Homebrew installations on macOS 11.0 (Big Sur). Homebrew doesn’t support it right now but we need to track and triage those items nonetheless.
The motivation for the feature
macOS 11.0 (Big Sur) has been released to the public, and our goal is for Homebrew to support it.
How the feature would be relevant to at least 90% of Homebrew users
In the long run, more than 90 % of Homebrew (macOS) users are going to run Apple Silicon hardware.
What alternatives to the feature have been considered
No alternatives.
Major blockers
arm64_big_surbottlesStatus of core formulae
on 11.0
ackadnsadwaita-icon-themeaircrack-ngansibleantopenjdkworksaomapache-sparkapr-utilaprargon2arpackasciidocasdfaspellatkaugeasautoconfautojumpautomakeaws-elasticbeanstalkaws-iam-authenticatorgoworksawsclidistutils.errors.DistutilsClassError, see logs.Possibly related to setuptools: https://github.com/pypa/setuptools/pull/2231
azure-clibash-completionbashmakesays,redefinition of 'sys_siglist' with a different type: 'char *[32]' vs 'const char *const [32]'. Logsbatrustworksbazelopenjdk@11worksbdw-gcberkeley-dbbinutilsbisonblueutilboostbrotlic-arescabal-installghcworkscairocargo-crustprereleases; will work when a stable Rust with Apple Silicon support shipscarthagecaskemacsworksccacheUsed to work, no longer builds. Logs
Says:
ceres-solvercertbotcfitsiocgalqtworkscirclecigoworksclang-formatcloccmakecocoapodsUnrecognized Mach-O load command: 0x80000034inffi_c.bundlecolordiffcomposerconsulgoworkscoreutilscscopectagscunitcurlcurl-opensslcythondav1ddaemontoolsdenollvmandrustworkdepgoworksdialogdirenvgoworksdnsmasqdocbook-xsldocbookdockergoworksdocker-completiondocker-machinegoworksdoctlgoworksdos2unixdoxygendutieigenelasticsearchgradleandopenjdkworkelixirerlangworksemacsgnutlsworksepsilonepstoolghostscriptworkserlangSame with https://github.com/erlang/otp/pull/2687.
exiftoolexpatfastlanefdrustworksffmpeggnutls,libblurayand several other dependencies workfftwgccandopen-mpiworkfig2devghostscriptandnetpbmworkfigletfindutilsfishflacfltkfontconfigfontforgefreetdsfreetypefreexlimplicitly declaring library function 'printf'Logsfrei0rfribidifswatchfzfgawkgcalgcc@Iains has some work in progress on https://github.com/iains/gcc-darwin-arm64 to port the GCC backend to Apple Silicon.
Mind that Apple Silicon support is going to require GCC 11 even in the best case. The first stable release of GCC 11 may come out in mid-2021 or later. If you absolutely require a stable GCC, or any formula that depends on it, you may want to hold off your Apple Silicon Mac purchase decisions until it’s clear if or when GCC will support it.
For limited testing on Apple Silicon, Homebrew may consider shipping an unstable GCC 11 but that’s yet to be decided.
gdalexpat,freexl,geos,hdf5and a dozen of other dependencies workgdbmgdbgdk-pixbufgdgeckodrivergeosBasicSegmentStringininlines.ovs.libnoding.a. Logsgettextgflagsghcghc@8.8ghostscriptgiflibgitUndefined symbols for architecture arm64. Possibly related tolibintlandpcre2. Logsgit-flowgit-guigit-lfsgitlab-runnergl2psglewglib-networkingglibglogglpkgmpgnu-getoptgnu-sedgnu-targnupggnutlsworksgnuplotgnutlsgobject-introspectiongoBootstrapped
go(x86_64) is killed at build time. LogsRe-check when upstream 1.16 is released
gpatchgpgmegradleopenjdkworksgrafanagraphicsmagickgraphite2graphvizgtsworksgrepgroongagroovygrpcgsettings-desktop-schemasgslgst-plugins-badgstreamergtk+3gtk+gtk-mac-integrationgtsnetpbmworksguileharfbuzzhdf5gccworkshelmgoworkshelm@2glideandgoworkhicolor-icon-themehighlighthtophttpdhttpiehubgoworkshugogoworkshwlocicu4cideviceinstallerilmbaseimagemagick@6imagemagickghostscript,libheifandlibompworkinetutilsios-deployios-webkit-debug-proxyiperf3ipythonislitstooljanssonjasperjemallocjenkinsopenjdk@11worksjenkins-ltsopenjdk@11worksjenvjmeterjpegjqjson-cjupyterlabpandocworkskafkaopenjdk(or some other form of Java) andzookeeperworkkopskotlinopenjdk(or some other form of Java) workskrb5kubectxkubernetes-cligoworkskustomizelameldnsleptonicalibarchivelibassuanlibasslibb2libblurayopenjdk(or some other form of Java) workslibcborlibcerflibcrocolibdaplibde265libepoxylibeventlibevlibexiflibffilibfido2libgcryptlibgeotifflibgit2libgpg-errorlibheiflibde265workslibiconvlibidn2libidnlibilbclibimobiledevicelibksbaliblqrlibmagiclibmaxminddblibmetalinklibmpclibnetlibogglibompmake installfails while trying to make sense of x86_64 assembly for Linux. Logslibp11libplistlibpnglibpqlibpsllibrdkafkalibressllibrsvglibsampleratelibscryptlibsmilibsndfilelibsodiumlibsouplibsoxrlibspatialitelibspirolibsshlibssh2libtasn1libtermkeylibtifflibtoollibuninameslistlibunistringlibusb-compatlibusbmuxdlibusblibuvlibvidstablibvirtlibvorbislibvpxlibvtermlibwebsocketslibxml2libxsltlibyamllibziplittle-cms2llvmHEADdoes and 11.0.0 will be compatible.lualua@5.1luajitluarockslynxlz4lzomacvimmad/bin/ksh ./config.sub -apple-darwin20.0.0 failedLogsmakemariadbgroongaworksmasmavenopenjdkworksmbedtlsmcryptmecabmecab-ipadicmemcachedmercurialmesonmetismidnight-commanderminikubeminizipmitmproxymkcertmkvtoolnixmonomoshmpfrmpvmsgpackmtrmujsmuttmysqlmysqld_safefails withsyntax error near unexpected token 'then'in line 831.mysql@5.6makeerrors out after building the targetevent_extra. Logsmysql@5.7mysqld_safefails:syntax error near unexpected token 'then'in line 804.mysql-clientnanonasmncduncursesneofetchneovimnetcdfnetpbmsubversionworksnettlenghttp2nginxninjanmapnodePatched for now.
See also https://github.com/nodejs/node/issues/34043 and https://github.com/nodejs/TSC/issues/886 for upstream progress.
node@10node@12node-buildnodebrewnpthnsprnsssoftokn3. Logsntfs-3gnumpynvmocaml4.10 backport in progress, see https://github.com/ocaml/ocaml/pull/10026.
4.10 formula-patches PR: https://github.com/Homebrew/formula-patches/pull/318
octaveonigurumaopamopen-mpigccworksopenblasopenconnectopencore-amropencvopenexropenjdkopenjdk@11openjpegopenldapopensshopensslakaopenssl@1.1Patched for now.
Works well enough until the upstream fix is released.
openvpnopusfileopusorcp11-kitp7zippackergoworkspandoccabal-installandghcworkpangoparallelpcre2pcreperlphp@7.2php. Might want to triage as 🚫.php@7.3php. Might want to triage as 🚫.phppinentrypipenvpixmanpkcs11-helperpkg-configplantumlpopplernssandqtworkpoptportaudiopostgisgdal,geos,gppandsfcgalworkpostgresqlpostgresql@9.6postgresql@10postgresql@11pre-commitprojprotobufprotobuf-cpstoeditpstreepulumiputtypy3cairopyenvpyenv-realpath.dylibas a builtin. Logpyenv-virtualenvpygobject3pyqtpython@3.7python@3.8Patched for now but
brew testfails.Re-check after https://github.com/Homebrew/homebrew-core/pull/64872 is merged.
pythonakapython@3.9brew testcurrently fails.Re-check after https://github.com/Homebrew/homebrew-core/pull/64869 is merged.
qemuqhullqrupdateqtfind_sdk.pylate in the build. (logs, full make log)rabbitmqerlangworksrav1ecargo-candrustworkrbenvrclonereadlineredisrenameripgreprsyncrtmpdumprubberbandruby-buildruby@2.5rubyrustrustup-inits-langs3cmdsbclsbtscalascrcpyscreenresolutionsdl2sdlsfcgalcgalworksshared-mime-infoshellcheckcabal-install,ghc@8.8andpandocworksipskaffoldsnappysocatsource-highlightsoxmadworksspandspspeedtest-clispeexsphinx-docsqlitesqlmapsrt'GLES/gl.h' file not foundduringmake install. Logsssh-copy-idsshfssshpasssshuttlestarshipstokensubversionbrew testfails. Logs.suite-sparsesundialsswagger-codegenswiftformatswiftlintswigsziptbbtcl-tktelnetdtelnetterraformgoworksterragrunttesseracttexinfotfenvtflintthefucktheorathe_silver_searchertidy-html5tigtmuxtomcattortreeuchardetunarunboundunibiliumunixodbcunrarutf8procv8valagraphvizworksvalgrindvapoursynthvaultvdevimvipswatchmanwatchwebpwgetwimlibwinetrickswiresharkwxmacx264x265xcodegenRe-check with upstream version > 2.17.0 once released.
xerces-cxmltoxvidxxhashxzyarayarnyasmyoutube-dlyqgoworkszeromqzimgzlibzookeeperantworkszshzsh-autosuggestionszsh-completionszsh-syntax-highlightingzstdSource
curl -sLS \ 'https://formulae.brew.sh/api/analytics/install/90d.json' \ | jq -r '.items | map(select (.formula | contains("/") | not) | .formula)[:512] | sort | [""] + map("`\(.)`") | map([., "", ""] | @csv) | .[] ' \ | pandoc -f csv -t gfm \ | sed -e 's/\\`/`/g'1 For Works on 11.0, the key is:
brew install -ssucceeds on Apple Silicon. The software works well enough natively.depends_on :arch => [:x86_64, :build]. The software works well enough on Rosetta.depends_on :arch => :x86_64. The software has been deemed to work on Intel only (for now).