Error: Cannot install in Homebrew on Intel processor in ARM default prefix (/opt/homebrew)!

[cmarquardt]

Bug report

• ran brew update and can still reproduce the problem?
• ran brew doctor, fixed all issues and can still reproduce the problem?
• ran brew config and brew doctor and included their output with your issue?

What you were trying to do (and why)

Since a long time, I happily use homebrew on a non-default path - /opt/homebrew. Since the last update of homebrew, trying to upgrade or install packages, e.g. with

brew upgrade

results in the following error:

Error: Cannot install in Homebrew on Intel processor in ARM default prefix (/opt/homebrew)!

and no installation takes place, unfortunately.

I understand you are working on ways to support the new ARM chips with Homebrew; I assume changes related to that cause this error message. I further assume that reinstalling in a different place will avoid this error - is this correct? I would still like to avoid a complete reinstall - is there a way to disable this check, e.g. with a command-line argument to brew?

To be honest, I would also suggest that installation directories for different hardware architectures carry the hardware in their path, e.g. like in

/opt/homebrew/x86_64
/opt/homebrew/arm

which would allow installing homebrew instances for different hardware architectures side-by-side. By the way, would brew accept a prefix like the proposed, or still throw an error?

Thank you.

Christian.

Output of brew config and brew doctor commands

KASSANDRA /Users/marq>brew config
HOMEBREW_VERSION: 2.5.10-10-g78f1761
ORIGIN: https://github.com/Homebrew/brew
HEAD: 78f17618028232e924980661a70ac08b4b78d609
Last commit: 3 hours ago
Core tap ORIGIN: https://github.com/Homebrew/homebrew-core
Core tap HEAD: 542ff01c92e32b04301c2c5aa1ca335b8c438da0
Core tap last commit: 3 hours ago
Core tap branch: master
HOMEBREW_PREFIX: /opt/homebrew
HOMEBREW_REPOSITORY: /opt/homebrew/Homebrew
HOMEBREW_CELLAR: /opt/homebrew/Cellar
HOMEBREW_CASK_OPTS: []
HOMEBREW_DISPLAY: /private/tmp/com.apple.launchd.MtDSttSw36/org.macosforge.xquartz:0
HOMEBREW_GITHUB_API_TOKEN: set
HOMEBREW_MAKE_JOBS: 8
Homebrew Ruby: 2.6.3 => /System/Library/Frameworks/Ruby.framework/Versions/2.6/usr/bin/ruby
CPU: octa-core 64-bit haswell
Clang: 12.0 build 1200
Git: 2.29.2 => /opt/homebrew/bin/git
Curl: 7.64.1 => /usr/bin/curl
Java: 1.8.0_131, 1.8.0_25
macOS: 10.15.7-x86_64
CLT: 12.0.32.27
Xcode: 12.2
XQuartz: 2.7.11 => /opt/X11

KASSANDRA /Users/marq>brew doctor
Please note that these warnings are just used to help the Homebrew maintainers
with debugging if you file an issue. If everything you use Homebrew for is
working fine: please don't worry or file an issue; just ignore this. Thanks!

Warning: You have installed Bitdefender. The "Traffic Scan" option interferes with
Homebrew's ability to download packages. See:
  https://github.com/Homebrew/brew/issues/5558

Warning: "config" scripts exist outside your system or Homebrew directories.
`./configure` scripts often look for *-config scripts to determine if
software packages are installed, and which additional flags to use when
compiling and linking.

Having additional scripts in your path can confuse software installed via
Homebrew if the config script overrides a system or Homebrew-provided
script of the same name. We found the following "config" scripts:
  /usr/local/bin/upgrade-borgmatic-config
  /usr/local/bin/generate-borgmatic-config

Warning: You have unlinked kegs in your Cellar.
Leaving kegs unlinked can lead to build-trouble and cause brews that depend on
those kegs to fail to run properly once built. Run `brew link` on these:
  numpy
  numpy4python@2

Warning: Your Homebrew's prefix is not /usr/local.
Some of Homebrew's bottles (binary packages) can only be used with the default
prefix (/usr/local).
You will encounter build failures with some formulae.
Please create pull requests instead of asking for help on Homebrew's GitHub,
Discourse, Twitter or any other official channels. You are responsible for
resolving any issues you experience while you are running this
unsupported configuration.

[sjackman]

Hi, Christian. I've referred your question to the Technical Steering Committee (TSC) of Homebrew. They may take some time to deliberate before replying.

In short term, it's strongly recommended to install Homebrew on macOS on Intel in /usr/local. See https://docs.brew.sh/Installation#untar-anywhere

However do yourself a favour and install to /usr/local on macOS Intel, /opt/homebrew on macOS ARM, and /home/linuxbrew/.linuxbrew on Linux. Some things may not build when installed elsewhere. One of the reasons Homebrew just works relative to the competition is because we recommend installing here. Pick another prefix at your peril!

The precompiled binary bottles are compiled for this prefix, and using that makes it unnecessary to build anything from source. Building from source is not supported.

[cmarquardt]

Hi Shaun (@sjackman),

Thank you for the quick reply, and for passing on my suggestion to the TSC.

I know about the /usr/local recommendation, of course; the one on /opt/homebrew is rather new. Let's say I prefer to decide myself where to install software on my machines, and I maintain some formulae with modified build options anyway. I'm perfectly happy (and able) to solve problems arising from different installation and library paths. Occasionally I was able to provide patches to the one or other formulae in case they didn't build with non-standard prefixes - cases which are actually very rare, given the high quality of the formulae in Homebrew.

