mididings links to wrong libboost_python version when shell has non-english locale
Closed this issue · 2 comments
When running python setup.py install with a Python version >= 3 and the shell locale is set to something causing gcc to output non-english messages, the lib_dirs function in setup.py fails to return the proper list of library directories, because it can not parse the gcc output. The result is that libboost_python3.so is not found in the usual library dirs (i.e. /usr/lib) and setup assumes the Boost library name to be libboost_python.so. On my system (Arch-based) this version of libboost_python links to the Python 2 library. As a result, mididings will be linked to the wrong library and an import will fail with an ImportError or even a segmentation fault
This can be fixed by prepending LC_ALL=C to the gcc command run via getstatusoutput. I'm not sure whether this is a Bash-ism, but it should work on OS X as well. Another solution would be to use subprocess.check_output([cc, '-print-search-dirs'], env={}), which also eliminates the use of a subshell, but it need Python >= 2.7.
Also, lib_dirs should normalize the library directories to make the compiler putput much nicer to read.
See pull request #6.
Ouch. Who thought it would be a good idea to localize the output of "gcc -print-search-dirs"?
Prepending LC_ALL=C fails with (t)csh, but works in every other shell I could try. That's probably good enough for now, and preferable to dropping support for Python 2.6.