S3 cached binaries incompatible with all but most recent Macs

[mroth]

Whatever method is being used to generate the cached boxen version of homebrew binary bottles that are stored on S3 seems to be generating binaries that will die fatally on anything but the newest intel architecture macs.

See, for example,
#17
boxen/puppet-emacs#5

This affects Macs that are not very old at all, for example, 2011 model Macbook Airs (current revision) that use Core2Duo processors.

I'm not sure if there is a way to generate more compatible binaries? (If not, machines that cannot use the precompiled binaries should not download them from S3, and instead compile from source. As it is currently, they happily install a bunch of broken binaries, which borks all of boxen (and other things) since that includes a broken version of git.)

[mroth]

Another for reference:
boxen/puppet-postgresql#8

[shanesveller]

I'm seeing this as well, on a mid-2010 Mac Mini with an Intel Core 2 Duo. It's not my primary dev machine, but I'm still hoping someone finds a way to opt-out of the S3 binaries or that this puppet module gets updated to circumvent this issue.

[goxberry]

I'm curious as to the hardware requirements of the S3 binaries. Can anyone on the Boxen team comment on how recent your hardware must be for S3 Homebrew bottles to work?

[wfarr]

It depends on GCC vs clang, and what optimization levels these things are
building under. We're not doing anything to alter default CFLAGS or
CPPFLAGS, but my intuition here is guessing some things might be being
built with -O3, which would certainly cause these sorts of segfaults.

On Tuesday, April 30, 2013, Geoffrey Oxberry wrote:

I'm curious as to the hardware requirements of the S3 binaries. Can anyone
on the Boxen team comment on how recent your hardware must be for S3
Homebrew bottles to work?

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/18#issuecomment-17243169
.

[theflow]

I'm seeing the same thing on a Core 2 Duo from end of 2010. "Illegal instruction: 4" or similar for python, nginx, imagemagick so far.

[rosner]

+1 We're seeing this on an older Mac Mini 2GHz Core 2 Duo from early 2009.

[mistydemeo]

In Homebrew, we build binaries for Core 2 in 64-bit mode, and Core in 32-bit mode. You can see the flags we use here:

https://github.com/mxcl/homebrew/blob/master/Library/Homebrew/os/mac/hardware.rb#L2-L10

[shanesveller]

Sounds like this is something specific to the way boxen generates the binary bottles. Do we have any workaround to tell a boxen run to always compile from source no matter what?

[MikeMcQuaid]

Are you building bottles with --build-bottle?

[bjjsre]

This will also occur on VMs in VirtualBox/VMWare (on mac hardware). To resolve, I think it would require both an option to not use the binary bottles and a workaround/resolution to this one: Homebrew/legacy-homebrew#21778

[mistydemeo]

@b2jrock If Boxen used Homebrew's bottle-generating mechanism (e.g. using the --build-bottle commandline switch), Homebrew/legacy-homebrew#21778 would be irrelevant - the binaries would be built for the oldest compatible CPU.

[bjjsre]

I've found if I add --install-from-source to the package options to the python package, the issue resolves for me. However, this would need to be done per module. The resulting package definition looks like (python/manifests/init.pp):

package { 'boxen/brews/python':
    ensure  => $version,
    provider => homebrew,
    install_options => ['--build-from-source'],
    require => [ Class['xquartz'], File['/opt/boxen/homebrew/Library/ENV/4.3/cc'] ],
  }

[razic]

@b2jrock i am having very good experience with that approach. however, i just made it a directive default in manifests/site.pp with the other Package defaults:

Package {
  provider => homebrew,
  require  => Class['homebrew'],
  install_options => ['--build-from-source'],
}

now everything builds from source, which is much more reliable than the s3 bottles; albeit slower.

[MikeMcQuaid]

The solution here is using --build-bottle to create binary packages.

[hparra]

If it's still is not building from source, even with install_options => ['--build-from-source'], then nuke boxen and start again. There may be some strange caching if you've tried building before without that option. (?)

Confirming this works on ancient 2007 MBP!

[MikeMcQuaid]

This is now fixed, script/sync in the main boxen repo will refuse to upload if it hasn't been built as a "real" bottle.