3 ms·

> Homebrew 1.9.0 no longer runs on 32-bit Intel CPUs. Where does this constraint come from? Homebrew is written in Ruby. To cut down on compilation from sourc

by bhaak 8y ago

> Homebrew 1.9.0 no longer runs on 32-bit Intel CPUs. Where does this constraint come from? Homebrew is written in Ruby. To cut down on compilation from source issues? Or Homebrew uses language features from Ruby versions greater than what Apple shipped in their latest 32-bit supported OSX versions (as homebrew insists on using the system default binaries)?

amypinka 8y ago
From: https://docs.brew.sh/Linuxbrew https://docs.brew.sh/Linuxbrew > Linuxbrew does not currently support 32-bit x86 platforms. It would be possible for Linuxbrew to work on 32-bit x86 platforms with some effort. An interested and dedicated person could maintain a fork of Homebrew to develop support for 32-bit x86.
Hackbraten 8y ago
Homebrew builds individual binary bottles per package and per macOS version, but not per target architecture. In other words: at bottle creation time (server-side), Homebrew tells the compiler to output code that runs on older CPUs. The downside of this is that end users who install bottles never get to enjoy the benefits of latest CPU instruction sets, such as SSE 4.1/4.2. From time to time, Homebrew raises the bar to keep the balance between performance and compatibility. From Homebrew 1.9.0, bottles are built to use the features of the Penryn/Core 2 microarchitecture or higher, or in other words: Homebrew no longer supports CPU microarchitectures older than Penryn/Core 2.
- bhaak 8y ago
  Your explanation makes sense for bottles, not for Homebrew itself. Homebrew is still at its core "build from source". This is exactly what the bottle bot does, building the same formulas you have on your machine. Why should this no longer work?
  - Hackbraten 8y ago
    Unless the user sets specific build options, or runs `brew install --build-from-source`, Homebrew installs core packages from a bottle hosted on Bintray by default. While I agree in that building from source is somewhat at Homebrew’s core (as that’s what happens at bottle creation time), the intention is to deliver core packages to end users via bottle as often as possible.
mikemcquaid 8y ago
It's not so much a constraint as something that has enabled us to cleanup code used only on extremely old Macs.

by bhaak 8y ago

amypinka 8y ago

From: https://docs.brew.sh/Linuxbrew https://docs.brew.sh/Linuxbrew > Linuxbrew does not currently support 32-bit x86 platforms. It would be possible for Linuxbrew to work on 32-bit x86 platforms with some effort. An interested and dedicated person could maintain a fork of Homebrew to develop support for 32-bit x86.

Hackbraten 8y ago

Homebrew builds individual binary bottles per package and per macOS version, but not per target architecture. In other words: at bottle creation time (server-side), Homebrew tells the compiler to output code that runs on older CPUs. The downside of this is that end users who install bottles never get to enjoy the benefits of latest CPU instruction sets, such as SSE 4.1/4.2. From time to time, Homebrew raises the bar to keep the balance between performance and compatibility. From Homebrew 1.9.0, bottles are built to use the features of the Penryn/Core 2 microarchitecture or higher, or in other words: Homebrew no longer supports CPU microarchitectures older than Penryn/Core 2.

bhaak 8y ago
Your explanation makes sense for bottles, not for Homebrew itself. Homebrew is still at its core "build from source". This is exactly what the bottle bot does, building the same formulas you have on your machine. Why should this no longer work?
- Hackbraten 8y ago
  Unless the user sets specific build options, or runs `brew install --build-from-source`, Homebrew installs core packages from a bottle hosted on Bintray by default. While I agree in that building from source is somewhat at Homebrew’s core (as that’s what happens at bottle creation time), the intention is to deliver core packages to end users via bottle as often as possible.

mikemcquaid 8y ago

It's not so much a constraint as something that has enabled us to cleanup code used only on extremely old Macs.