Christopher Barker wrote:
> import PIL._imagingft
>> Traceback (most recent call last):
>> File "", line 1, in
>> ImportError: dlopen(PIL/_imagingft.so, 2): Symbol not found:
>> _FSOpenResFile
>> Referenced from: PIL/_imagingft.so
>> Expected in: dynamic lookup
>>
>> This error does not occur if _imagingtk is imported first. So it looks
>> like we would have to link against some system library when building
>> _imagingft.
>
> could be -- I'm clueless on that one, but if I try in it:
>
import PIL._imagingft
> Traceback (most recent call last):
> File "", line 1, in
> ImportError:
> dlopen(/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/PIL/_imagingft.so,
> 2): Symbol not found: _inflateEnd
> Referenced from:
> /Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/PIL/_imagingft.so
>
> Expected in: dynamic lookup
>
> What I don't know is if we should expect -imagingft to b importable all
> by itself, first. Though I wouldn't think it should depend on TK.
>
> If I do:
>
import PIL._imaging
import PIL._imagingft
The second import still fails for me. But in your case, it was the
symbol _inflateEnd that was missing which is from zlib. _imaging also
depends on zlib, so that explains why importing _imaging first fixes the
second import for you. Apparently, your version of libfreetype doesn't
have the same dependencies as my version. Here, the dependencies are as
follows:
$ otool -L /opt/local/lib/libfreetype.6.dylib
/opt/local/lib/libfreetype.6.dylib:
/opt/local/lib/libfreetype.6.dylib (compatibility version 10.0.0,
current version 10.20.0)
/System/Library/Frameworks/CoreServices.framework/Versions/A/CoreServices
(compatibility version 1.0.0, current version 18.0.0)
/System/Library/Frameworks/ApplicationServices.framework/Versions/A/ApplicationServices
(compatibility version 1.0.0, current version 22.0.0)
/usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version
1.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current
version 88.3.9)
So in the setup script around line 320 where the _imagingft extension
module is defined, I added the following linker args:
extra_link_args=["-framework", "CoreServices", "-framework",
"ApplicationServices"]
After that I can actually import _imagingft just on its own and your
test script then also works (after changing the font as the one in the
script doesn't exist on my system). Without the above modification, your
script would still fail unless I import _imagingtk first.
So all the dependencies of the PIL modules are now like this:
$ otool -L PIL/*.so
PIL/_imaging.so:
/usr/lib/libz.1.dylib (compatibility version 1.0.0, current
version 1.2.3)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current
version 88.3.9)
PIL/_imagingcms.so:
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current
version 88.3.9)
PIL/_imagingft.so:
/System/Library/Frameworks/CoreServices.framework/Versions/A/CoreServices
(compatibility version 1.0.0, current version 18.0.0)
/System/Library/Frameworks/ApplicationServices.framework/Versions/A/ApplicationServices
(compatibility version 1.0.0, current version 22.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current
version 88.3.9)
PIL/_imagingmath.so:
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current
version 88.3.9)
PIL/_imagingtk.so:
/System/Library/Frameworks/Tcl.framework/Versions/8.4/Tcl
(compatibility version 8.4.0, current version 8.4.0)
/System/Library/Frameworks/Tk.framework/Versions/8.4/Tk
(compatibility version 8.4.0, current version 8.4.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current
version 88.3.9)
So do all Python modules compiled on OSX 10.4 automatically work on
newer versions of OSX? Do you want me to send the packages to you for
testing? By the way, what's generally the preferred distribution format,
zip or dmg?
- Matthias -
___
Pythonmac-SIG maillist - Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig
unsubscribe: http://mail.python.org/mailman/options/Pythonmac-SIG
