cmake find_package(PythonLibs) broken with brewed python on 10.9

[NikolausDemmel]

Hi,

this is possibly an upstream cmake issue, but in affects in particular users of a brewed python.

I'm on Mavericks and have brewed python 2.7.6 and brewed cmake 2.8.12.1 installed. brew doctor shows no errors. (https://gist.github.com/NikolausDemmel/7893695)

While find_package(PythonInterp) does find the correct binary (e.g. brewed for 2.7, system for version 2.6 and 2.5), find_package(PythonLibs) always finds librarie and include paths related to the system 2.7 python (even when requesting version 2.6 or 2.5). Needless to say that this causes great grief and segmentation faults when the linked libs don't match the executing interpreter. (In my case it breaks a bunch of python libs in ROS http://wiki.ros.org/hydro/Installation/OSX/Homebrew/Source). The only configuration where this would be correct is when using the system python 2.7 (which incidentally might also be the most used configuration, maybe?).

I believe this is an issue of the cmake modules FindPythonLibs.cmake, but possibly also CMakeFindFrameworks.cmake and the way that the brewed python installs itsself (the list of locations that CMakeFindFrameworks.cmake searches does not include /usr/local/Frameworks, which is where the brewed python installs itself as a framework). The framework might be a lesser issue in my scenario at least, but it seems to invite trouble. I'm thus opening this issue here instead of upstream cmake.

The following test CMakeLists.txt and output shows the faulty behaviour illustrated above. Do other people see the same?

cmake_minimum_required(VERSION 2.8)

foreach(REQUIRED_PYTHON_VERSION 2.7 2.6 2.5)
  message(STATUS "======== LOOKING FOR ${REQUIRED_PYTHON_VERSION} ========================")
  find_package ( PythonInterp ${REQUIRED_PYTHON_VERSION} REQUIRED)
  find_package ( PythonLibs ${PYTHON_VERSION_STRING} EXACT)
  #find_package ( PythonLibs ${PYTHON_VERSION_STRING} EXACT REQUIRED )


  message(STATUS "PYTHON_EXECUTABLE:FILEPATH=${PYTHON_EXECUTABLE}")
  message(STATUS "PYTHON_LIBRARY:FILEPATH=${PYTHON_LIBRARY}")
  message(STATUS "PYTHON_INCLUDE_DIR:FILEPATH=${PYTHON_INCLUDE_DIR}")
  message(STATUS "PYTHON_FRAMEWORK_INCLUDES=${PYTHON_FRAMEWORK_INCLUDES}")
  message(STATUS "PYTHONLIBS_VERSION_STRING=${PYTHONLIBS_VERSION_STRING}")
  message(STATUS "Python_FRAMEWORKS=${Python_FRAMEWORKS}")

  unset(PYTHON_EXECUTABLE CACHE)
  unset(PYTHON_LIBRARY CACHE)
  unset(PYTHON_INCLUDE_DIR CACHE)
endforeach()

This is the output of mkdir build && cmake ..:

