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 ajstewart
Recipients ajstewart, ned.deily
Date 2017-03-18.20:12:08
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1489867928.53.0.623510111226.issue29846@psf.upfronthosting.co.za>
In-reply-to
Content
> 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

I believe those were necessary to get the build working. Spack doesn't install anything into /usr/, and without those flags, Python doesn't know where to search for its dependencies. I tried removing them anyway but it didn't help.

> My guess is that you will find that the problem goes away if you avoid the use of '--enable-shared' on the Python configure

Just tried this and it does indeed go away! I can try convincing the other developers that this is the best option.

> most Python distributions on macOS use --enable-framework rather than --enable-shared and we seldom test it.

I just tried using using `--enable-framework` and `make install` failed. Seeing lots of `ImportError: No module named site` errors.

> 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.

This could very well be the cause of the problem. I happen to have both Python 2 and 3 installed with both Homebrew and Anaconda, and all 4 are in my PATH. I don't have any PYTHON or LD/DYLD related env vars though. If you think it's worth testing, I can try removing everything from my PATH except /usr/bin:/bin
History
Date User Action Args
2017-03-18 20:12:08ajstewartsetrecipients: + ajstewart, ned.deily
2017-03-18 20:12:08ajstewartsetmessageid: <1489867928.53.0.623510111226.issue29846@psf.upfronthosting.co.za>
2017-03-18 20:12:08ajstewartlinkissue29846 messages
2017-03-18 20:12:08ajstewartcreate