Re: [Visualpython-users] Mac installation question.

[Martin C. <cos...@wa...>]

On 9/09/10 10:55, Steve Spicklemire wrote:
>
> Possible clue...  on my PPC running Leopard (10.5.8) I see:
>
> $ otool -vT /usr/lib/libSystem.B.dylib | grep memcpy
> single module    ___memcpy_chk
> single module    _memcpy
> single module    _wmemcpy
>
> on my intel, running Snow Leopard
>
> $ otool -vT /usr/lib/libSystem.B.dylib
> /usr/lib/libSystem.B.dylib:
> Table of contents (0 entries)
> module name      symbol name

It seems that otool -T behaves in an "unexpected" way on Snow Leopard 
(AKA "doesn't work"). If you use nm instead, it shows you the same thing 
for ___memcpy as on Leopard.

> So... that's interesting. Having said that I installed v5.32/py2.7 and it works correctly on my Snow Leopard intel system... so the numpy that's installed with visual doesn't seem to link to the missing symbol.

It does link:

costabel% nm -m multiarray.so | grep memcpy_chk
       (undefined [lazy bound]) external ___memcpy_chk (from libSystem)

This is on Snow Leopard. If I try the same command with the same file on 
Leopard, I get

nm: for architecture i386 object: core/multiarray.so malformed object 
(unknown load command 4).

Load command 4 is LC_DYLD_INFO_ONLY, which was introduced with MacOSX 
10.6. This means that this binary doesn't even work correctly on MacOSX 
10.5, although it is rather "fat":

% file  core/multiarray.so
core/multiarray.so: Mach-O universal binary with 3 architectures
core/multiarray.so (for architecture i386):	Mach-O bundle i386
core/multiarray.so (for architecture ppc7400):	Mach-O bundle ppc
core/multiarray.so (for architecture x86_64):	Mach-O 64-bit bundle x86_64

Whoever built this version of numpy might want to rebuild it with the 
10.4 SDK.

-- 
Martin