-- The C compiler identification is Clang 5.0.0
-- The CXX compiler identification is Clang 5.0.0
-- Check for working C compiler: /usr/bin/cc
-- Check for working C compiler: /usr/bin/cc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working CXX compiler: /usr/bin/c++
-- Check for working CXX compiler: /usr/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- ======== LOOKING FOR 2.7 ========================
-- Found PythonInterp: /usr/local/bin/python2.7 (found suitable version "2.7.6", minimum required is "2.7")
-- Could NOT find PythonLibs: Found unsuitable version "2.7.5", but required is exact version "2.7.6" (found /usr/lib/libpython2.7.dylib)
-- PYTHON_VERSION_STRING=2.7.6
-- PYTHON_EXECUTABLE:FILEPATH=/usr/local/bin/python2.7
-- PYTHONLIBS_VERSION_STRING=2.7.5
-- PYTHON_LIBRARY:FILEPATH=/usr/lib/libpython2.7.dylib
-- PYTHON_INCLUDE_DIR:FILEPATH=/System/Library/Frameworks/Python.framework/Headers
-- PYTHON_FRAMEWORK_INCLUDES=
-- Python_FRAMEWORKS=/System/Library/Frameworks/Python.framework
-- ======== LOOKING FOR 2.6 ========================
-- Found PythonInterp: /usr/bin/python2.6 (found suitable version "2.6.8", minimum required is "2.6")
-- Could NOT find PythonLibs: Found unsuitable version "2.7.5", but required is exact version "2.6.8" (found /usr/lib/libpython2.7.dylib)
-- PYTHON_VERSION_STRING=2.6.8
-- PYTHON_EXECUTABLE:FILEPATH=/usr/bin/python2.6
-- PYTHONLIBS_VERSION_STRING=2.7.5
-- PYTHON_LIBRARY:FILEPATH=/usr/lib/libpython2.7.dylib
-- PYTHON_INCLUDE_DIR:FILEPATH=/System/Library/Frameworks/Python.framework/Headers
-- PYTHON_FRAMEWORK_INCLUDES=
-- Python_FRAMEWORKS=/System/Library/Frameworks/Python.framework
-- ======== LOOKING FOR 2.5 ========================
-- Found PythonInterp: /usr/bin/python2.5 (found suitable version "2.5.6", minimum required is "2.5")
-- Could NOT find PythonLibs: Found unsuitable version "2.7.5", but required is exact version "2.5.6" (found /usr/lib/libpython2.7.dylib)
-- PYTHON_VERSION_STRING=2.5.6
-- PYTHON_EXECUTABLE:FILEPATH=/usr/bin/python2.5
-- PYTHONLIBS_VERSION_STRING=2.7.5
-- PYTHON_LIBRARY:FILEPATH=/usr/lib/libpython2.7.dylib
-- PYTHON_INCLUDE_DIR:FILEPATH=/System/Library/Frameworks/Python.framework/Headers
-- PYTHON_FRAMEWORK_INCLUDES=
-- Python_FRAMEWORKS=/System/Library/Frameworks/Python.framework
-- Configuring done
-- Generating done
-- Build files have been written to: /Users/demmeln/work/cmake_test/build

Possibly related, 2-year-old and never resolved issue is #10393.

[mistydemeo]

I see it found /usr/lib/libpython2.7.dylib - is there a system Python lib there? For some reason I thought they only lived in the Python.framework.

What are the dependencies of your formula? I notice it's not picking up the Homebrewed Python framework, even though it should be in the search path.

[NikolausDemmel]

Yes unfortunately:

$ ls -la /usr/lib/libpython2.7.dylib
lrwxr-xr-x  1 root  wheel  68 31 Okt 07:50 /usr/lib/libpython2.7.dylib -> ../../System/Library/Frameworks/Python.framework/Versions/2.7/Python

I'm not developing a formula. I am building a CMake project using find_package(PythonLibs). It's building, but brewed python is not happy when /usr/lib/libpython2.7.dylib is importet (segfault 11).

PYTHON_FRAMEWORK_INCLUDES is set inside FindPythonLibs.cmake, but only under certain conditions. I don't actually use it directly. I'm unsure if this is related to the wrong lib and include paths, or if it is a seperate issue.

Python_FRAMEWORKS is set inside CMakeFindFrameworks.cmake, but it only searches a hardcoded list of locations and as mentioned, /usr/local/Frameworks is not included.

[mistydemeo]

I'm not very familiar with cmake, but is it possible to override Python_FRAMEWORKS? What happens if you pass -DPython_FRAMEWORKS=/usr/local/Frameworks to cmake?

[NikolausDemmel]

That doesn't change anything. Looking inside FindPythonLibs.cmake I don't think its meant to be used that way. I actually think that FindPythonLibs.cmake determines the lib and include paths for python idependent of the frameworks (variables Python_FRAMEWORKS and PYTHON_FRAMEWORK_INCLUDES). I'm not sure though.

[dakcarto]

@NikolausDemmel We ran into the same issue with the CMake build for QGIS. While an upstream fix is ideal, as a workaround I added a CMake option PYTHON_CUSTOM_FRAMEWORK specifically to support Homebrew'd Python setups.

QGIS FindPythonLibrary.cmake module and how I use it in a formula.

If you use that module and find any issues with or fixes for it, please post to the QGIS issue tracker.

[NikolausDemmel]

