Message88839
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. |
|
Date |
User |
Action |
Args |
2009-06-03 22:45:19 | ronaldoussoren | set | recipients:
+ ronaldoussoren, brett.cannon, mark.dickinson, benjamin.peterson, erickt, tarek, brodie, rpetrov, ebehar |
2009-06-03 22:45:19 | ronaldoussoren | set | messageid: <1244069119.76.0.418156952379.issue6154@psf.upfronthosting.co.za> |
2009-06-03 22:45:18 | ronaldoussoren | link | issue6154 messages |
2009-06-03 22:45:17 | ronaldoussoren | create | |
|