Ronald Oussoren <ronaldousso...@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 <rep...@bugs.python.org>
<http://bugs.python.org/issue6154>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
