Bootstrapping the recent 14.2 version gcc on MacOS is turning out to be more difficult than expected due to the errorIt's astonishing but Xcode on MacOS is still missing OpenMP support. Here are the results for the single-processor version of pichart on a Mac Mini M4.It would be really interesting to have an entry for one of the Apple M series processors!I would like to run the pichart code on a MacBook Air M2, but get this:Any simple suggestions to get me past this?Code:
@MacBook-Air pichart-40 % makegcc -std=gnu99 -O3 -mtune=native -march=native -Wall -o pichart-serial pichart.c util.c sieve.c merge.c fourier.c lorenz.c -lmgcc -std=gnu99 -O3 -mtune=native -march=native -Wall -fopenmp -o pichart-openmp pichart.c util.c sieve.c merge.c fourier.c lorenz.c -lmclang: error: unsupported option '-fopenmp'clang: error: unsupported option '-fopenmp'clang: error: unsupported option '-fopenmp'clang: error: unsupported option '-fopenmp'clang: error: unsupported option '-fopenmp'clang: error: unsupported option '-fopenmp'clang: error: unsupported option '-fopenmp'make: *** [pichart-openmp] Error 1
According to Mac R Projecthttps://mac.r-project.org/openmp/Apple has explicitly disabled OpenMP support in compilers that they ship in Xcode:
$ clang -c omp.c -fopenmp
clang: error: unsupported option '-fopenmp'
even though clang had OpenMP support for quite a long time now (great thanks to the folks at Intel providing their library as open source!). In fact, the clang compiler in Xcode can generate all the necessary code for OpenMP. It can be tricked into performing its designed function by using -Xclang -fopenmp flags.
The unfortunate part about this is that Apple is not shipping the necesssary libomp.dylib run-time library needed for OpenMP support. Fortunately, some clever folks were able to match the versions so we can build the binaries that correspond to the clang version used. It is sometimes possible to use a more recent version of the runtime than the version of Apple clang, so picking the latest is often sufficient.
Note that Apple's gcc command points to clang on MacOS, apparently to increase confusion.
While libraries compatible with the native tools are provided on the above website, I'd probably build my own version of clang LLVM from source and a real version of gcc for comparison
Another option popular on the web is to install the binary packages using homebrew.
See, for example
https://thelinuxnotes.com/index.php/res ... -on-macos/
Fido objects to the graphic of a dog developer on a hot chair, but the content looks reasonable to me.
Code:
*** Configuration aarch64-apple-darwin24.1.0 not supportedhttps://gcc.gnu.org/bugzilla/show_bug.cgi?id=116809
which seems to indicate ongoing gcc support on MacOS has been an ongoing difficulty due to changes in Xcode.
The canine coder has been barking all evening about how Apple does not have enough developers to fully support the platform. I think the barking is mostly due to lack of corporate interest during the epidemic for replacing MacOS by FidoBASIC.
Statistics: Posted by ejolson — Thu Jan 02, 2025 4:23 pm