python failed to build on 10.8.2 #15241

audioplastic opened this Issue Oct 2, 2012 · 18 comments

4 participants


Full gist available here:

macmini:~ nick$ brew install python --framework --universal
==> Downloading
Already downloaded: /Library/Caches/Homebrew/python-2.7.3.tar.bz2
==> ./configure --prefix=/usr/local/Cellar/python/2.7.3 --enable-ipv6 --datarootdir=/usr/local/Cellar/python/2.7.3/share --datadir=/usr/local/Cellar/python/2.7.3/share --enable-framework=/
==> make
==> make install PYTHONAPPSDIR=/usr/local/Cellar/python/2.7.3
ln -sf pythonw2 "/usr/local/Cellar/python/2.7.3/Frameworks/Python.framework/Versions/2.7/bin/pythonw"
lipo -extract i386 -output /usr/local/Cellar/python/2.7.3/Frameworks/Python.framework/Versions/2.7/bin/python2.7-32 pythonw
lipo: input file (pythonw) must be a fat file when the -extract option is specified
make[1]: *** [install_pythonw] Error 1
make: *** [frameworkinstallapps] Error 2

Error: python did not build
Logs: /Users/nick/Library/Logs/Homebrew/python/

Do you actually need a fat binary with 32bit on your shiny new 10.8.2?

I suppose brew install python (It's always framework since a few months now) should work.
I'll check if the universal build is broken. Also please provide the output of brew doctor and brew --config.


nick$ brew doctor
Your system is raring to brew.

nick$ brew --config
HEAD: d20a094
HOMEBREW_CELLAR: /usr/local/Cellar
CPU: dual-core 64-bit penryn
OS X: 10.8.2-x86_64
Xcode: 4.5
LLVM-GCC: build 2336
Clang: 4.1 build 421
X11: 2.7.4 => /opt/X11
System Ruby: 1.8.7-358
Perl: /usr/bin/perl
Python: /usr/bin/python
Ruby: /usr/bin/ruby => /System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/bin/ruby


Yep, confirmed. Thanks. brew install python --universal errors out with the messages reported above.

Workaround: brew install python --universal --env=std


Sweet. Thanks


@audioplastic Thanks, your system is perfect. But out of curiosity, why "--universal"? There are a lot of old blog post floating around which state to use --framework and --universal because at one point we had some libs (most notably wxmac) that were only available in 32bit. And by old, I mean outdated.

@mxcl Does the new superenv build style support universal at all?

I see brew: superenv removed: -arch i386 -arch x86_64 -L/homebrew/lib -L/homebrew/lib so no wonder that there is no fat binary. Should the option :universal handle this?


Under superenv, universal arch flags are removed unless the formula calls ENV.universal_binary, which python does not (instead, it passes some flags to configure).


@jacknagel So why can't option :universal handle this - as I was assuming?


What exactly should it do? It can't do anything specific like call ENV.univeral_binary, because universal has to be implemented on a per-formula basis (i.e., there are things where it is not as simple as just adding the appropriate arch flags).


@jacknagel alright. My fault. Will update the python formula with ENV.universal_binary.


Still, I think that superenv could be made so smart to let the usual -arch flags through if build.universal?.

Anyways, I have PR for python with ENV.universal_binary, @jacknagel.


When I asked, "what exactly should it do?" I wasn't really being rhetorical. If the formula doesn't need ENV.universal_binary to build universal (and it appears that it adds the appropriate flags on its own given what we are passing to configure), we shouldn't add it.

Rather, I imagine something like this:

  • If a formula defines option :universal and the user asks for a universal build, then the formula's BuildEnvironment object records this;
  • the build script checks f.env.allow_universal?, and if it is true it instructs superenv to allow -arch flags (say, ENV.allow_universal!
  • formulae where a simple ENV.universal_binary is enough can also define env :universal, and the build script checks f.env.universal? and if it is true calls ENV.universal_binary.

When I asked, "what exactly should it do?" I wasn't really being rhetorical.

Ok, I understood it more like "there is no way to do it" - and I stopped thinking about it.

Your suggestion sounds appealing (though I lack the deep understanding of how options are processed here).

The last of your three bullets, is however, a bit unclear to me: Does this mean it's a shorthand for ENV.universal_binary if build.universal?? Not sure if we need to introduce yet another env :something command here.

Homebrew member

superenv requires ENV.universal or it doesn't allow it. Possibly this is OTT, but there have been build problems in the past due to incorrect arch flags. Superenv tries to prevent such problems at the expense of universal working without telling it to allow it.


I updated homebrew just now, but still needed to do a

brew link -f python

Not sure if we need to introduce yet another env :something command here.

The original point of the env DSL idea was to get rid of ENV.universal_binary in formulae.


@audioplastic You will need to brew update, brew rm python and brew install python --universal.

@jacknagel ok, fair enough. If that is a replacement, I am fine with it :-)


It should be fixed. Please close, if so.

@nkraft nkraft referenced this issue in Homebrew/homebrew-versions Nov 18, 2012

python31 with --universal fails #62

@xu-cheng xu-cheng locked and limited conversation to collaborators Feb 16, 2016
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.