#28346 closed defect (fixed)
py26-numpy, py27-numpy: universal is not universal
Reported by: | dumont.guillaume@… | Owned by: | Veence (Vincent) |
---|---|---|---|
Priority: | Normal | Milestone: | |
Component: | ports | Version: | 1.9.2 |
Keywords: | Cc: | MarcusCalhoun-Lopez (Marcus Calhoun-Lopez), stromnov (Andrey Stromnov), skymoo (Adam Mercer), michaelld (Michael Dickens) | |
Port: | py26-numpy, py27-numpy |
Description (last modified by skymoo (Adam Mercer))
Hi,
I am trying to build numpy with python 2.7 as a 32 bit since I would like to use the wxpython port and the numpy port with the same version of python.
I tried to
port install py27-numpy -atlas +universal
with the default build_arch setting and with build_arch set to i386. The install goes trough without any errors and I can import numpy without any problem if python is running in x86_64 mode but if I start python with the command
arch -i386 python
and try to import numpy I always get
File "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/numpy/core/__init__.py", line 5, in <module> import multiarray ImportError: dlopen(/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/numpy/core/multiarray.so, 2): no suitable image found. Did find: /opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/numpy/core/multiarray.so: mach-o, but wrong architecture
If I run lipo on this library I get:
Non-fat file: /opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/numpy/core/multiarray.so is architecture: x86_64
which seems to tell me that this library was built as 64 bit regardless of the build_arch setting.
Is this a known problem?
Thanks
Attachments (2)
Change History (22)
comment:1 Changed 14 years ago by skymoo (Adam Mercer)
Description: | modified (diff) |
---|
comment:2 follow-up: 4 Changed 14 years ago by ryandesign (Ryan Carsten Schmidt)
Cc: | ram@… removed |
---|---|
Owner: | changed from macports-tickets@… to ram@… |
Port: | py26-numpy added |
Summary: | cannot build py27-numpy as i386 on SnowLeopard → py26-numpy, py27-numpy: universal is not universal |
@ram: If the universal variant doesn't produce universal software (and I confirmed this is the case on my Snow Leopard system as well) it should be disabled.
@dumont.guillaume: If you only want i386, then set build_arch to i386 and do not use the universal variant. build_arch is only used when not building universal. (When building universal, universal_archs is used.)
comment:3 Changed 14 years ago by jmroot (Joshua Root)
Cc: | mcalhoun@… stromnov@… added |
---|
comment:4 Changed 14 years ago by dumont.guillaume@…
Replying to ryandesign@…:
@ram: If the universal variant doesn't produce universal software (and I confirmed this is the case on my Snow Leopard system as well) it should be disabled.
@dumont.guillaume: If you only want i386, then set build_arch to i386 and do not use the universal variant. build_arch is only used when not building universal. (When building universal, universal_archs is used.)
Ok thanks I have successfully built numpy as i386. I should be able to get I want.
comment:5 Changed 14 years ago by skymoo (Adam Mercer)
I agree that universal should be disabled, if mcalhoun and stromnov object otherwise I'll disable universal on early next week.
comment:6 follow-up: 7 Changed 14 years ago by Veence (Vincent)
For eons I have a private Portfile and system with which one can build py26 and py27-numpy as universal files, but nobody seems to care…
-> port installed py26-numpy Warning: port definitions are more than two weeks old, consider using selfupdate The following ports are currently installed: py26-numpy @1.5.1_0+gcc45+universal (active)
comment:7 Changed 14 years ago by skymoo (Adam Mercer)
Replying to vince@…:
For eons I have a private Portfile and system with which one can build py26 and py27-numpy as universal files, but nobody seems to care…
Was that the one with the wrapper to gcc?
comment:8 follow-up: 9 Changed 14 years ago by Veence (Vincent)
Yes, what's wrong with them? I can build both numpy and scipy as two-way universal binaries…
comment:9 Changed 14 years ago by skymoo (Adam Mercer)
Replying to vince@…:
Yes, what's wrong with them? I can build both numpy and scipy as two-way universal binaries…
I just tend not to spend much time looking at anything regarding universal as I just don't use it. Provided it doesn't effect the standard build I have no objections.
Changed 14 years ago by Veence (Vincent)
Attachment: | py27-numpy.tgz added |
---|
comment:10 Changed 14 years ago by Veence (Vincent)
The file I have uploaded is my universal py27-numpy Macports directory. Please test if you care, and tell me of any bugs.
comment:11 Changed 14 years ago by skymoo (Adam Mercer)
It's hard to see the changes as you've also changed the whitespace, could you just attach a diff that doesn't change the whitespace so I can clearly see whats changed.
Changed 14 years ago by Veence (Vincent)
Attachment: | Portfile.diff added |
---|
Portfile -> Portfile (universal)
comment:13 Changed 14 years ago by Veence (Vincent)
The same trick can be used to build a universal variant of scipy…
comment:14 Changed 14 years ago by skymoo (Adam Mercer)
Cc: | ram@… added |
---|---|
Owner: | changed from ram@… to vince@… |
No objections from me. Feel free to add yourself to the list of maintainers.
comment:15 Changed 14 years ago by Veence (Vincent)
Resolution: | → fixed |
---|---|
Status: | new → closed |
comment:16 Changed 14 years ago by skymoo (Adam Mercer)
How about py25-numpy
to keep things consistent?
comment:17 Changed 14 years ago by Veence (Vincent)
I am not sure python25 support universal variants. Could you check this?
comment:18 Changed 14 years ago by skymoo (Adam Mercer)
Don't know, python25
says it supports the universal variant:
$ port variants python25 python25 has the variants: universal: Build for multiple architectures
comment:19 Changed 14 years ago by jmroot (Joshua Root)
Technically python25 does have universal support, but its build system will only do i386+ppc. So it's not actually that useful.
NumPy has never played nice with the universal variant and I've never had much success in getting it to work. Plus it's never been high on my priority list as I personally never use universal.