I've created a pull request [1] to incorporate this patch. As noted on the PR, I have no way to test the end result; perhaps someone else would like to try it?
Thanks, - Eric [1] https://github.com/macports/macports-ports/pull/8859 On Mon, Oct 19, 2020 at 11:19 AM Christopher Chavez <chrischa...@gmx.us> wrote: > Hello Michael, > > Thank you very much for this information. I am forwarding this to the > macports-dev mailing list for others who are involved in MacPorts more > closely and for much longer than I have been. > > > On Friday, October 16, 2020 at 6:32 PM, Mike Pique wrote: > > > I have a DTK and have built OpenMP both for arm64 an x86_64. You need to > compile with “-Xclang -fopenmp” and to include the OMP header files. You > need to link with -l omp and include the path to the run-time library > directory. Example: > > > cc -I /usr/local/include -Xclang -fopenmp omp_hello.c -L /usr/local/lib > -l omp -o omp_hello > > > For arm64, when you build the openmp run-time library you need to change > 5 lines in the assembly language file Z_Linux_asm.S (disregard the historic > “Linux” - it has #ifdefs for many platforms). On 24 September, I submitted > my 5-line patch to the OpenMP group (differential ID D88252) where it is > under review. The 5-line patch affects only arm64 builds and corrects an > assumption in the code that MacOS (Mach-O) object files are never built for > arm64; the patched version is completely x86_64-compatible. > > > I’ve not been able to figure out how to interest HomeBrew and MacPorts > about this, presumable when eventually OpenMP adopts it (or something > similar) that will flow downstream. But I had several pieces of our lab’s > scientific software needing OpenMP so I went ahead for my work without > waiting. > > > Let me know any suggestions on how, or whether, these changes should be > put into MacPorts and/or HomeBrew. Thank you. > > > MacPorts is likely interested in this. It currently has some support for > OpenMP: the recommended approach would be for portfiles to specify > `compiler.openmp_version`, so that an OpenMP-capable compiler and a > MacPorts-provided libomp are used. But plenty of ports which could use > OpenMP aren't doing so yet, or are not using it by default. One concert was > the fact an alternative MacPorts-provided compiler was needed; this new > info may help with using Xcode clang instead, which I wonder could be as > simple as tweaking the paths to use MacPorts' libomp. There are still some > other concerns, such as how using OpenMP in library ports affects building > their dependents. I'm also not aware whether MacPorts has considered OpenMP > on ARM64 yet either. > > Searching online for "-Xclang" "-fopenmp" reveals there are a few other > interesting posts out there on the topic. > > Christopher A. Chavez >