@dakcarto Thanks for that info and the linked cmake file. I agree that using the found python interpreter from find_package(PythonInterp) and then using distutils.sysconfig.get_python_inc() seems like the right thing. Why do you link with -framework Python instead of using the lib path in distutils.sysconfig.get_python_lib()? On my system at least the -framework Python goes back to using the system python library (version 2.7). I'm not sure if it would link correctly with older python versions (e.g. if python2.6 is desired). It's clear why this doesn't work, as I have not done anything to tell clang about the Homebrew python framework. I would like to make the cmake module work without any custom variables like PYTHON_CUSTOM_FRAMEWORK (in particular because I want it to work for cmake projects that I can not easily change myself). I'm not sure what the advantages of using -framework Python over directly linking to the dylib are?

Edit:
If the -framework Python links correct versions (i.e. if python2.5 or 2.6 is selected), maybe it would be appropriate push for an upstream change of cmake FindPythonLibs.cmake to behave along the lines of your solution in QGIS and then make sure that users of brewed python alter their environment in such a way that the brewed python framework is found first.

[NikolausDemmel]

Should we raise this upsteam with CMake to see how we can change the broken FindPythonLibs.cmake?

[MikeMcQuaid]

Yes.

[iMichka]

Has a ticket been opened on the cmake bug tracker for this ?

[NikolausDemmel]

@iMichka: No, it hasn't. After researching a bunch of existing mailinglist discussions and bug tracker issues about related problems and digging into the code it is not clear to me what the solution should be. I did a local hack along the lines of what @dakcarto suggested and then dropped the ball on the issue, sorry.

I should try to at least dig up the list of links to existing issues and list discussions...

[iMichka]

If not, you should open a ticket on cmake's bug tracker so that they know about the issue. Perhaps upstream will fix it (I know there can be some delay for this, they still have a lot of bugs open)

[MikeMcQuaid]

This stuff won't be fixed if it's not raised upstream.

[GitSullied]

I am experiencing a similar issue, but building a different package (libfreenect) that I want to link against the brewed Python I just installed.

I was surprised to see the suggestion that this was an upstream problem. It very well may be, but before I read through this thread I was trying to determine if the formula for brewed python was intentionally not linking the libpython.dylib and header directory or if that was a mistake. My very first expectation was that I would find the symbolic links:

• /usr/local/lib/libpython2.7.dylib -> /usr/local/Cellar/python/2.7.6/Frameworks/Python.framework/Versions/2.7/Python
• /usr/local/lib/libpython.dylib -> /usr/local/lib/libpython2.7.dylib
• /usr/local/include/python2.7 -> usr/local/Cellar/python/2.7.6/Frameworks/Python.framework/Versions/2.7/Headers

Other parts of the brewed Python seemed to have been linked, like the bin and share directories, but then I considered that maybe developers were meant to pass these libraries and include directories as parameters or possibly environment variables. I seem to remember the post install caveats for readline, gdbm, and/or sqlite mentioning this. Personally, I intended to always link against the brewed applications I have installed instead of the system provided versions. Maybe that is naive. I am new to the OSX platform, so maybe one of the more experienced Mac developers would like to chime in with the best practices they follow.

Thank you, @NikolausDemmel, for posting the simple CMakeLists.txt example. It was instructive as I worked through my issue. I wanted to ask, or maybe point out, a few things that came up for me.

• Did you intentionally use find_package instead of find_library?
• Are you aware of the FindPythonInterp and FindPythonLibs modules provided by cmake?

I wasn't and having your example, as well as, the reference by @dakcarto helped me out; so thank you again. I added the lines:

include(FindPythonInterp)
include(FindPythonLibs)

to the CMakeLists.txt example above (placing them immediately before the foreach-loop iterates over versions) and experimented with various options. I looked at the disutils technique suggested too. I haven't gotten to the bottom of all the issues, but it was enough to convince me that passing cmake some parameters was going to be the easiest way to achieve my goal.

$ mkdir build
$ cd build
$ cmake -DPYTHON_INCLUDE_DIR=/path/to/brewed/python/Headers -DPYTHON_LIBRARY=/path/to/brewed/libpython.dylib -DPython_FRAMEWORKS=/path/to/brewed/python/Framework/Python.framework ..

which generated

