[bug]: Wrong fzf binary for M1 chip

[seagle0128]

Describe the bug

Zinit downloads wrong fzf binary from Github on M1 Macbook.

Steps to reproduce

zinit ice wait lucid from"gh-r" nocompile src'key-bindings.zsh' sbin \
      dl'https://raw.githubusercontent.com/junegunn/fzf/master/shell/completion.zsh -> _fzf_completion;
         https://raw.githubusercontent.com/junegunn/fzf/master/shell/key-bindings.zsh -> key-bindings.zsh;
         https://raw.githubusercontent.com/junegunn/fzf/master/man/man1/fzf-tmux.1 -> $ZPFX/share/man/man1/fzf-tmux.1;
         https://raw.githubusercontent.com/junegunn/fzf/master/man/man1/fzf.1 -> $ZPFX/share/man/man1/fzf.1'
zinit light junegunn/fzf

fzf-0.30.0-darwin_amd64.zip is downloaed on M1 Macbook.

Expected behavior

fzf-0.30.0-darwin_arm64.zip is downloaded for M1 chip.

Screenshots and recordings

No response

OS / Linux distribution

macOS M1

Zsh version

5.8.1

Terminal emulator

iTerm2

If using WSL on Windows, which version of WSL

No response

Additional context

No response

[vladdoster]

@seagle0128, I'm not seeing this issue?

[vladdoster]

[vladdoster]

Not to be pedantic, but macOS M1 isn't really the OS distribution. sw_vers is a built-in macOS command.

[vladdoster]

Seems to work on both architectures on M1, too.

arch -arch arm64

and

arch -arch x86_64

[vladdoster]

@seagle0128 Can you confirm if you still see this bug or can this issue be closed?

[seagle0128]