Coming back to my question, the error message doesn't indicate that an install from source code was problematic. It suggests that the brew install/upgrade script checks the target directory and then refuses to go ahead with the installation. I didn't dispute the choice of the homebrew maintainers implementing this behaviour; I merely asked if relocating/reinstalling homebrew into a subdirectory of /opt/homebrew would result in similar complaints, and/or if the check can currently be disabled. As an alternative, I'd also be grateful for a pointer to where in brew source code this particular behaviour is implemented. I spend a while trying to go through the sources here on GitHub to find the place, but have been unsuccessful so far; I don't know much about the structure of the code (and Ruby in general). So I thought I'd rather ask.

Thanks again for your help,

Christian.

[cmarquardt]

Ahh, I finally found it - here. So no way to bypass it, but every prefix other than the default one for ARM will do. That answers my question.

[MikeMcQuaid]

So no way to bypass it, but every prefix other than the default one for ARM will do.

Yup, this is the intended behaviour. Sorry to mess with your current workflow but this should be a one-time change that will avoid pain in future.

[sjackman]

brew bundle dump and brew bundle install are useful to migrate an existing Homebrew installation to a new location.
See https://github.com/Homebrew/homebrew-bundle#usage

[cmarquardt]

Thank you for the confirmation and also for the pointer to brew bundle - that helps a lot indeed!

[sjackman]

See #9177 Discussion: longterm Homebrew prefix on Apple Silicon Macs

[Yann-R]

Hello,

I belong to the group of users that already chose /opt/homebrew as prefix so as not to mix with other binaries coming (often without verification of overwrites) into /usr/local.
I've been doing so for years hapilly, knowing I entered this land by a "little door" allowed by homebrew documenting "Pick another prefix at your peril" (see https://docs.brew.sh/Installation) when recommending the default prefixes:

• /usr/local on macOS intel
• /opt/homebrew on macOS ARM
• /home/linuxbrew on Linux

But I really appreciated this little door ("at my peril") being open on my Intel-based system to customize the brew prefix.
So my disappointment is two-fold today:

1. similarly the little door to change (at my peril) the prefix for ARM-based systems seems not to be open with the same logic
2. the hard-coded ARM prefix has side-effects on my system not ARM-based, whereas I supposed that this restriction (concerning the usage of /opt/homebrew) would raise only on ARM-based systems... Why warning Intel-users?

@MikeMcQuaid wrote:
Sorry to mess with your current workflow but this should be a one-time change that will avoid pain in future.

OK,hombrewis worth it 👍 I will surely reinstall my gigas of brewed software to another customized place (maybe using this kind of dirty tricks https://blog.mact.me/2015/05/15/so-you-want-to-move-your-homebrew-folder, to save recompiling hours, at my own risks I know)
But since I look very unlucky to have picked the same directory as homebrew this time, I may also pick another one that could also become restricted by hard-code during my brewing if Apple introduces another architecture in a couple of years 😉

Really, making this /opt/homebrew "customizable at your peril" (like it is for /usr/local), or ignored on Intel-based system, would have been 2 welcomed options.
Best regards.

[artob]

Just checking in to say that I'm in the same boat as @cmarquardt and @Yann-R: I've been using /opt/homebrew for years, largely without incident--until a brew upgrade just now resulted in this unexpected error. My /opt/homebrew is 15+ GB, so can't say I'm terribly happy about this breakage that rather interrupts and changes my plans for today.

[bunam]

For ARM this should by nicer :

• /opt/armbrew

[Hikoyu]

I edited Library/Homebrew/global.rb and change the path like this:
HOMEBREW_MACOS_ARM_DEFAULT_PREFIX = "/opt/armbrew"

[lenlo]

I know this issue has been closed, but I still wanted to add a +1. Not wanting to mix homebrew's installation tree with that of every other random package that also wants to install into /usr/local, I put it in /opt/homebrew instead. It felt like the right choice at the time and has worked perfectly for the 5+ years that I have been using homebrew on numerous macOS systems. I'm glad to see that the brew maintainers have started to see things the same way, but I am less happy with the heavy handed way /opt/homebrew suddenly got usurped for ARM binaries only -- even on x86 systems that will never have any ARM binaries on them. Why is that necessary? Can't there at least be a user selectable option for this? I get it that I'm on "my own" if I don't use the standard locations and have to build everything from source and I'm used to that. That doesn't bother me at all. What bothers me is suddenly being thrown an error message when I try to upgrade homebrew with no configurable recourse around it. That's very unfortunate and is bound to cause a lot of unnecessary pain for a lot of people out there. I think /opt/homebrew is a fine default choice for ARM moving forward, but I would strongly urge you to provide a way to override the system default setting for HOMEBREW_MACOS_ARM_DEFAULT_PREFIX -- or at least allow for it to be used for non-ARM binaries on non-ARM systems. Yes, I am aware that one can edit Library/Homebrew/global.rb manually (and yes, I have done that too), but that is a really bad workaround. Please reconsider. Thanks.

[MikeMcQuaid]

Why is that necessary?

Because we're going to imminently start shipping ARM binaries and need to build them in a different location to /usr/local so people on ARM Macs can have Intel and ARM installations side-by-side.

Can't there at least be a user selectable option for this?

No, sorry.

That's very unfortunate and is bound to cause a lot of unnecessary pain for a lot of people out there

I agree it is unfortunate, I do not consider it unnecessary.