-- The C compiler identification is Clang 5.0.0
-- The CXX compiler identification is Clang 5.0.0
-- Check for working C compiler: /usr/bin/cc
-- Check for working C compiler: /usr/bin/cc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working CXX compiler: /usr/bin/c++
-- Check for working CXX compiler: /usr/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Found PythonInterp: /usr/local/bin/python (found version "2.7.6") 
-- Found PythonLibs: /usr/local/lib/libpython.dylib (found version "2.7.6") 
-- ======== LOOKING FOR 2.7 ========================
-- Found PythonInterp: /usr/local/bin/python (found suitable version "2.7.6", minimum required is "2.7") 
-- Found PythonLibs: /usr/local/lib/libpython.dylib (found suitable exact version "2.7.6") 
-- PYTHON_EXECUTABLE:FILEPATH=/usr/local/bin/python
-- PYTHON_LIBRARY:FILEPATH=/usr/local/lib/libpython.dylib
-- PYTHON_INCLUDE_DIR:FILEPATH=/usr/local/include/python2.7
-- PYTHON_FRAMEWORK_INCLUDES=
-- PYTHONLIBS_VERSION_STRING=2.7.6
-- Python_FRAMEWORKS=/usr/local/Cellar/2.7.6/Frameworks/Python.framework;/System/Library/Frameworks/Python.framework

... output cut because I"m only interested in the brewed 2.7 python ...

-- Configuring done
-- Generating done
-- Build files have been written to: /Users/sully/Development/worksp

I am going down this path. Hopefully, this helps you too.

distutils

At a glance it seemed that the python environment path (sys.path) might be problematic for the suggested approach (using distutils to determine the proper location of the library files).

cmake options

There were a few options that the find_package and find_library functions took that might have helped sort out which library (system vs. brewed) should be preferred, but I did not try them out.

brew --linkapps

I didn't look into this option either; not really sure if it would have worked because I have never even done it. Maybe one of the Homebrew gurus can chime in here. Would it be possible, or advisable, to try and overshadow the system packages by overtaking them in their own directory space? I think I read or heard that Homebrew is strict about not going outside of the prefix directory it is configured to use- I think that is a good philosophy, so I never tried this feature.

[naegelejd]

To clarify, aren't there really two CMake issues here?

1. CmakeFindFrameworks.cmake loops over a list of hard-coded paths, which doesn't
   include /usr/local. Ideally, it would also read from a CMake variable
   (e.g. CMAKE_FRAMEWORK_PATH, similar to CMAKE_MODULE_PATH)