I still get wrong fzf binary even though I upgrade to the latest :-(

What should I do for further troubleshooting?

[vladdoster]

can you try

zinit delete junegunn/fzf --yes \
&& rm -rf "$HOME/.local/share/zinit/zinit.git" \
&& exec zsh

[seagle0128]

@vladdoster sure.

If I use bpick"*arm*", it works well.

[docwhat]

The issue seems to be that MACHTYPE (compiled in CPU type) is searched before CPUTYPE (runtime detected CPU type). If you launch via /bin/zsh from an x86_64 terminal, then MACHTYPE=x86_64 while CPUTYPE=arm64

[vladdoster]

@docwhat -- I proved in a screenshot this isn't the issue, no?

Seems to work on both architectures on M1, too.

arch -arch arm64

and

arch -arch x86_64

[seagle0128]

The issue seems to be that MACHTYPE (compiled in CPU type) is searched before CPUTYPE (runtime detected CPU type). If you launch via /bin/zsh from an x86_64 terminal, then MACHTYPE=x86_64 while CPUTYPE=arm64

@docwhat You are right! The PR #287 should fix this issue.

Actually I am using the built-in zsh and iTerm2

❯ /bin/zsh --version
zsh 5.8.1 (x86_64-apple-darwin21.0)

After I installed zsh 5.9 (arm) via brew and reinstalled zinit, MACHTYPE is arm finally.

[vladdoster]

I don't think this is the issue.

You are using the x86_64 version of Zsh, so it is selecting the correct binary.

I think this is more an issue of the macOS Zsh version, and I have hunch you're running Iterm2 via Rosetta2?

[docwhat]

@docwhat -- I proved in a screenshot this isn't the issue, no?

To reproduce the bug your MACHTYPE needs to be x86_64 and CPUTYPE needs to be arm64.

In this bug they disagree because the terminal program is x86_64 which runs /bin/zsh.

/bin/zsh is a universal binary which effectively has two binaries in it. One is compiled with MACHTYPE=x86_64 and one is compiled with MACHTYPE=arm64.

In both cases, CPUTYPE is the same because they use the same CPU detection methods.

[vladdoster]

Yes, so the question is whether or not iterm2 was running via Rosetta2. Which would propagate to Zsh selection, right?

[docwhat]

@seagle0128's comment above implies that he has the x86_64 version of iTerm2.

In my case, Kitty only has x86_64 binaries for macOS at this time; it always runs under Rosette2.

[seagle0128]

I think this is more an issue of the macOS Zsh version, and I have hunch you're running Iterm2 via Rosetta2?

No, I am not using x86_64 iTerm2 with Rosette2.

[vladdoster]

I see:

What is output of:

lipo /Applications/iTerm.app/Contents/MacOS/iTerm2 -detailed_info

ᐳ lipo /Applications/iTerm.app/Contents/MacOS/iTerm2 -detailed_info
Fat header in: /Applications/iTerm.app/Contents/MacOS/iTerm2
fat_magic 0xcafebabe
nfat_arch 2
architecture x86_64
    cputype CPU_TYPE_X86_64
    cpusubtype CPU_SUBTYPE_X86_64_ALL
    capabilities 0x0
    offset 16384
    size 18469472
    align 2^14 (16384)
architecture arm64
    cputype CPU_TYPE_ARM64
    cpusubtype CPU_SUBTYPE_ARM64_ALL
    capabilities 0x0
    offset 18497536
    size 17904240
    align 2^14 (16384)

~
ᐳ

[docwhat]

@seagle0128 when you fire up your iTerm2 and run 'echo "shell:$SHELL compiled-cpu:$MACHTYPE detected-cpu:$CPUTYPE"` I would expect you'd get:

$ echo "shell:$SHELL  compiled-cpu:$MACHTYPE  detected-cpu:$CPUTYPE"
shell:/bin/zsh  compiled-cpu:x86_64  detected-cpu:arm64

...which is what I get with Kitty on my M1.

[seagle0128]

❯ lipo /Applications/iTerm.app/Contents/MacOS/iTerm2 -detailed_info
input file /Applications/iTerm.app/Contents/MacOS/iTerm2 is not a fat file
Non-fat file: /Applications/iTerm.app/Contents/MacOS/iTerm2 is architecture: arm64

Before (using built-in zsh):

❯ zsh --version
zsh 5.8.1 (x86_64-apple-darwin21.0)
❯ echo "shell:$SHELL  compiled-cpu:$MACHTYPE  detected-cpu:$CPUTYPE"
shell:/bin/zsh  compiled-cpu:x86_64  detected-cpu:arm64

Now (using zsh from homebrew):

❯ zsh --version
zsh 5.9 (arm-apple-darwin21.3.0)
❯ echo "shell:$SHELL  compiled-cpu:$MACHTYPE  detected-cpu:$CPUTYPE"
shell:/usr/local/bin/zsh  compiled-cpu:arm  detected-cpu:arm64

BTW: Actually whatever I use zsh(x86_64) or zsh(arm64) , the downloaded binary is correct, as long as zsh(arm64) is in the front of $PATH.

[vladdoster]

@seagle0128 that makes sense. So is my previous message true or am I misunderstanding?

I don't think this is the issue.

You are using the x86_64 version of Zsh, so it is selecting the correct binary.

I think this is more an issue of the macOS Zsh version, and ~I have hunch you're running Iterm2 via Rosetta2~?

[seagle0128]

@vladdoster Correct. But I still think it's better checking $CPUTYPE first, for better performance. No idea why zsh(x86_64) is built-in. Maybe need documentation? Thank you!

BTW, I remember two or four weeks ago, the behavior is different if I am not wrong.

[vladdoster]

@vladdoster Correct. But I still think it's better checking $CPUTYPE first, for better performance.

What program(s) have you observed with performance differences?

No idea why zsh(x86_64) is built-in.

Granted it is a shell, but probably due to APIs (memory allocation) not being 1-to-1 plus x86 version being defacto target for majority of users which makes it preferable (e.g., increased stability, all features, relying on contributors to maintain 2nd version)

But probably because M1 is first generation and they will switch version at some point when Intel apple laptops are less common.

Maybe need documentation? Thank you!

Wouldn't hurt, will add something

BTW, I remember two or four weeks ago, the behavior is different if I am not wrong.

Indeed, see #201, #235, and #269

[vladdoster]

@seagle0128

lol, this just happened to be on HackerNews front page

TLDR:

Anyway I can say that my colleagues M1 using rosetta is faster or equal to my MBP i9 2020.

That's because it's not emulation. It's binary translation, which is vastly more performant

HN thread: https://news.ycombinator.com/item?id=31696447

[seagle0128]

What program(s) have you observed with performance differences?

In my env, at the first time startup, x86 binaries run slower significantly than arm binaries. e.g. rg, fzf.

[vladdoster]

What program(s) have you observed with performance differences?

In my env, at the first time startup, x86 binaries run slower significantly than arm binaries. e.g. rg, fzf.

Isn't this to be expected since it is being ran via Rosetta?

[vladdoster]

@docwhat ... this is due to quoting (i.e., ' v.s. ") of variables, right? So what it reports isn't actually the value Zinit is using.

Could I get a sanity check? Below is the output of the respective logic 😖.

[vladdoster]

@seagle0128

as a temporary solution, set the following environment variable in your .zshenv or .zprofile or set it in your arch preferences file (man arch).

export ARCHPREFERNCE=arm64e

[seagle0128]

@vladdoster Thank you for letting me know!

[github-actions[bot]]

:tada: This issue has been resolved in version 3.8.0 :tada:

The release is available on GitHub release

Your semantic-release bot :package::rocket:

[ngocphamm]

I'm still getting this issue with latest version of zinit, using /bin/zsh in macOS 12.6.1, which is x86_64 built.

Downloading junegunn/fzf…
(Requesting `fzf-0.35.1-darwin_amd64.zip'…)
#################################################################################################################################################################################################################### 100.0%
[ziextract] Unpacking the files from: `fzf-0.35.1-darwin_amd64.zip'…
Archive:  fzf-0.35.1-darwin_amd64.zip
  inflating: fzf
[ziextract] Successfully extracted and assigned +x chmod to the file: fzf.
[patch-dl annex]: File fzf-tmux downloaded correctly
[patch-dl annex]: File completion.zsh downloaded correctly
[patch-dl annex]: File key-bindings.zsh downloaded correctly
[patch-dl annex]: File fzf-tmux.1 downloaded correctly
[patch-dl annex]: File fzf.1 downloaded correctly
bin-gem-node annex: Created the fzf shim and set +x on the fzf binary
bin-gem-node annex: Created the fzf-tmux shim and set +x on the fzf-tmux binary

Downloading ajeetdsouza/zoxide…
(Requesting `zoxide-0.8.3-x86_64-apple-darwin.tar.gz'…)
#################################################################################################################################################################################################################### 100.0%
[ziextract] Unpacking the files from: `zoxide-0.8.3-x86_64-apple-darwin.tar.gz'…
[ziextract] Successfully extracted and assigned +x chmod to the file: zoxide.
(eval):1: bad CPU type in executable: ./zoxide
Warning: ∞zinit-atclone-hook hook returned with 127
bin-gem-node annex: Created the zoxide shim and set +x on the zoxide binary

~ » echo "shell:$SHELL  compiled-cpu:$MACHTYPE  detected-cpu:$CPUTYPE"                                                                                                                                              
shell:/bin/zsh  compiled-cpu:x86_64  detected-cpu:arm64

~ »  zsh --version
zsh 5.8.1 (x86_64-apple-darwin21.0)

I have tried putting export ARCHPREFERENCE=arm64e in .zprofile with no success.

I'm using Alacritty (arm64 build), and do not even have Rosetta installed.