Re: OpenBLAS fails to compile
Success! (I wonder why it would build the whole thing rather than downloading a binary; but it did build). And python37 does import numpy now. Thanks much, Uli On 1/18/20 6:24 PM, Ryan Schmidt wrote: On Jan 18, 2020, at 17:20, Uli Wienands wrote: This is on OS-X 10.6.8, Macports 2.6.1. Please "sudo port selfupdate" to get MacPorts 2.6.2. I am trying to get py37-numpy installed. One dependency is OpenBLAS which fails to build. It looks like I am running into the same error Ken already reported:58832. This has to do with 64-bit mode. Per the stats on the Macports website, open BLAS does build in 32-bit mode on 10.6. Be aware that those stats are not necessarily up to date and so are not a reliable indicator of whether something currently works. See https://github.com/macports/macports-webapp/issues/135 Right now, https://ports.macports.org/port/OpenBLAS/summary shows that OpenBLAS has a green status on 10.6 i386, but if you click on it to get more info, you'll see that that refers to version 0.3.6_1, not the current version 0.3.7. However, if we check https://packages.macports.org/OpenBLAS/, it does show a package exists for 0.3.7 for 10.6 i386, so it looks like that is indeed available. Soo... how do I make it do that?? I don't see any variant that looks like that. Also, I assume that the whole of numpy has to be 32 bit for this to work... or? The thing is: I have numpy working with python 3.6 (well, it imports & a very cursory test suggests it is not totally broken). So there does seem to be a way to build it on this system. You can't just decide to build one port or the other 32-bit. If you want to make your entire MacPorts installation 32-bit, you can uninstall all ports, change build_arch to i386 in macports.conf, and then reinstall the ports you want. We do have a 32-bit buildbot worker for 10.6, so hopefully you will be able to get most ports as binaries, just as you can on 64-bit 10.6. But it is possible / likely that some other ports will fail to build in this configuration. (If so, please file bug reports as usual.) I don't really recommend trying that. It would be better to fix OpenBLAS to work on 10.6 x86_64. Ken says in the ticket that he already figured out a fix. It also says that OpenBLAS-devel already works on 10.6 x86_64, so I recommend you use that instead of OpenBLAS until OpenBLAS is fixed. sudo port install OpenBLAS-devel
Re: OpenBLAS fails to compile
On Jan 18, 2020, at 17:20, Uli Wienands wrote: > This is on OS-X 10.6.8, Macports 2.6.1. Please "sudo port selfupdate" to get MacPorts 2.6.2. > I am trying to get py37-numpy installed. One dependency is OpenBLAS which > fails to build. It looks like I am running into the same error Ken already > reported:58832. This has to do with 64-bit mode. > > Per the stats on the Macports website, open BLAS does build in 32-bit mode on > 10.6. Be aware that those stats are not necessarily up to date and so are not a reliable indicator of whether something currently works. See https://github.com/macports/macports-webapp/issues/135 Right now, https://ports.macports.org/port/OpenBLAS/summary shows that OpenBLAS has a green status on 10.6 i386, but if you click on it to get more info, you'll see that that refers to version 0.3.6_1, not the current version 0.3.7. However, if we check https://packages.macports.org/OpenBLAS/, it does show a package exists for 0.3.7 for 10.6 i386, so it looks like that is indeed available. > Soo... how do I make it do that?? I don't see any variant that looks like > that. Also, I assume that the whole of numpy has to be 32 bit for this to > work... or? > > The thing is: I have numpy working with python 3.6 (well, it imports & a very > cursory test suggests it is not totally broken). So there does seem to be a > way to build it on this system. You can't just decide to build one port or the other 32-bit. If you want to make your entire MacPorts installation 32-bit, you can uninstall all ports, change build_arch to i386 in macports.conf, and then reinstall the ports you want. We do have a 32-bit buildbot worker for 10.6, so hopefully you will be able to get most ports as binaries, just as you can on 64-bit 10.6. But it is possible / likely that some other ports will fail to build in this configuration. (If so, please file bug reports as usual.) I don't really recommend trying that. It would be better to fix OpenBLAS to work on 10.6 x86_64. Ken says in the ticket that he already figured out a fix. It also says that OpenBLAS-devel already works on 10.6 x86_64, so I recommend you use that instead of OpenBLAS until OpenBLAS is fixed. sudo port install OpenBLAS-devel
OpenBLAS fails to compile
This is on OS-X 10.6.8, Macports 2.6.1. I am trying to get py37-numpy installed. One dependency is OpenBLAS which fails to build. It looks like I am running into the same error Ken already reported:58832. This has to do with 64-bit mode. Per the stats on the Macports website, open BLAS does build in 32-bit mode on 10.6. Soo... how do I make it do that?? I don't see any variant that looks like that. Also, I assume that the whole of numpy has to be 32 bit for this to work... or? The thing is: I have numpy working with python 3.6 (well, it imports & a very cursory test suggests it is not totally broken). So there does seem to be a way to build it on this system. Uli
Re: Test in local repository without privileges
On Fri, 17 Jan 2020 at 23:44, Christopher Jones
wrote:
> On 17 Jan 2020, at 10:36 pm, Dave Allured - NOAA Affiliate via macports-users
> wrote:
>
> Chris, thanks for the quick reply. You are correct, a private macports
> installation would enable testing ports without special privilege. Actually
> I have already done this many times for testing and debugging other cases.
>
> However, I would like to find an intermediate solution that avoids full
> build-up from sources. My main reasons are (1) test sensitivity to installed
> ports in the system prefix; (2) save time and effort; and (3) be able to
> provide compact, uncomplicated reproducers to third parties.
>
> If not currently possible, it would be nice to have a new feature to enable
> local repository testing, with fallback to the system prefix for everything
> not found in the local repository.
>
> What you are asking for is I am afraid really not possible, I suspect. The
> installation prefix is a fundamental parameter in most port builds. Many
> directly use this via the ${prefix} variable, which is a single valued path.
> What you are asking for is for a port use to use one location for some ports
> and a second one from others. I just don’t see how that could work.
>
> I think your only option is really to go with a second installation using a
> custom prefix.
The only thing we could potentially do (but sadly I don't see it
coming any time soon unless we get a devoted developer with sufficient
time and skillset willing to work on this) is to support
"relocatability" of packages to avoid building everything from source.
It should be possible to a certain extent (at least our competitors
did it).
However installing some packages in one prefix and others in another
is going to lead to countless troubles. Binaries have absolute links
to their dependencies. So if you have library A, library B which
depends on A, and binary C which depends on B, you install all three
to /opt/local and then decide to test B in local installation using A
from global prefix, this will generate a mess and will stop working as
soon as A in global prefix is updated. Moreover you also need to
install C to local prefix, else the test won't be "complete". I could
keep on talking about problems, but long story short: not an option.
Mojca
