Warning: Building … from source as the bottle needs

[lsloan]

Are the Warning: Building … from source as the bottle needs messages really just warnings or are they errors, rendering the packages unusable?

For example, I get a lot of warnings from Homebrew like this…

Warning: Building pypy from source as the bottle needs:
- HOMEBREW_CELLAR: /usr/local/Cellar (yours is /Local/Cellar)
- HOMEBREW_PREFIX: /usr/local (yours is /Local)

I see these more now than in years past. I guess Homebrew is doing more checking than it was before.

Some background on my choice of Homebrew directories:

I'm working on a computer owned by my employer. They will not include my changes to "/usr/local" in backups. So, I created "/Local" and I symlinked "/usr/local" to it. They will backup my "/Local", so I'm happy.

When I started using Homebrew, I saw the warnings about changing the various directories. I did so because I didn't want to take a chance that the "/usr/local" → "/Local" symlinks would cause problems with its operations. So I decided to specify the actual directories rather than the symlinks.

[Bo98]

Sometimes when you build software, it stores the installed prefix in the binary. Such software are referred to as being "not relocatable". Our bottles are built using the default prefix, so when you install a formula which doesn't have a relocatable bottle then you have no choice but to build it from source. This is what is happening in your case - you have installed a formula which is not relocatable so it instead builds from source. We warn you because:

• Builds from source take longer. Much much longer. Some can be over an hour.
• Builds from source have less guarantees it will work. A lot can go wrong - there's a lot more happening compared to a simple bottle install which really just does a simple tar extraction.
• We do not actively test whether formulae work on non-default prefixes. This is less of an issue now that we have different prefixes for Intel and arm64 - so we are actively testing on two prefixes, and thus any hardcoded values have probably been fixed.

We are hoping to improve the relocatablity of bottles (Homebrew/brew#10846), but it's not a trivial task.

rendering the packages unusable?

For the most part, the final install should be functionally the same as installing from a bottle on the default prefix. Maybe the build will detect some extra installed libraries and use them to enable some features (this is called "opportunistic linking").

[bgshacklett]

What, generally, makes a given bottle non-relocatable? Is that something which would, theoretically, need to be patched in the upstream software or is it something to do with how bottles are compiled? Also, how does Homebrew know when a given formula is non-relocatable?

[carlocab]

Glossing over some details, the relocatability check just dumps all the strings in each binary object in the bottle and checks them for references to HOMEBREW_PREFIX. (It's actually a little more selective than that, but that's the idea.) If those exist, then the bottle is considered non-relocatable. Otherwise, the bottle is relocatable.

Is that something which would, theoretically, need to be patched in the upstream software or is it something to do with how bottles are compiled?

It is, in principle, possible to patch this out in upstream software, but this is typically very difficult.

[SMillerDev]

I'm working on a computer owned by my employer. They will not include my changes to "/usr/local" in backups. So, I created "/Local" and I symlinked "/usr/local" to it. They will backup my "/Local", so I'm happy.

As an aside, why would you want to back up homebrew binaries? You can always redownload them. Personally I use brew bundle dump to just store a list of packages that I backup and if I ever need to restore I do brew bundle install.

[asmaier]

It is a pity that work on Homebrew/brew#10846 has been stopped. Because of that one cannot really use homebrew installed in a non-default directory, e.g. the users home directory. But this makes it impossible to use homebrew without sudo, because /opt/homebrew on most systems is a directory where one needs sudo rights to create it. This unfortunately is a show stopper for using homebrew in enterprise, where users usually don't have sudo right on their workplace PCs.

[SMillerDev]

That's where https://workbrew.com might be more beneficial.

[asmaier]

Workbrew has many additional features we don't need. We would only need homebrew without sudo.

[SMillerDev]

Personally I just deploy the pkg installer through MDM. No admin access needed for the users (unless they need certain casks)