mod_wsgi: compile error on ML, OSX10.8.xctoolchain

[2bits]

mod_wsgi fails to build on Mountain Lion due to its using /usr/share/apr-1/build-1/libtool to compile and the fact that apr-1 has an invalid path buried in its apr-1-config and libtool files.

/usr/share/apr-1/build-1/libtool --tag=CC --mode=link /usr/bin/clang -o mod_wsgi.la  -rpath /usr/libexec/apache2 -module -avoid-version    mod_wsgi.lo -L/usr/local/lib -Wl,-F/usr/local/Cellar/python/2.7.3/Frameworks -framework Python -u _PyMac_Error -arch x86_64 -ldl -framework CoreFoundation
/Applications/Xcode.app/Contents/Developer/Toolchains/OSX10.8.xctoolchain/usr/bin/cc ${wl}-undefined ${wl}dynamic_lookup -o .libs/mod_wsgi.so -bundle  .libs/mod_wsgi.o  -L/usr/local/lib -ldl  -Wl,-F/usr/local/Cellar/python/2.7.3/Frameworks -framework Python -arch x86_64 -framework CoreFoundation
/usr/share/apr-1/build-1/libtool: line 4574: /Applications/Xcode.app/Contents/Developer/Toolchains/OSX10.8.xctoolchain/usr/bin/cc: No such file or directory
apxs:Error: Command failed with rc=8323072
.
make: *** [mod_wsgi.la] Error 1

Unlink serf, this can't be fixed easily in the formula because there are no configure variables that can be set. The only known workaround is to symlink the correct toolchain path to the one it's looking for that doesn't exist:

ln -s /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/cc /Applications/Xcode.app`/Contents/Developer/Toolchains/OSX10.8.xctoolchain/usr/bin/cc

I suppose we could make a requirement for this, but I'm not thrilled by that. I haven't bug reported this to Apple yet. This was originally reported in #13586

[joemaller]

I spent several hours banging my head against this yesterday. I was looking for some way to override apr-1-config's values, but they're pretty well baked in.

This might very well be overkill, what about just compiling our own apr? It's fairly lightweight and would allow us to completely route around the botched apr config values in 10.8.

I likely won't be able to get to this today, but it seems worth looking into.

[joemaller]

well, apr was easy enough to install, but apxs was still pulling from the original location. So no go on that.

[2bits]

It's probably better not to roll apr and apxs. Homebrew doesn't like to duplicate system software.

[2bits]

Doing a search through regular files to search for "OSX10.8.xctoolchain" turned up several possibly broken apps:

/usr/bin/apr-1-config
/usr/bin/net-snmp-config
/usr/lib/postgresql/pgxs/src/Makefile.global
/usr/share/apr-1/build-1/apr_rules.mk
/usr/share/apr-1/build-1/libtool
/usr/share/httpd/build/config_vars.mk

It's possible that editing all those file to be correct would fix this. Dunno.

[joemaller]

The two most relevant files are apr_rules.mk and config_vars.mk. Changes to config_vars.mk are reflected by apxs, but not by apr-1-config.

After fussing with this for a while, I don't know that it's something we can fix without recompiling APR or writing a new makefile which calls the compiler and libtool directly instead of using apxs.

I posted a question on StackOverflow, Changing APR-embedded values returned by apr-1-config?
but I'm not expecting much.

The symlink workaround fixes this, maybe that should just be added to brew doctor?

[adamv]

We've migrated this formula to: https://github.com/Homebrew/homebrew-apache