pip install fails on Mac laptop

[manodeep]

I tried to install halotools with (conda) pip pip install halotools and the install fails with

---

gcc -fno-strict-aliasing -I/Users/manodeep1_Old/anaconda/include -arch x86_64 -isysroot /Developer/SDKs/MacOSX10.5.sdk -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -I/Users/manodeep1_Old/anaconda/include/python2.7 -c halotools/_compiler.c -o build/temp.macosx-10.5-x86_64-2.7/halotools/_compiler.o
In file included from /opt/local/lib/gcc5/gcc/x86_64-apple-darwin15/5.3.0/include/stdint.h:9:0,
                 from /Developer/SDKs/MacOSX10.5.sdk/usr/include/inttypes.h:255,
                 from /Users/manodeep1_Old/anaconda/include/python2.7/pyport.h:9,
                 from /Users/manodeep1_Old/anaconda/include/python2.7/Python.h:58,
                 from halotools/_compiler.c:1:
/opt/local/lib/gcc5/gcc/x86_64-apple-darwin15/5.3.0/include-fixed/stdint.h:27:32: fatal error: sys/_types/_int8_t.h: No such file or directory
compilation terminated.
error: command 'gcc' failed with exit status 1

---

A similar error occurs during the build step as well. I have copy-pasted the one from the install step.

[manodeep]

Seems to be solved by using: export CC=clang; pip install halotools

[aphearin]

Reopening this until I can address this in the documentation (at minimum).

CC @eteq

[eteq]

@manodeep - is it possible you're using the Mac OS X built-in Python? It sometimes yields weird linker errors like that, especially if you mix it with gcc (it's actually built with clang but sometimes thinks that it should use gcc).

If so, that's basically the problem. Life will be easier if you never use the OS X Python.

[manodeep]

@eteq I use conda python + pip. I checked that both pip and python point to the anaconda directory. gcc is through macports, as is clang.

I agree that the includepath pointing to the MAC SDK is highly suspicious - I wonder if macports pulls that in during gcc install.

[eteq]

Huh, that's quite strange. I have essentially the identical setup on the laptop I am type this from right now, and it defaults to clang. I don't suppose you've set your local CC variable in the shell to point to gcc? Or is there a /usr/local/bin/cc that's pointing to gcc (instead of clang like it normally is on a mac)?

Based on the above, though, it seems like this is an issue with your local configuration and not directly the fault of halotools, right? And it's not clear that the general advice should be "use clange" because sometimes gcc is desired (i.e. on linux). So in that case it might be ok to close this without modifying halotools at all, although @aphearin can be the final judge of that.

[manodeep]

I wanted to note that this issue still remains. Just did a fresh git clone and tried python setup.py install and encountered the exact same error. As before, is solvable by export CC=clang. Just highlights the issue that using real gcc on a Mac is trouble-some. @eteq I have the exact same issue with installing astropy

[aphearin]

Thanks for checking @manodeep.

@eteq - do you have any better suggestions besides putting a note in the install docs to export clang in the event that this comes up? I was planning on releasing v0.3 tomorrow.

[eteq]

Nothing really leaps to mind. Although if @manodeep has the same problem installing Astropy, I'm even more confused because I also have gcc from macports, and don't see this at all.

Maybe @manodeep has the path set up in a different order or something? @manodeep, if you just do cc do you get gcc or clang? (I get clang, but I think at one point I set it up to do that on purpose...)

[manodeep]

cc points to /usr/bin/cc. /usr/bin/cc --version gives:

Apple LLVM version 7.3.0 (clang-703.0.31)
Target: x86_64-apple-darwin15.4.0
Thread model: posix
InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin

PATH contains conda/bin, /opt/local/[s]bin, /usr/local/bin and then /usr/bin -- in that order. python picks up the conda version.

[eteq]

Huh. Well that's weird, @manodeep .

One other thing I just noticed, though: when I start anaconda python it givesGCC 4.2.1 (Apple Inc. build 5577) as the matched compiler. And the gccs I have installed are all 4.x's. Whereas from the lib directories you listed above it looks like you might be on gcc v5.3 - maybe that's the underlying incompatibility? That something changed in the cstdlib from gcc 4.x to 5.x? Still doesn't explain why you're not getting clang as the default though - I certainly am.

Which makes me think of one other thing: have you ever used xcode-select? I have a hazy memory that that's what you're supposed to use to set up clang correctly. Maybe that needs to be run?

[manodeep]

I get a similar output as well from python -- [GCC 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2336.11.00)] on darwin. /usr/bin/gcc --version gives me Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr --with-gxx-include-dir=/usr/include/c++/4.2.1

However, my gcc points to macports gcc (which resolves to one of 4.6, 4.8, 5.3 and 6.1) - so these Xcode directories should really not be used anyway.

The good news is that now I can install halotools. I removed all previous versions, and then pip install halotools worked just normally. Checking the install log, I can see that the compilation line has changed and does not contain the isysroot variable anymore.

---

gcc -fno-strict-aliasing -I/Users/manodeep1_Old/anaconda/include -arch x86_64 -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -I/Users/manodeep1_Old/anaconda/include/python2.7 -c halotools/_compiler.c -o build/temp.macosx-10.6-x86_64-2.7/halotools/_compiler.o

gcc -bundle -undefined dynamic_lookup -L/Users/manodeep1_Old/anaconda/lib -arch x86_64 -arch x86_64 build/temp.macosx-10.6-x86_64-2.7/halotools/_compiler.o -L/Users/manodeep1_Old/anaconda/lib -o build/lib.macosx-10.6-x86_64-2.7/halotools/_compiler.so

---

Something in distutils or setup.py changed I am assuming.