[issue6154] Python 3.1 rc1 will not build on OS X 10.5.7 with macports libintl

Ronald Oussoren report at bugs.python.org
Thu Jun 4 00:45:19 CEST 2009


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

Do you have a copy of libintl in /usr/local or ~brett//local/lib? If so, 
could you run 'file' on that library to check if it is a universal 
library?

All system libraries on OSX are universal binaries and work just fine 
with a universal build of Python, that's why I believe you have a non-
universal copy of some libraries on your systems and those won't work 
when you try to do a universal build.

Removing -lintl for a universal build would not be a valid solution, 
unless -lintl is completely unnecessary on OSX.

And for the record: I cannot reproduce this on my system, the end of 
build with --enable-universalsdk:

Python build finished, but the necessary bits to build these modules 
were not found:
_gdbm              ossaudiodev        readline        
spwd                                                  
To find the necessary bits, look in setup.py in detect_modules() for the 
module's name.


Failed to build these modules:
_gestalt           _tkinter                           


And the output of file:

file python.exe
python.exe: Mach-O universal binary with 2 architectures
python.exe (for architecture ppc):	Mach-O executable ppc
python.exe (for architecture i386):	Mach-O executable i386

Al of this is with a fresh checkout (r73188) of the py3k branch.


P.S. I'd love to know a clean way to exclude /usr/local/{include,lib} 
from the search paths of GCC, I've had a number of bugreports for other 
projects where the compiler picked up a non-universal library in 
/usr/local that the user didn't even know they had installed and didn't 
want to use.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6154>
_______________________________________


More information about the Python-bugs-list mailing list