[MacPorts] #48381: OpenBlas: difficulty detecting architecture
MacPorts
noreply at macports.org
Tue Aug 11 03:26:08 PDT 2015
#48381: OpenBlas: difficulty detecting architecture
--------------------------+---------------------
Reporter: aaron.koe@… | Owner: nicos@…
Type: defect | Status: new
Priority: Normal | Milestone:
Component: ports | Version: 2.3.3
Resolution: | Keywords:
Port: openblas |
--------------------------+---------------------
Comment (by andy.nowacki@…):
In fact, things are working as per the port file. The portfile contains:
{{{
if { ![catch {sysctl hw.optional.avx1_0} has_avx] && $has_avx == 1 } {
#Use clang if the processor has avx instructions
default_variants +clang
} else {
#Else, use gcc48 as default
default_variants +gcc48
}
}}}
And then, if the variant is not clang, we do the following:
{{{
if {![variant_isset clang]} {
puts $makeINC "NO_AVX = 1"
}
}}}
(Note that `sysctl hw.optional.avx1_0` outputs 1 on my machine.)
Because I have been using the +gcc48 variant (mainly just to avoid having
to add dragonegg to my list of ports), the line `NO_AVX = 1` is added to
the Makefile.rule file, and it is this which leads to `CORE=NEHALEM` from
getarch. If this is intended behaviour, probably something should be
added to the information about the port to this effect.
Building with gcc, not clang, doesn't appear to lead to any build problems
when using AVX instructions, and these give a big boost to speed. I
wonder what the reason was to require (i) that gcc is needed for machines
without AVX; and (ii) whether choosing a gcc?? variant should preclude
using AVX instructions. Perhaps the latter situation was an unintended
side-effect? Apologies if there are deeper causes I am missing.
I think this means OpenBLAS @0.2.12_2 is actually fixed, but perhaps both
ports need their portfile tweaking?
--
Ticket URL: <https://trac.macports.org/ticket/48381#comment:12>
MacPorts <https://www.macports.org/>
Ports system for OS X
More information about the macports-tickets
mailing list