Apple Silicon support?
Opened this issue · 8 comments
Is support for Apple Silicon processors planned or possible?
Currently, I get this error if I try to compile on an Apple M1 system:
checking build system type... Invalid configuration `arm64-apple-darwin20.0.0': machine `arm64-apple' not recognized
configure: error: /bin/sh ../build-aux/config.sub arm64-apple-darwin20.0.0 failed
You probably just need to re-./autogen.sh
with an autoconf that supports it?
StarPU itself is very arch-independent, by using gcc atomics & such.
Thanks! I know next to nothing about these gnu tools.
That got me further. I'll tinker with it some more. I guess now it's complaining about not having MKL (which doesn't exist for Apple Silicon). I guess there's probably a way to link with a different BLAS/Lapack?
now it's complaining about not having MKL
That shouldn't be a problem, starpu itself doesn't need a blas library. Do you actually get an error message?
Looks like it's trying to link with the x86 MKL:
...
ld: warning: directory not found for option '-L/opt/intel/oneapi/mkl/2022.0.0/lib/intel64'
ld: warning: ignoring file /opt/intel/oneapi/mkl/2022.0.0/lib/libmkl_intel_lp64.dylib, building for macOS-arm64 but attempting to link with file built for macOS-x86_64
ld: warning: ignoring file /opt/intel/oneapi/mkl/2022.0.0/lib/libmkl_sequential.dylib, building for macOS-arm64 but attempting to link with file built for macOS-x86_64
ld: warning: ignoring file /opt/intel/oneapi/mkl/2022.0.0/lib/libmkl_core.dylib, building for macOS-arm64 but attempting to link with file built for macOS-x86_64
1 warning generated.
CC heat/dw_factolu_grain.o
1 warning generated.
CC heat/dw_sparse_cg.o
Undefined symbols for architecture arm64:
"_dasum_", referenced from:
_STARPU_DASUM in blas.o
"_daxpy_", referenced from:
_STARPU_DAXPY in blas.o
"_ddot_", referenced from:
_STARPU_DDOT in blas.o
"_dgemm_", referenced from:
_STARPU_DGEMM in blas.o
"_dgemv_", referenced from:
_STARPU_DGEMV in blas.o
"_dger_", referenced from:
_STARPU_DGER in blas.o
"_dpotrf_", referenced from:
_STARPU_DPOTRF in blas.o
...
ld: symbol(s) not found for architecture arm64
clang-16: error: linker command failed with exit code 1 (use -v to see invocation)
When I add --enable-blas-lib=none
to the ../configure
call I get:
...
checking for FFTW... checking for FFTWF... checking for FFTWL... checking for HWLOC... configure: error: libhwloc or pkg-config was not found on your system. If the target machine is hyperthreaded the performance may be impacted a lot. It is strongly recommended to install libhwloc and pkg-config. However, if you really want to use StarPU without enabling libhwloc, please restart configure by specifying the option '--without-hwloc'.
I have hwloc installed via conda. How do I tell it where that is located?
If I add --without-hwloc
, I get
...
icc: warning #10193: -vec is default; use -x and -ax to configure vectorization
ld: warning: ignoring file basic_examples/vector_scal_opencl.o, building for macOS-x86_64 but attempting to link with file built for unknown-arm64
ld: warning: ignoring file basic_examples/vector_scal_cpu.o, building for macOS-x86_64 but attempting to link with file built for unknown-arm64
ld: warning: ignoring file ../src/.libs/libstarpu-1.4.dylib, building for macOS-x86_64 but attempting to link with file built for macOS-arm64
ld: warning: ignoring file basic_examples/vector_scal.o, building for macOS-x86_64 but attempting to link with file built for unknown-arm64
ld: warning: ignoring file /Users/jwilliam/git/qr_mumps_build/env/lib/libc++.dylib, building for macOS-x86_64 but attempting to link with file built for macOS-arm64
CCLD filters/fndim_to_vector
CCLD filters/fndim_to_matrix
CCLD filters/fndim_to_variable
Undefined symbols for architecture x86_64:
"_main", referenced from:
implicit entry/start for main executable
ld: symbol(s) not found for architecture x86_64
make[3]: *** [basic_examples/vector_scal] Error 1
make[3]: *** Waiting for unfinished jobs....
make[2]: *** [all-recursive] Error 1
make[1]: *** [all] Error 2
make: *** [all-recursive] Error 1
No idea why it's trying to build x86_64
code.
Update after I pasted all this in I noticed the icc
. So it's using the intel icc
compiler (which is x86_64
). I'll try to prevent it from doing that...
I have hwloc installed via conda. How do I tell it where that is located?
If libhwloc is installed in a standard location, no option is required, it will be detected automatically, otherwise --with-hwloc= should be used to specify its location.
Another (standard) way is to set the PKG_CONFIG_PATH
environment variable to the lib/pkgconfig
directory.
I just can't quite get this working.
Here's my script. I gave up on conda and now just trying to use homebrew:
#!/bin/bash
# now: before running this, install homebrew and:
#
# brew install libtool
# brew install wget
# brew install autoconf
# brew install automake
# brew install gcc
# brew install pkg-config
# brew install hwloc
set -e
STARPUVERSION=1.4.1
STARPUDIR=$PWD/starpu
STARPUINSTALLDIR=$STARPUDIR/install
rm -rf $STARPUDIR
rm -rf $INSTALLDIR
# try from brew:
export CXX=/opt/homebrew/bin/g++-13
export CPP=/opt/homebrew/bin/cpp-13
export CC=/opt/homebrew/bin/gcc-13
export FC=/opt/homebrew/bin/gfortran-13
export F77=/opt/homebrew/bin/gfortran-13
export AR=/usr/bin/ar
export RANLIB=/usr/bin/ranlib
export NM=/usr/bin/nm
export AS=/usr/bin/as
# build StarPU
mkdir $STARPUDIR
cd $STARPUDIR
STARPUINSTALLDIR=$PWD/install
wget https://files.inria.fr/starpu/starpu-$STARPUVERSION/starpu-${STARPUVERSION}.tar.gz
tar xf starpu-${STARPUVERSION}.tar.gz
cd starpu-${STARPUVERSION}
./autogen.sh
mkdir build
cd build
../configure --prefix=$STARPUINSTALLDIR --disable-build-tests --disable-build-doc --enable-blas-lib=none
make -j 4
make install
The result is that it starts to compile. I do get a million warnings like this:
<command-line>: warning: "_FORTIFY_SOURCE" redefined
<command-line>: note: this is the location of the previous definition
CC sched_ctx/sched_ctx_remove.o
<command-line>: warning: "_FORTIFY_SOURCE" redefined
<command-line>: note: this is the location of the previous definition
CC sched_ctx/sched_ctx_delete.o
CC sched_ctx/two_cpu_contexts.o
CC sched_ctx/dummy_sched_with_ctx.o
<command-line>: warning: "_FORTIFY_SOURCE" redefined
<command-line>: note: this is the location of the previous definition
<command-line>: warning: "_FORTIFY_SOURCE" redefined
<command-line>: note: this is the location of the previous definition
But in the end it errors out with this:
<command-line>: warning: "_FORTIFY_SOURCE" redefined
<command-line>: note: this is the location of the previous definition
f951: Warning: Nonexistent include directory '/Library/Python/3.9/include' [-Wmissing-include-dirs]
<command-line>:6:0:
Warning: "_FORTIFY_SOURCE" redefined
<command-line>:5:0:
note: this is the location of the previous definition
<command-line>: warning: "_FORTIFY_SOURCE" redefined
<command-line>: note: this is the location of the previous definition
../../examples/cpp/add_vectors_cpp11.cpp:22:10: fatal error: cassert: No such file or directory
22 | #include <cassert>
| ^~~~~~~~~
compilation terminated.
make[3]: *** [cpp/add_vectors_cpp11.o] Error 1
make[3]: *** Waiting for unfinished jobs....
make[2]: *** [all-recursive] Error 1
make[1]: *** [all] Error 2
make: *** [all-recursive] Error 1
Your c++ compiler doesn't have the standard <cassert>
header? You can try to replace that with <assert.h>
update: I've gotten it to compile. The main problem was the presence of the icc
32 bit C compiler in my path. Somehow that was messing things up. Once I got rid of that and updated the script a bit it seems to compile.
Still trying to figure out if it's actually working.
I'll post the updated script here for reference once I verify that it's working.