GalSim on OSX 10.9?

[rmandelb]

I was wondering if anyone else has compiled GalSim on OSX 10.9? I have a new computer and am trying to install GalSim on it, but I'm hitting trouble with some of the prerequisites. I've been doing a lot of my GalSim work on the cluster at CMU, but it would be nice to be able to work locally! Any tips from someone who made the transition to 10.9 successfully would be great.

Right now my trouble is TMV:

I am trying to compile it using clang; if I do g++ --version the output is

Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr --with-gxx-includedir=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/usr/include/c++/4.2.1
Apple LLVM version 5.0 (clang-500.2.79) (based on LLVM 3.3svn)
Target: x86_64-apple-darwin13.0.2
Thread model: posix

For scons, I am using the WITH_BLAS=false option. When I start compiling TMV I get some warnings near the beginning, but then there are outright errors like

gcc -o lib/libtmv.0.dylib -dynamiclib -dynamic -Wl,-install_name,/Users/rmandelb/software/tmv0.71/lib/libtmv.0.dylib -Wl,-compatibility_version,0.70 -Wl,-current_version,0.71 src/TMV_Vector.os src/TMV_MultVV.os src/TMV_AddVV.os src/TMV_MultXV.os src/TMV_BaseMatrix.os src/TMV_Matrix.os src/TMV_MultXM.os src/TMV_AddMM.os src/TMV_MultMV.os src/TMV_Rank1_VVM.os src/TMV_MultMM_CCC.os src/TMV_MultMM_CRC.os src/TMV_MultMM_RCC.os src/TMV_MultMM_Block.os src/TMV_IntegerDet.os src/TMV_DiagMatrix.os src/TMV_MultDV.os src/TMV_AddDM.os src/TMV_MultDM.os src/TMV_TriMatrix.os src/TMV_TriDiv.os src/TMV_MultUV.os src/TMV_MultXU.os src/TMV_AddUU.os src/TMV_MultUM.os src/TMV_MultUL.os src/TMV_MultUU.os src/TMV_MultDU.os src/TMV_Givens.os src/TMV_Householder.os src/TMV_LUD.os src/TMV_LUDecompose.os src/TMV_LUDiv.os src/TMV_LUInverse.os src/TMV_QRD.os src/TMV_QRDecompose.os src/TMV_QRDiv.os src/TMV_PackedQ.os src/TMV_QRInverse.os src/TMV_GetQFromQR.os src/TMV_QRUpdate.os src/TMV_QRDowndate.os src/TMV_QRPD.os src/TMV_SVD.os src/TMV_SVDecompose.os src/TMV_SVDecompose_Bidiag.os src/TMV_SVDecompose_QR.os src/TMV_SVDiv.os src/TMV_TriDiv_V.os src/TMV_TriDiv_M.os src/TMV_TriDiv_L.os src/TMV_TriInverse.os src/TMV_MultMM.os src/TMV_MultMM_OpenMP.os src/TMV_SVDecompose_DC.os src/TMV_QRPDecompose.os -Llib
gcc -o src/TMV_Rank2_VVS.os -c -fPIC -DTMV_NDEBUG -DNOBLAS -Iinclude src/TMV_Rank2_VVS.cpp
Undefined symbols for architecture x86_64:
  "std::string::find_last_not_of(std::string const&, unsigned long) const", referenced from:
      tmv::TMV_Reader::trim(std::string) in TMV_Vector.os
      tmv::TMV_Reader::trim(std::string) in TMV_Matrix.os
      tmv::TMV_Reader::trim(std::string) in TMV_DiagMatrix.os
      tmv::TMV_Reader::trim(std::string) in TMV_TriMatrix.os
  "std::string::find_first_not_of(std::string const&, unsigned long) const", referenced from:
      tmv::TMV_Reader::trim(std::string) in TMV_Vector.os
      tmv::TMV_Reader::trim(std::string) in TMV_Matrix.os
      tmv::TMV_Reader::trim(std::string) in TMV_DiagMatrix.os
      tmv::TMV_Reader::trim(std::string) in TMV_TriMatrix.os
  "std::string::find(char, unsigned long) const", referenced from:
      tmv::TMV_Reader::skipWhiteSpace() const in TMV_Vector.os
      tmv::TMV_Reader::skipWhiteSpace() const in TMV_Matrix.os
      tmv::TMV_Reader::skipWhiteSpace() const in TMV_DiagMatrix.os
      tmv::TMV_Reader::skipWhiteSpace() const in TMV_TriMatrix.os
  "std::string::size() const", referenced from:
      tmv::TMV_Reader::readStr(std::string const&, std::string&, std::string&) const in TMV_Vector.os
      tmv::TMV_Reader::readStr(std::string const&, std::string&, std::string&) const in TMV_Matrix.os
      tmv::TMV_Reader::readStr(std::string const&, std::string&, std::string&) const in TMV_DiagMatrix.os
      tmv::TMV_Reader::readStr(std::string const&, std::string&, std::string&) const in TMV_TriMatrix.os