2. There is no convenient way to feed information about your Python headers/libs to
   FindPythonLibs.cmake. Ideally, one could set $PYTHONHOME, which is used
   by Python (http://docs.python.org/2/using/cmdline.html#environment-variables)
   for finding headers/libs (or PYTHON_ROOT like in FindBoost.cmake, FindHDF5.cmake, etc.).

[NikolausDemmel]

@naegelejd:

1. Yes, thanks for pointing that out. This is one separate issue that should be addressed. The second issue depends on it to some degree.

2. I am not sure what the expeceted behaviour really should be. What you say might be reasonable. I would have also expected the version of python that FindPythonInterp and FindPythonLibs find to be the same, but I'm not sure if this is reasonable in any circumstance. Maybe if there is no customization of $PYTHONHOME or similar, and if FindPythonInterp does find an interpreter, then FindPythonLibs should make sure to return the flags for this version?

@GitSullied:

1. I do not understand your comment about find_package vs find_library. AFAIK find_package calls the latter internally. So I am using and talking about the modules FindPythonInterp and FindPythonLibs, no?

2. about distutils: What makes you say that this might not work?

3. about cmake options: I am in particular concerned about configuring the python version (brewed versus apple) globally. I am in a position where I build a ton of packages that others develop that use cmake to find python, so I cannot change the neither the invocation of cmake, nor the calls to find_packge. For FindPythonInterp this works nicely by making sure the desired python version comes first on $PATH.

4. brew --linkapps is intended for linking application bundles into /Applications, I think.

In general using the --framework Python compiler flag will not work together with selecting a specific python version (see: http://stackoverflow.com/questions/2414807/how-to-link-to-a-specific-framework-version-in-xcode), so in that case cmake should always return the flags directly to the full header directory and libraries. It might however be ok to use --framework Python if the user specifies no version in cmake, i.e. he wants the latest version. This again depends on fixing @naegelejd's first issue.

[daviewales]

This is a bug in cmake, or possibly OS X's Python configuration. If you brew remove python, it will only fix this for 2.7. It still fails for 2.6 and 2.5, because they both only see the libs for 2.7.5.

Essentially, cmake can only see libs for 2.7.5, no matter what.

[NikolausDemmel]

True. However 2.7 is a common case, in particular it is the case if no version is specified. It turns out the only case I encountered in practice in cmake projects is not specifying a version. That works with system python, but not with brewed.

It is actually more intrecate. I'm running some more tests right now. It turns out if we don't call the above test in a loop, but rather seperate invocations of cmake for each version, the result is slightly different. Then, it correctly finds /usr/lib/libpython2.6.dylib and /usr/lib/libpython2.5.dylib, however, the headers are still wrong. Not sure what state cmake is keeping here. Maybe something inside find_library.

I fully agree that the solution is a fix for CMake.

[NikolausDemmel]

@MikeMcQuaid , can you comment on the point brought up by @GitSullied above? Was it a delibertate choice to not include symlinks /usr/local/lib/libpython2.7.dylib, /usr/local/lib/libpython.dylib and /usr/local/include/python2.7 in the python formula given that Apple provides /usr/include/python2.7, /usr/lib/libpython.dylib and /usr/lib/libpython2.7.dylib?

[MikeMcQuaid]

It's a deliberate choice by Python upstream. I don't like us hacking around what upstream is doing because other packages are broken.

[NikolausDemmel]

Finally got round to reporting this upstream: http://www.itk.org/Bug/view.php?id=14809, http://www.itk.org/Bug/view.php?id=14810

[mkoval]

I am running into the same issue building KDL in OS X 10.9. CMake detects a Python 2.7.6. interpreter, but finds the system Python 2.7.5 library. Has anyone found a temporary workaround while waiting for an upstream fix?

[santekotturi]

I too am trying to build ROS by running ./src/catkin/bin/catkin_make_isolated --install -DCMAKE_BUILD_TYPE=Release and am getting:
CMake Error at /usr/local/Cellar/cmake/2.8.12.2/share/cmake/Modules/FindPackageHandleStandardArgs.cmake:108 (message): Could NOT find PythonLibs: Found unsuitable version "2.7.5", but required is at least "2.7.6" (found /usr/lib/libpython2.7.dylib)

my brew is updated, doctored and ready to brew.

[iMichka]

Look how we do it in the VTK formula: https://github.com/Homebrew/homebrew-science/blob/master/vtk.rb
You have to pass manually the path to the dylib.

"-DPYTHON_LIBRARY='#{%x(python-config --prefix).chomp}/lib/libpython2.7.dylib'"

[NikolausDemmel]

@skotturi : You can try brew uninstall cmake and brew install nikolausdemmel/devel/cmake. It is far from perfect or even remotely covering all cases, let alone tested. However, it allows me to build and use ROS with brewed python (Hyrdo on Mavericks).

[NikolausDemmel]

I rewrote the module to be compliant with the find module's interface (input/output variables) and it should do the right thing in more cases. It's not thoroughly tested, but you can check it out here: NikolausDemmel/CMake#2 and/or install via brew install nikolausdemmel/devel/cmake.

[mkoval]

Thanks @NikolausDemmel for the help. Unfortunately, brew install nikolausdemmel/devel/cmake fails with a hash mismatch:

$ brew install nikolausdemmel/devel/cmake
==> Downloading http://www.cmake.org/files/v2.8/cmake-2.8.12.2.tar.gz
Already downloaded: /Library/Caches/Homebrew/cmake-2.8.12.2.tar.gz
==> Downloading https://github.com/NikolausDemmel/CMake/pull/2.patch
Already downloaded: /Library/Caches/Homebrew/cmake--patch-1e7ae84d7c6bb2e884d8a1e8ffe69c61146ee503.patch
Error: SHA1 mismatch
Expected: 1e7ae84d7c6bb2e884d8a1e8ffe69c61146ee503
Actual: 0e21491d5846ddb9b177403eae495bb2105b046e
Archive: /Library/Caches/Homebrew/cmake--patch-1e7ae84d7c6bb2e884d8a1e8ffe69c61146ee503.patch
To retry an incomplete download, remove the file above.

I poked around in brew edit nikolausdemmel/devel/cmake and couldn't find the offending hash anywhere in that file. This is probably just my lack of Homebrew knowledge failing me: What does the foo/bar/cmake syntax mean? Does brew edit support editing these recipes?

[NikolausDemmel]

Ah dang it. I got skrewed by homebrew download caching when testing this. There might be other issues since I apparently didnt test it properly. I will fix it when I get home.

The "foo/bar/formulaname" syntax is for Taps. Look up brew tap in the man page or docs. It means you are installing cmake from github.com/NikolausDemmel/homebrew-devel

[NikolausDemmel]

You should find the file with that expected sha1 in /usr/local/Library/Taps/nikolausdemmel/homebrew-devel/cmake.rb.

[santekotturi]

@NikolausDemmel I could successfully install your new cmake after brew uninstall cmake:
ros_catkin_ws $brew install nikolausdemmel/devel/cmake Cloning into '/usr/local/Library/Taps/nikolausdemmel/homebrew-devel'... ... ==> Downloading http://www.cmake.org/files/v2.8/cmake-2.8.12.2.tar.gz ######################################################################## 100.0% ==> Downloading https://github.com/NikolausDemmel/CMake/pull/2.patch ######################################################################## 100.0% ==> Patching patching file Modules/FindLibPython.py patching file Modules/FindPythonLibs.cmake ==> ./bootstrap --prefix=/usr/local/Cellar/cmake/2.8.12.2 --system-libs --no-system-libarchive --datadir=/share/cmake --docdir=/share/doc/cmake - ==> make ==> make install 🍺 /usr/local/Cellar/cmake/2.8.12.2: 702 files, 34M, built in 4.2 minutes

I then tried to build ROS catkin workspace again and got the same error, here's the gist:
https://gist.github.com/skotturi/c8f0a6ab5ee2e1c1e8bf
see line 2094 for the error.
I noticed some new output between 1369 and 1865 that might be informative

[mkoval]

It looks like @NikolausDemmel's CMake tap is working now. Thanks a lot for the help!

I now get past the configure step, but compiling KDL fails due to a massive number of errors (see this Gist: https://gist.github.com/mkoval/66b6af8f064ea2b5bc39). These appear to be legitimate C++ errors, so I'm not sure exactly whats going on.

[EDIT] This is a known issue with building KDL in clang. See this answer on ROS answers for a workaround.

I think the problem @skotturi is having is caused by:

Warning: Could not tap nikolausdemmel/homebrew-devel/cmake

You probably have the default cmake tapped. You should manually remove cmake, then tap the patched version:

brew remove cmake; brew install nikolausdemmel/homebrew-devel/cmake

[NikolausDemmel]

@mkoval: Good to know you got past the python issues (for now). Let's not highjack this homebrew issue for ROS problems. But to get started, check out http://answers.ros.org/question/94771/building-ros-on-osx-109-solution/?answer=101176#post-id-101176. Feeld free to post any remaining issues on answers.ros.org (and maybe link them from here).

@skotturi: The warning is fine and it looks like it did install the fromula from my Tap. Please edit your comment and move all the output to pastebin.com or gist.github.com, this thread is long enough as it is. And then indicate the lines that you think are informative. Just to make sure, please remove the build_isolated directory after installing the patched cmake version.

[santekotturi]

I ran brew remove cmake and brew cleanup. However brew prune still yields:
Warning: Could not tap nikolausdemmel/homebrew-devel/cmake over Homebrew/homebrew/cmake

But it works! I'm now getting this error when trying to process rospack:
fatal error: 'tinyxml.h' file not found
But I'll figure that out.
Thanks for the help @NikolausDemmel & @mkoval (and for reminding me to remove build_isolated)

[beefon]

This is also an issue for 10.10 beta 1.

[dbrnz]

cmake's FindPythonLibs appears to correctly find a brewed Python if ~/Library/Frameworks contains a symbolic link to the homebrew Python framework.

ln -s /usr/local/Cellar/python/2.7.6_1/Frameworks/Python.framework ~/Library/Frameworks/Python.framework

Should homebrew maintain this link?

[MikeMcQuaid]

@dbrnz Homebrew doesn't modify files in the user's home directory.

[NikolausDemmel]

@dbrnz: Moreover, creating such a link is a workaround only for the current python version (2.7.). The module will still break if you look for other versions.

[luzzbob]

thks @mistydemeo

[MikeMcQuaid]

It seems we're agreed that this is an upstream issue so I'm closing this out.

[MartinHjelm]

I had some problems with the Shogun toolbox giving me segmentation fault when using import. Adding

-DPYTHON_LIBRARY=#{%x(python-config --prefix).chomp}/lib/libpython2.7.dylib

seems to fix this. Thankx!

[shrx]

@dbrnz's solution worked for me.