Re: [Visualpython-users] Mac installation question.

[Bruce S. <bas...@nc...>]

Further comment: I've been careful to use the 10.4 c++ compiler on the
Mac, and in PackageMaker to specify OSX >= 10.4. Alas, it must be that
the latest numpy installer isn't built that way, and I didn't think of
that potential problem. I'm going to change the note on vpython.org to
say "10.5 or 10.6", and suggest people use an older version if they're
running 10.4.

I can't help observing that Python and Visual work fine across a very
long time period of Windows versions, from XP, or even before, through
Windows 7. But there are all sorts of little glitches in Mac OSX
releases that make it necessary to pay close attention to the specific
release.

Also, for everyone's information, there still isn't a numpy installer
for Python 3.1 on the Mac, and I was unable to build numpy from source
(I found some notes on the web about others having this problem, too).

Bruce

On Thu, Sep 9, 2010 at 10:02 AM, Bruce Sherwood <bas...@nc...> wrote:
> Sigh. I innocently simply used the numpy Mac installer. Is the short
> statement that at least for now the vpython.org Mac download page
> should say that the VPython installer is for 10.5 and higher?
>
> Bruce
>
> On Thu, Sep 9, 2010 at 6:25 AM, Martin Costabel <cos...@wa...> wrote:
>> 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
>>
>>
>>
>