(and on and on like this)

@rmjarvis , any ideas?

[rmandelb]

More update: I was wondering if I should blame clang, so I installed gcc v4.9, and got the same error message with it.

[rmjarvis]

I'm confused by the fact that the compiler doing the link step seems to be gcc rather than g++. Try setting CXX=g++ explicitly (scons should have used that automatically, but maybe something weird happened) and see if that helps.

[jmeyers314]

I've also been working on this today.

My g++ --version returns

Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr --with-gxx-include-dir=/usr/include/c++/4.2.1
Apple LLVM version 5.0 (clang-500.2.79) (based on LLVM 3.3svn)
Target: x86_64-apple-darwin13.0.0
Thread model: posix

which looks similar to @rmandelb's but with a slightly simpler --with-gxx-include-dir path. FWIW, I got my Xcode command line tools by running xcode-select --install, as suggested by the Macports Mavericks migration instructions.

My issue compiling TMV is openmp. When I run with the default scons WITH_OPENMP=True, I get the error:

ld: library not found for -lgomp
clang: error: linker command failed with exit code 1 (use -v to see invocation)
scons: *** [lib/libtmv_symband.0.dylib] Error 1
scons: building terminated because of errors.

If I compile with scons WITH_OPENMP=False, though, everything seems to be fine, and galsim compiles and tests fine thereafter.

[barnabytprowe]

Hi all. Sorry I've been offline most of the day. I think at least one of the the complaints (that of @jmeyers314 ) is simply due to the fact that:

1. In OSX 9 it seems that Apple has moved totally to clang as its system compiler, and /usr/bin/g++ is in fact clang but masquerades as g++! This is why clang shows up in your g++ --version version!
2. TMV detects g++ but doesn't know about 1.
3. TMV thinks that the g++ version is high enough to include OpenMP, tries to link to it, but the Mavericks system clang doesn't yet support OpenMP.

That's why the WITH_OPENMP=False option makes things work, I believe...

[rmjarvis]

ld: library not found for -lgomp
clang: error: linker command failed with exit code 1 (use -v to see invocation)

Sorry. This is a known problem with Apple's recent XCode releases. They switched to using clang, which does not support OpenMP yet. The TMV scons stuff knows that clang can't do OpenMP, so it will automatically disable it if you use clang++ as the compiler. The problem is that Apple decided to lie about the name of the compiler. They call it g++, even though it isn't compatible with g++. Pretty lame, IMO. It's one thing to alias c++ to the compiler that you want, but to alias g++ to something that isn't actually g++ is bad practice, IMHO.

So the options are either to use WITH_OPENMP=false as you did, or do CXX=clang++, which will get TMV to figure it out automatically.

It's something I need to fix for the next release, but I haven't done so yet.

[rmjarvis]

Ah. As Barney just said as well. :)

[barnabytprowe]

Haha! I totally agree that this is pretty lame though: we surely won't be the only project that will try to use OpenMP by default and be thwarted by this cloak-and-dagger compiler naming. gcc must also think it's lame too.

[rmandelb]

Lame. Shall I put something about this in the installation FAQ?

Now that I've put CXX=clang++, the TMV compilation proceeds smoothly. There is one random warning, but nothing fatal.

Moving right along, I decided to try compiling GalSIm just to see if it recognizes that TMV is compiled and linked properly. (I did this in the full expectation that it was going to whine at some later point because I need to recompile boost with the new compiler, which I didn't really feel like doing tonight. I'll find a spare 4 hours sometime for that one. ;) The results were mixed:

(1) It is happy with TMV, but
(2) It claims to be unable to import NumPy. What is interesting is that if I open up the version of python it's using I am perfectly capable of importing NumPy, so I'm not sure what is going on with that. [EDIT: BEFORE READING FURTHER IN THIS POST, PLEASE SEE NEXT MESSAGE.]

Checking if we can build against NumPy... 
Unable to import numpy using the python executable:
/Library/Frameworks/EPD64.framework/Versions/Current/bin/python

For reference, the unhappy part of config.log is here:

