WCS build fails on Mac - #98

This is probably the same as #31. @mdboom's compiler detection doesn't always seem to work. You can manually set the compiler with export CC=/usr/bin/clang.

I'm actually using 10.6 (not 10.7 as in #31), and didn't have any issues until some time in the last few days, so something must have changed in the compiler detection that is causing this issue.

The compiler detection code has not changed for some time and it is still working on Lion. Perhaps there was an XCode update recently? If astropy really is at fault, and I can't reproduce this here, maybe you could try running git bisect to determine when it broke? Or at least roll back to sometime last week when you last remember it working.

When you do cc --version what do you get? If you add this version string (i.e. the first token of that output) to compiler_mapping in setup_helpers.py does that resolve the issue? We may want to have a blanket black list on all versions of llvm-gcc (which is a half-baked transitional compiler anyway) instead of targeting very specific versions of it as we do now. (We don't really know how widespread this compiler bug is.)

If I change compiler_mapping to:

compiler_mapping = {
    'i686-apple-darwin10-llvm-gcc-4.2': 'clang',
    'i686-apple-darwin11-llvm-gcc-4.2': 'clang'
    }

it uses clang to compile, and works fine. Shall I commit that change?

That seems fine -- but I think I'll change it to match on any llvm-gcc-4.2, regardless of darwin version. That should catch more of these cases in the future. Expect a pull request shortly which I'll ask you to test in your environment.

By the way, this makes sense - darwin10 is in MacOS 10.6, and darwin11 is in MacOS 10.7, so maybe these are two only two default mac compilers we need to worry about?

@mdboom - ok, thanks!

I haven't done any actual experimenting to this end but I've found that the compiler adjustment is highly dependent on the Python I'm using. With EPD or python.org binaries it was never caught and I'd have to set CC manually. Right now I have Python 2.7 and Python 3.2 built with the exact same llvm-gcc and under Python 2 the compiler gets automatically switched to clang, but under Python 3 I have to set CC manually to /usr/bin/clang.

I'll have to see if @mdboom's fix changes things and if not I'll actually try to track down the problem.

@mdboom, on a totally separate topic, how do you attach code to an open issue and turn it into a pull request?

@jiffyclub: I have a dorky little script that uses curl to call the github API here: http://develop.github.com/p/pulls.html

@mdboom I'm getting this error trying to test your branch on Python 3:

(python3)astropy 33 >:python setup.py test  
Traceback (most recent call last):
  File "setup.py", line 24, in <module>
    setup_helpers.adjust_compiler()
  File "/Users/jiffyclub/astropy/astropy/setup_helpers.py", line 368, in adjust_compiler
    if re.match(broken, version):
  File "/Users/jiffyclub/.virtualenvs/python3/lib/python3.2/re.py", line 153, in match
    return _compile(pattern, flags).match(string)
TypeError: can't use a string pattern on a bytes-like object

It looks like the version object is a bytes object.

@jiffyclub: I've pushed what I hope fixes that to this branch. Also rebased to get other Python 3 fixes made today.

It's not liking that either:

(python3)astropy 55 >:python setup.py test
Traceback (most recent call last):
  File "setup.py", line 24, in <module>
    setup_helpers.adjust_compiler()
  File "/Users/jiffyclub/astropy/astropy/setup_helpers.py", line 369, in adjust_compiler
    os.environ['CC'] = fixed
  File "/Users/jiffyclub/.virtualenvs/python3/lib/python3.2/os.py", line 455, in __setitem__
    value = self.encodevalue(value)
  File "/Users/jiffyclub/.virtualenvs/python3/lib/python3.2/os.py", line 517, in encode
    raise TypeError("str expected, not %s" % type(value).__name__)
TypeError: str expected, not bytes

I guess the good news is that it is actually trying to change the compiler.

If you remove the 'b' from b'clang' does it work?

Yes, works on Python 2.7 and 3.2.

One funny thing I just noticed is that the compiler gets switched to clang for compiling all the *.o files, but then /usr/bin/llvm-gcc is used to bundle them into _wcs.o. Maybe that's supposed to happen? Doesn't seem to have any negative side effects.

After removing the b from b'clang', it works for me in MacOS 10.6 (darwin10) with 2.6, 2.7, 3.1, and 3.2.

I know I'm a bit behind here, but because the topic came up and I just figured out how to do this... it's pretty easy to attach code to issues inside python via the github API w/ the requests package (http://docs.python-requests.org/en/latest/index.html). e.g. to attach my version-renumbering branch to issue 52:

import requests,json

jdata = json.dumps({'issue':'52','head':'eteq:version-renumbering','base':'master'})
res = requests.post('https://api.github.com/repos/astropy/astropy/pulls',data=jdata,auth=('eteq','12345'))
print res

And if it tells you the return code is 201, you were sucessful.

(And no, my password is not actually '12345'. That's the kind of combination an idiot would have on his luggage...)

@jiffyclub: wrt a different command used to link -- it's probably fine that it happens that way. gcc is designed to be run as either a compiler or a linker depending on what is passed on the commandline. When run as a linker, it merely punts along to the ld command. Most Python distros I've seen set both the compiler and linker to the same command, but the adjust_compiler stuff here only changes the compiler, since only the compiler is buggy and needs to be changed (at least that I've seen). I think we can ignore this as long as it's working.