Menu
▾
▴
visualpython-users
|
From: Gary P. <gar...@gm...> - 2010-09-08 22:52:05
|
Our IT dept. just installed vpython on the 'clean' Macs in our lab. AFAIK, they followed the instructions on vpython.org. Unfortunately, python can't find packages. numpy and visual are installed in the "Frameworks" site-packages directory, but they are not found on import. One problem is that PATH is not set properly. which python ==> /usr/bin/python But if I launch python using the entire path to the executable, then import numpy, I get the attached traceback. Anyone know what the missing link is? thanks, gary --------------------------------------------------------------------------------- >>> import numpy Traceback (most recent call last): File "<stdin>", line 1, in <module> File "/Library/Frameworks/Python. framework/Versions/2.7/lib/python2.7/site-packages/numpy/__init__.py", line 136, in <module> import add_newdocs File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/numpy/add_newdocs.py", line 9, in <module> from numpy.lib import add_newdoc File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/numpy/lib/__init__.py", line 4, in <module> from type_check import * File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/numpy/lib/type_check.py", line 8, in <module> import numpy.core.numeric as _nx File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/numpy/core/__init__.py", line 5, in <module> import multiarray ImportError: dlopen(/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/numpy/core/multiarray.so, 2): Symbol not found: ___memcpy_chk Referenced from: /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/numpy/core/multiarray.so Expected in: /usr/lib/libSystem.B.dylib |
|
From: Bruce S. <bas...@nc...> - 2010-09-08 23:42:05
|
It's not a problem of not finding packages, since when you import numpy you find numpy. The problem is that numpy can't find a resource it needs. I don't know what could be set up oddly on these Macs, but the trace claims that ___memcpy_chk should be found in /usr/lib/libSystem.B.dylib. So the first thing to do is to verify that indeed this file is missing (or damaged?). Is it? Note that to see /usr/lib in the Finder you need to use the Finder menu Go > Go to Folder. Bruce Sherwood On Wed, Sep 8, 2010 at 4:51 PM, Gary Pajer <gar...@gm...> wrote: > Our IT dept. just installed vpython on the 'clean' Macs in our lab. AFAIK, > they followed the instructions on vpython.org. > > Unfortunately, python can't find packages. numpy and visual are installed > in the "Frameworks" site-packages directory, but they are not found on > import. > > One problem is that PATH is not set properly. which python ==> > /usr/bin/python > > But if I launch python using the entire path to the executable, then import > numpy, I get the attached traceback. > > Anyone know what the missing link is? > > thanks, > gary > > --------------------------------------------------------------------------------- > >>>> import numpy > Traceback (most recent call last): > File "<stdin>", line 1, in <module> > File "/Library/Frameworks/Python. > framework/Versions/2.7/lib/python2.7/site-packages/numpy/__init__.py", line > 136, in <module> > import add_newdocs > File > "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/numpy/add_newdocs.py", > line 9, in <module> > from numpy.lib import add_newdoc > File > "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/numpy/lib/__init__.py", > line 4, in <module> > from type_check import * > File > "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/numpy/lib/type_check.py", > line 8, in <module> > import numpy.core.numeric as _nx > File > "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/numpy/core/__init__.py", > line 5, in <module> > import multiarray > ImportError: > dlopen(/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/numpy/core/multiarray.so, > 2): Symbol not found: ___memcpy_chk > Referenced from: > /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/numpy/core/multiarray.so > Expected in: /usr/lib/libSystem.B.dylib > > > |
|
From: Martin C. <cos...@wa...> - 2010-09-09 08:10:42
|
On 9/09/10 01:41, Bruce Sherwood wrote: > > It's not a problem of not finding packages, since when you import > numpy you find numpy. The problem is that numpy can't find a resource > it needs. > > I don't know what could be set up oddly on these Macs, but the trace > claims that ___memcpy_chk should be found in > /usr/lib/libSystem.B.dylib. So the first thing to do is to verify that > indeed this file is missing (or damaged?). Is it? The symbol in question appeared in MacOSX 10.5. Gary's Macs are probably running the old MacOSX 10.4 while the installed numpy from the vpython package was compiled on MacOSX 10.5 or 10.6 (10.6, as far as I can tell). This won't work, although the vpython web page says it should. -- Martin |
|
From: Steve S. <st...@sp...> - 2010-09-09 09:15:54
|
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
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.
Gary... did anything else get installed besides visual/py2.7 ? Maybe a different version of numpy?
This might also be useful:
IntelMini:~ steve$ python -v -c 'import numpy' 2>&1 | grep multiarray
dlopen("/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/numpy/core/multiarray.so", 2);
import numpy.core.multiarray # dynamically loaded from /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/numpy/core/multiarray.so
# cleanup[2] numpy.core.multiarray
IntelMini:~ steve$
-steve
On Sep 8, 2010, at 7:41 PM, Bruce Sherwood wrote:
> It's not a problem of not finding packages, since when you import
> numpy you find numpy. The problem is that numpy can't find a resource
> it needs.
>
> I don't know what could be set up oddly on these Macs, but the trace
> claims that ___memcpy_chk should be found in
> /usr/lib/libSystem.B.dylib. So the first thing to do is to verify that
> indeed this file is missing (or damaged?). Is it?
>
> Note that to see /usr/lib in the Finder you need to use the Finder
> menu Go > Go to Folder.
>
> Bruce Sherwood
>
> On Wed, Sep 8, 2010 at 4:51 PM, Gary Pajer <gar...@gm...> wrote:
>> Our IT dept. just installed vpython on the 'clean' Macs in our lab. AFAIK,
>> they followed the instructions on vpython.org.
>>
>> Unfortunately, python can't find packages. numpy and visual are installed
>> in the "Frameworks" site-packages directory, but they are not found on
>> import.
>>
>> One problem is that PATH is not set properly. which python ==>
>> /usr/bin/python
>>
>> But if I launch python using the entire path to the executable, then import
>> numpy, I get the attached traceback.
>>
>> Anyone know what the missing link is?
>>
>> thanks,
>> gary
>>
>> ---------------------------------------------------------------------------------
>>
>>>>> import numpy
>> Traceback (most recent call last):
>> File "<stdin>", line 1, in <module>
>> File "/Library/Frameworks/Python.
>> framework/Versions/2.7/lib/python2.7/site-packages/numpy/__init__.py", line
>> 136, in <module>
>> import add_newdocs
>> File
>> "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/numpy/add_newdocs.py",
>> line 9, in <module>
>> from numpy.lib import add_newdoc
>> File
>> "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/numpy/lib/__init__.py",
>> line 4, in <module>
>> from type_check import *
>> File
>> "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/numpy/lib/type_check.py",
>> line 8, in <module>
>> import numpy.core.numeric as _nx
>> File
>> "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/numpy/core/__init__.py",
>> line 5, in <module>
>> import multiarray
>> ImportError:
>> dlopen(/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/numpy/core/multiarray.so,
>> 2): Symbol not found: ___memcpy_chk
>> Referenced from:
>> /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/numpy/core/multiarray.so
>> Expected in: /usr/lib/libSystem.B.dylib
>>
>>
>>
>
> ------------------------------------------------------------------------------
> This SF.net Dev2Dev email is sponsored by:
>
> Show off your parallel programming skills.
> Enter the Intel(R) Threading Challenge 2010.
> http://p.sf.net/sfu/intel-thread-sfd
> _______________________________________________
> Visualpython-users mailing list
> Vis...@li...
> https://lists.sourceforge.net/lists/listinfo/visualpython-users
|
|
From: Martin C. <cos...@wa...> - 2010-09-09 12:26:30
|
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
|
|
From: Bruce S. <bas...@nc...> - 2010-09-09 16:02:28
|
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 > > > |
|
From: Bruce S. <bas...@nc...> - 2010-09-09 19:36:19
|
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 >> >> >> > |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X