scons: Configure: Checking if we can build against NumPy... 
.sconf_temp/conftest_57 <-
  |import numpy; print numpy.get_include()
/Library/Frameworks/EPD64.framework/Versions/Current/bin/python < .sconf_temp/conftest_57 > .sconf_temp/conftest_57.out
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/Library/Frameworks/EPD64.framework/Versions/7.2/lib/python2.7/site-packages/numpy/__init__.py", line 143, in <module>
    import add_newdocs
  File "/Library/Frameworks/EPD64.framework/Versions/7.2/lib/python2.7/site-packages/numpy/add_newdocs.py", line 9, in <module>
    from numpy.lib import add_newdoc
  File "/Library/Frameworks/EPD64.framework/Versions/7.2/lib/python2.7/site-packages/numpy/lib/__init__.py", line 4, in <module>
    from type_check import *
  File "/Library/Frameworks/EPD64.framework/Versions/7.2/lib/python2.7/site-packages/numpy/lib/type_check.py", line 8, in <module>
    import numpy.core.numeric as _nx
  File "/Library/Frameworks/EPD64.framework/Versions/7.2/lib/python2.7/site-packages/numpy/core/__init__.py", line 40, in <module>
    from numpy.testing import Tester
  File "/Library/Frameworks/EPD64.framework/Versions/7.2/lib/python2.7/site-packages/numpy/testing/__init__.py", line 8, in <module>
    from unittest import TestCase
  File "/Library/Frameworks/EPD64.framework/Versions/7.2/lib/python2.7/unittest/__init__.py", line 64, in <module>
    from .main import TestProgram, main
  File "/Library/Frameworks/EPD64.framework/Versions/7.2/lib/python2.7/unittest/main.py", line 7, in <module>
    from . import loader, runner
  File "/Library/Frameworks/EPD64.framework/Versions/7.2/lib/python2.7/unittest/runner.py", line 4, in <module>
    import time
  File "/Users/rmandelb/git/GalSim/time.py", line 1, in <module>
  File "galsim/__init__.py", line 28, in <module>
    import pyfits
  File "/Library/Frameworks/EPD64.framework/Versions/7.2/lib/python2.7/site-packages/pyfits/__init__.py", line 12, in <module>
    import pyfits.core
  File "/Library/Frameworks/EPD64.framework/Versions/7.2/lib/python2.7/site-packages/pyfits/core.py", line 42, in <module>
    import pyfits.column
  File "/Library/Frameworks/EPD64.framework/Versions/7.2/lib/python2.7/site-packages/pyfits/column.py", line 7, in <module>
    from numpy import char as chararray
ImportError: cannot import name char

Also, in the interest of full disclosure: In a fit of laziness, I did not reinstall python (in other words, when I went to the new machine I took my old account on my old computer and this is the same old python from the old machine). I was hoping that that would be okay, but do you think I need a new install in order for all this stuff to work?

[rmandelb]

Oh wait, I just noticed the message from config.log suggests it was getting screwed up by some old module I had in the GalSim directory (which I had deleted, but the .pyc file was still sitting around). I'm not sure how / why that happened! But when I deleted that .pyc file, the error about numpy went away. Sorry for the false alarm.

[rmandelb]

... and now I'm really confused because it's not making me reinstall boost. I thought it had to be compiled with the same compiler as the GalSim C++ code? But GalSim compiled happily and I am able to import the module, run unit tests, etc.

There is a warning when compiling GalSim:

pysrc/Bounds.cpp:57:27: warning: multiple unsequenced modifications to 'self' [-Wunsequenced]
            .def(bp::self *= bp::other<T>())
                          ^
pysrc/Bounds.cpp:88:27: warning: multiple unsequenced modifications to 'self' [-Wunsequenced]
            .def(bp::self += bp::other< Position<T> >())
                          ^

[rmjarvis]

I think I fixed the warning for you. What it is warning about would normally be undefined behavior if self *= ... and self += ... were normal arithmetic operations rather than operator-overloaded boost python magic. But the workaround to avoid the warning was quite simple, so I just did it.

I did it on branch #493, but if it works for you, we can probably just merge it into both master and 1.0 without a PR.

[barnabytprowe]

I agree, I think this can be merged directly. (I fixed a very minor, mildly amusing typo above)

[rmandelb]

Thanks for the fix - that works for me, and I agree about merging directly.

I put something in the FAQ about this; please feel free to edit as needed.

[rmandelb]

I merged this branch into master, and cherry-picked the two commits into releases/v1.0. Closing #493.