This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author ned.deily
Recipients ajstewart, ned.deily
Date 2017-03-18.17:25:52
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1489857952.22.0.933224564605.issue29846@psf.upfronthosting.co.za>
In-reply-to
Content
I'm not familiar with Spack and I'm certainly not going to try to deeply analyze a build that inserts *that* many separate -I and -L options into the compiler calls :)  But there have been a number of reports of problems with this symptom in the past (try searching the web) and at least one previous issue opened here (Issue26498).  The root cause in all of these is that at some point there is a mismatch between a python executable of one 2.7.x version being dynamically linked at run time with python shared libraries of a different 2.7.x version.  While a python build should guard against this happening, often it doesn't matter when such a mismatch occurs.  However, there was an incompatibility introduced in the lifetime of 2.7.x involving __PyCodecInfo_GetIncrementalDecoder (I forget the details).  My guess is that you will find that the problem goes away if you avoid the use of '--enable-shared' on the Python configure; most Python distributions on macOS use --enable-framework rather than --enable-shared and we seldom test it.  Or use neither.  You should also check that there are no third-party Python 2.7's on PATH and/or Python 2.7 shared libraries on the dyld library search paths, other than the Apple-supplied pythons in /usr/bin.  It would be nice to finally figure out and resolve where the hole is but I've never been able to reproduce the failure myself.
History
Date User Action Args
2017-03-18 17:25:52ned.deilysetrecipients: + ned.deily, ajstewart
2017-03-18 17:25:52ned.deilysetmessageid: <1489857952.22.0.933224564605.issue29846@psf.upfronthosting.co.za>
2017-03-18 17:25:52ned.deilylinkissue29846 messages
2017-03-18 17:25:52ned.deilycreate