On 8 Aug, 2010, at 6:15, Greg Ewing wrote: > Aaargh, I think I've found out what the problem is. > > I'm using framework builds on MacOSX. I have two experimental > builds of Python 3.1 around, plus a standard one installed in > /Library. It's picking up the version of Python.framework in > /Library/Frameworks instead of the one in the local build > directory that python.exe was explicitly linked with. Check the RUNPY definition in the Makefile, you should start python.exe using DYLD_FRAMEWORK_PATH=$PWD ./python.exe (Assuming your running from the build directory, adjusting this for other situations should be easy) > > Now I'm confused about why my *other* experimental build > worked -- the one I've been using for yield-from and codef -- > because it should have suffered from the same problem. And > when I tried to use it again just now, it did indeed not work. > > Does anyone know if there's a way to tell Apple's linker to > use a framework from a specific location and not go looking > anywhere else? Use the '--with-framework-name' option to configure, this enables you to build the framework with an alternate name and therefore have two framework installs side-by-side. I use this to have a regular python build as well as a --with-pydebug build. Ronald -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3567 bytes Desc: not available URL: <http://mail.python.org/pipermail/python-dev/attachments/20100810/7ebe643d/attachment.bin>
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4