Opened 4 years ago
Closed 4 years ago
#62070 closed defect (fixed)
mpif90-openmpi-gcc10 fails to link FORTRAN program
Reported by: | Guymer (Thomas Guymer) | Owned by: | mascguy (Christopher Nielsen) |
---|---|---|---|
Priority: | Normal | Milestone: | |
Component: | ports | Version: | 2.6.4 |
Keywords: | bigsur | Cc: | |
Port: | openmpi-gcc10 |
Description
Introduction
I have been unable to recompile any of my FORTRAN MPI programs since the upgrade to Big Sur and the reinstallation of all of my ports, I have been able to distil the failure down to a simple "hello world" example. C MPI programs appear to work fine, it is only FORTRAN MPI. I am using Big Sur 11.1 and XCode 12.3, I have manually reinstalled the Command Line Tools from the Apple Developer web site too.
As an aside, the following compile lines are longer than what they would normally be because there have been some changes in Big Sur, see https://apple.stackexchange.com/questions/408999/gfortran-compiler-error-on-mac-os-big-sur on Stack Exchange.
Right, the actual bug: I have attached two files (bar.c and bar.F90).
C "Hello World" without MPI
Run /opt/local/bin/gcc-mp-10 -I/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include bar.c -L/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/lib
and run ./a.out
- everything works as expected.
C "Hello World" with MPI
Run /opt/local/bin/mpicc-openmpi-gcc10 -I/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include bar.c -L/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/lib
and you will get the following output ...
ld: warning: dylib (/opt/local/lib/openmpi-gcc10/libmpi.dylib) was built for newer macOS version (11.1) than being linked (11.0)
...but it is only a warning, so you can still run ./a.out
- everything works as expected.
FORTRAN "Hello World" without MPI
Run /opt/local/bin/gfortran-mp-10 bar.F90 -L/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/lib
and run ./a.out
- everything works as expected.
FORTRAN "Hello World" with MPI
Run /opt/local/bin/mpif90-openmpi-gcc10 bar.F90 -L/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/lib
and you will get the following output ...
ld: warning: dylib (/opt/local/lib/openmpi-gcc10/libmpi_usempif08.dylib) was built for newer macOS version (11.1) than being linked (11.0) ld: warning: dylib (/opt/local/lib/openmpi-gcc10/libmpi_mpifh.dylib) was built for newer macOS version (11.1) than being linked (11.0) ld: warning: dylib (/opt/local/lib/openmpi-gcc10/libmpi_usempi_ignore_tkr.dylib) was built for newer macOS version (11.1) than being linked (11.0) ld: warning: dylib (/opt/local/lib/openmpi-gcc10/libmpi.dylib) was built for newer macOS version (11.1) than being linked (11.0) ld: warning: dylib (/opt/local/lib/openmpi-gcc10/libopen-rte.40.dylib) was built for newer macOS version (11.1) than being linked (11.0) ld: warning: dylib (/opt/local/lib/openmpi-gcc10/libopen-pal.40.dylib) was built for newer macOS version (11.1) than being linked (11.0) ld: file not found: /System/Library/Frameworks/OpenCL.framework/Versions/A/OpenCL for architecture x86_64 collect2: error: ld returned 1 exit status
... which contains many warnings and one error - "a.out" was not created (this is the bug).
Summary
I have been unable to compile a simple one line FORTRAN program using the mpif90-openmpi-gcc10
wrapper. For some reason it wants to link in OpenCL for a simple "Hello World" program. If I run ls -l /System/Library/Frameworks/OpenCL.framework/Versions/A
then I get:
total 0 drwxr-xr-x 14 root wheel 448 1 Jan 08:00:00 2020 Libraries drwxr-xr-x 36 root wheel 1152 1 Jan 08:00:00 2020 Resources drwxr-xr-x 3 root wheel 96 1 Jan 08:00:00 2020 _CodeSignature drwxr-xr-x 3 root wheel 96 1 Jan 08:00:00 2020 lib
Should there be anything else there? Or is it that "mpif90-openmpi-gcc10" is looking in the wrong place? Why is "mpif90-openmpi-gcc10" trying to link to OpenCL? Am I doing anything wrong? All my software used to compile fine.
Thank you for reading all of that :)
Attachments (2)
Change History (21)
Changed 4 years ago by Guymer (Thomas Guymer)
Changed 4 years ago by Guymer (Thomas Guymer)
example FORTRAN "hello world" program
comment:1 Changed 4 years ago by Guymer (Thomas Guymer)
Owner: | set to mascguy |
---|---|
Status: | new → assigned |
comment:2 Changed 4 years ago by Guymer (Thomas Guymer)
Keywords: | bigsur added |
---|
comment:3 Changed 4 years ago by mascguy (Christopher Nielsen)
Thomas, thank you for taking the time to provide all of this detail!
While my Fortran skills are a bit rusty, this will be a great opportunity to dust off the cobwebs. I'll try my best to take a look at this today, if possible.
I'll provide a follow-up, once I've done more investigation.
comment:4 Changed 4 years ago by mascguy (Christopher Nielsen)
Thomas, can you replace both Xcode 12.3 and Xcode CLT 12.3, with their respective 12.2 versions? I ask, as I'm wondering if this is an issue with the latest developer tools.
comment:5 Changed 4 years ago by mascguy (Christopher Nielsen)
On a separate note, have you tried any of the other openmpi-* variations, such as openmpi-default? (Even if your project is dependent on gcc10, it would still help to troubleshoot with alternatives.)
comment:6 Changed 4 years ago by Guymer (Thomas Guymer)
As requested, I have tried out different OpenMPI versions.
Trying openmpi-gcc9
The results were exactly the same.
C Example (Success)
Here is the output:
ld: warning: dylib (/opt/local/lib/openmpi-gcc9/libmpi.dylib) was built for newer macOS version (11.1) than being linked (11.0)
FORTRAN Example (Failure)
Here is the output:
ld: warning: ld: warning: dylib (/opt/local/lib/openmpi-gcc9/libmpi_usempif08.dylib) was built for newer macOS version (11.1) than being linked (11.0)dylib (/opt/local/lib/openmpi-gcc9/libmpi_usempi_ignore_tkr.dylib) was built for newer macOS version (11.1) than being linked (11.0) ld: warning: dylib (/opt/local/lib/openmpi-gcc9/libmpi_mpifh.dylib) was built for newer macOS version (11.1) than being linked (11.0) ld: warning: dylib (/opt/local/lib/openmpi-gcc9/libmpi.dylib) was built for newer macOS version (11.1) than being linked (11.0) ld: warning: dylib (/opt/local/lib/openmpi-gcc9/libopen-rte.40.dylib) was built for newer macOS version (11.1) than being linked (11.0) ld: warning: dylib (/opt/local/lib/openmpi-gcc9/libopen-pal.40.dylib) was built for newer macOS version (11.1) than being linked (11.0) ld: file not found: /System/Library/Frameworks/OpenCL.framework/Versions/A/OpenCL for architecture x86_64 collect2: error: ld returned 1 exit status
Trying openmpi-default
The results were exactly the same (but with different warning/error messages).
C Example (Success)
Here is the output:
In file included from bar.c:1: In file included from /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/stdio.h:64: /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/_stdio.h:93:16: warning: pointer is missing a nullability type specifier (_Nonnull, _Nullable, or _Null_unspecified) [-Wnullability-completeness] unsigned char *_base; ^ /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/_stdio.h:93:16: note: insert '_Nullable' if the pointer may be null unsigned char *_base; ^ _Nullable /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/_stdio.h:93:16: note: insert '_Nonnull' if the pointer should never be null unsigned char *_base; ^ _Nonnull /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/_stdio.h:138:32: warning: pointer is missing a nullability type specifier (_Nonnull, _Nullable, or _Null_unspecified) [-Wnullability-completeness] int (* _Nullable _read) (void *, char *, int); ^ /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/_stdio.h:138:32: note: insert '_Nullable' if the pointer may be null int (* _Nullable _read) (void *, char *, int); ^ _Nullable /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/_stdio.h:138:32: note: insert '_Nonnull' if the pointer should never be null int (* _Nullable _read) (void *, char *, int); ^ _Nonnull /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/_stdio.h:138:40: warning: pointer is missing a nullability type specifier (_Nonnull, _Nullable, or _Null_unspecified) [-Wnullability-completeness] int (* _Nullable _read) (void *, char *, int); ^ /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/_stdio.h:138:40: note: insert '_Nullable' if the pointer may be null int (* _Nullable _read) (void *, char *, int); ^ _Nullable /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/_stdio.h:138:40: note: insert '_Nonnull' if the pointer should never be null int (* _Nullable _read) (void *, char *, int); ^ _Nonnull /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/_stdio.h:139:35: warning: pointer is missing a nullability type specifier (_Nonnull, _Nullable, or _Null_unspecified) [-Wnullability-completeness] fpos_t (* _Nullable _seek) (void *, fpos_t, int); ^ /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/_stdio.h:139:35: note: insert '_Nullable' if the pointer may be null fpos_t (* _Nullable _seek) (void *, fpos_t, int); ^ _Nullable /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/_stdio.h:139:35: note: insert '_Nonnull' if the pointer should never be null fpos_t (* _Nullable _seek) (void *, fpos_t, int); ^ _Nonnull /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/_stdio.h:140:32: warning: pointer is missing a nullability type specifier (_Nonnull, _Nullable, or _Null_unspecified) [-Wnullability-completeness] int (* _Nullable _write)(void *, const char *, int); ^ /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/_stdio.h:140:32: note: insert '_Nullable' if the pointer may be null int (* _Nullable _write)(void *, const char *, int); ^ _Nullable /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/_stdio.h:140:32: note: insert '_Nonnull' if the pointer should never be null int (* _Nullable _write)(void *, const char *, int); ^ _Nonnull /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/_stdio.h:140:46: warning: pointer is missing a nullability type specifier (_Nonnull, _Nullable, or _Null_unspecified) [-Wnullability-completeness] int (* _Nullable _write)(void *, const char *, int); ^ /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/_stdio.h:140:46: note: insert '_Nullable' if the pointer may be null int (* _Nullable _write)(void *, const char *, int); ^ _Nullable /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/_stdio.h:140:46: note: insert '_Nonnull' if the pointer should never be null int (* _Nullable _write)(void *, const char *, int); ^ _Nonnull /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/_stdio.h:144:18: warning: pointer is missing a nullability type specifier (_Nonnull, _Nullable, or _Null_unspecified) [-Wnullability-completeness] struct __sFILEX *_extra; /* additions to FILE to not break ABI */ ^ /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/_stdio.h:144:18: note: insert '_Nullable' if the pointer may be null struct __sFILEX *_extra; /* additions to FILE to not break ABI */ ^ _Nullable /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/_stdio.h:144:18: note: insert '_Nonnull' if the pointer should never be null struct __sFILEX *_extra; /* additions to FILE to not break ABI */ ^ _Nonnull In file included from bar.c:1: /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/stdio.h:67:13: warning: pointer is missing a nullability type specifier (_Nonnull, _Nullable, or _Null_unspecified) [-Wnullability-completeness] extern FILE *__stdinp; ^ /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/stdio.h:67:13: note: insert '_Nullable' if the pointer may be null extern FILE *__stdinp; ^ _Nullable /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/stdio.h:67:13: note: insert '_Nonnull' if the pointer should never be null extern FILE *__stdinp; ^ _Nonnull /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/stdio.h:386:41: warning: pointer is missing a nullability type specifier (_Nonnull, _Nullable, or _Null_unspecified) [-Wnullability-completeness] int (* _Nullable)(void *, const char *, int), ^ /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/stdio.h:386:41: note: insert '_Nullable' if the pointer may be null int (* _Nullable)(void *, const char *, int), ^ _Nullable /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/stdio.h:386:41: note: insert '_Nonnull' if the pointer should never be null int (* _Nullable)(void *, const char *, int), ^ _Nonnull /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/stdio.h:386:55: warning: pointer is missing a nullability type specifier (_Nonnull, _Nullable, or _Null_unspecified) [-Wnullability-completeness] int (* _Nullable)(void *, const char *, int), ^ /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/stdio.h:386:55: note: insert '_Nullable' if the pointer may be null int (* _Nullable)(void *, const char *, int), ^ _Nullable /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/stdio.h:386:55: note: insert '_Nonnull' if the pointer should never be null int (* _Nullable)(void *, const char *, int), ^ _Nonnull /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/stdio.h:387:44: warning: pointer is missing a nullability type specifier (_Nonnull, _Nullable, or _Null_unspecified) [-Wnullability-completeness] fpos_t (* _Nullable)(void *, fpos_t, int), ^ /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/stdio.h:387:44: note: insert '_Nullable' if the pointer may be null fpos_t (* _Nullable)(void *, fpos_t, int), ^ _Nullable /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/stdio.h:387:44: note: insert '_Nonnull' if the pointer should never be null fpos_t (* _Nullable)(void *, fpos_t, int), ^ _Nonnull /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/stdio.h:388:41: warning: pointer is missing a nullability type specifier (_Nonnull, _Nullable, or _Null_unspecified) [-Wnullability-completeness] int (* _Nullable)(void *)); ^ /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/stdio.h:388:41: note: insert '_Nullable' if the pointer may be null int (* _Nullable)(void *)); ^ _Nullable /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/stdio.h:388:41: note: insert '_Nonnull' if the pointer should never be null int (* _Nullable)(void *)); ^ _Nonnull /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/stdio.h:384:6: warning: pointer is missing a nullability type specifier (_Nonnull, _Nullable, or _Null_unspecified) [-Wnullability-completeness] FILE *funopen(const void *, ^ /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/stdio.h:384:6: note: insert '_Nullable' if the pointer may be null FILE *funopen(const void *, ^ _Nullable /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/stdio.h:384:6: note: insert '_Nonnull' if the pointer should never be null FILE *funopen(const void *, ^ _Nonnull 13 warnings generated. ld: warning: dylib (/opt/local/lib/openmpi-mp/libmpi.dylib) was built for newer macOS version (11.1) than being linked (11.0)
FORTRAN Example (Failure)
Here is the output:
ld: warning: dylib (/opt/local/lib/openmpi-mp/libmpi_usempif08.dylib) was built for newer macOS version (11.1) than being linked (11.0) ld: warning: dylib (/opt/local/lib/openmpi-mp/libmpi_usempi_ignore_tkr.dylib) was built for newer macOS version (11.1) than being linked (11.0) ld: warning: dylib (/opt/local/lib/openmpi-mp/libmpi_mpifh.dylib) was built for newer macOS version (11.1) than being linked (11.0) ld: warning: dylib (/opt/local/lib/openmpi-mp/libmpi.dylib) was built for newer macOS version (11.1) than being linked (11.0) ld: warning: dylib (/opt/local/lib/openmpi-mp/libopen-rte.40.dylib) was built for newer macOS version (11.1) than being linked (11.0) ld: warning: dylib (/opt/local/lib/openmpi-mp/libopen-pal.40.dylib) was built for newer macOS version (11.1) than being linked (11.0) ld: file not found: /System/Library/Frameworks/OpenCL.framework/Versions/A/OpenCL for architecture x86_64 collect2: error: ld returned 1 exit status
comment:7 Changed 4 years ago by Guymer (Thomas Guymer)
I will have a go at installing the previous versions of Xcode and Command Line Tools and then give it a try.
Were you able to reproduce my error with the simple one line "Hello World" FORTRAN example?
What does your /System/Library/Frameworks/OpenCL.framework/Versions/A
folder look like? I note that there are five OpenCL.framework
folders on my system:
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/System/Library/Frameworks/OpenCL.framework
/Library/Developer/CommandLineTools/SDKs/MacOSX11.1.sdk/System/Library/Frameworks/OpenCL.framework
/System/Library/Frameworks/OpenCL.framework
/System/Volumes/Data/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/System/Library/Frameworks/OpenCL.framework
/System/Volumes/Data/Library/Developer/CommandLineTools/SDKs/MacOSX11.1.sdk/System/Library/Frameworks/OpenCL.framework
If I run ls
on $DIR/Versions/A
then I can see that numbers 1, 2, 4 and 5 have a file called "OpenCL.tbd" in them, if that makes sense. Is it this file that mpif90
is trying to access? If so, why is it looking in the one OpenCL.framework
folder on my system that doesn't have it? Would any of the other four folders do? How do I change which folder mpif90
is looking in?
Do you have any thoughts as to why mpif90
wants to link in OpenCL but mpicc
doesn't? I cannot understand why OpenCL is required to print "Hello World". Or is mpicc
needing it too but looking in a different place?
comment:8 Changed 4 years ago by Guymer (Thomas Guymer)
If I was to stick my head out here then I would say that openmpi-*
needs to point to /Library/Developer/CommandLineTools/SDKs/MacOSX11.1.sdk/System/Library/Frameworks/OpenCL.framework/Versions/A
when looking for OpenCL. If you look at my original bug report, the ls
for the /System/Library/Frameworks/OpenCL.framework/Versions/A
folder shows that those files were modified on 1st January 2020 whilst "Bug Sur" wasn't released until November 2020. They cannot be "Big Sur" files as they are older than "Big Sur" itself. My guess is that /System/Library/Frameworks/OpenCL.framework/Versions/A
is left over from "Catalina" and Apple didn't bother to remove it during the upgrade. If I run ls -l /Library/Developer/CommandLineTools/SDKs/MacOSX11.1.sdk/System/Library/Frameworks/OpenCL.framework/Versions/A
then the output is:
total 16 drwxr-xr-x 10 root wheel 320 14 Jan 19:28:14 2021 Headers drwxr-xr-x 13 root wheel 416 14 Jan 19:28:14 2021 Libraries drwxr-xr-x 3 root wheel 96 14 Jan 19:28:14 2021 Modules -rw-r--r-- 1 root wheel 6054 30 Nov 12:28:11 2020 OpenCL.tbd drwxr-xr-x 3 root wheel 96 30 Nov 12:33:53 2020 lib
Those dates look far more reasonable as to when I updated from "Catalina" to "Big Sur" (and when I reinstalled Xcode Command Line Tools the other day before filing this bug report). Also note that the list is completely different to the one at the top of this page and that there is a file called OpenCL.tbd
too. Given that gcc9
and gcc10
have to have -L/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/lib
passed to them to work on "Big Sur" is it not reasonable to assume that /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk
is the new prefix for Xcode Command Line Tools in general and that mpif90-*
should go looking in there for what it needs rather than (the clearly outdated) /System/Library/Frameworks/OpenCL.framework/Versions/A
?
What do you think? Does that make sense? The paths seem to make sense to me and the dates returned by ls
seem to be consistent. In short, I think the current version of OpenMPI needs to look in /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/System/$FOLDER
rather than /System/$FOLDER
when installed on "Big Sur". I think that the current paths only work on "Catalina".
comment:9 Changed 4 years ago by Guymer (Thomas Guymer)
One more quick comment: I have just searched the OpenMPI and MacPorts repositories on GitHub and I cannot find "/System/Library/Frameworks/OpenCL.framework" in the source code at all - have you any idea where it is coded up that mpif90-*
needs /System/Library/Frameworks/OpenCL.framework/Versions/A
on a Mac? I was looking for a way to change it on "Big Sur".
comment:10 Changed 4 years ago by mascguy (Christopher Nielsen)
Thanks for all of the additional testing and info, it'll take me a bit to digest it all. More questions/thoughts to follow, once I'm able to make similar tests within Big Sur.
comment:11 Changed 4 years ago by Guymer (Thomas Guymer)
Hi, I am now on Big Sur 11.2.2 and the problem still persists. /System/Library/Frameworks/OpenCL.framework/Versions/A
is still looked in for OpenCL by OpenMPI, even though I don't think it is needed and even if it is then I do not think that it is the correct path to look in.
comment:12 Changed 4 years ago by mascguy (Christopher Nielsen)
Sorry it took so long to get back to this.
Based on some digging, it looks like the OpenCL dependency may be coming from hwloc (which openmpi-* ports depend on):
$ otool -L /opt/local/lib/libhwloc.dylib /opt/local/lib/libhwloc.dylib: /opt/local/lib/libhwloc.15.dylib (compatibility version 20.0.0, current version 20.0.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1252.250.1) /opt/local/lib/libxml2.2.dylib (compatibility version 12.0.0, current version 12.10.0) /System/Library/Frameworks/OpenCL.framework/Versions/A/OpenCL (compatibility version 1.0.0, current version 1.0.0)
Whether we can disable OpenCL usage for hwloc or not, without impacting our users, is another story. More digging to follow.
comment:13 Changed 4 years ago by mascguy (Christopher Nielsen)
I've submitted a pull request for hwloc, with OpenCL support disabled by default. That will eliminate the OpenCL dependency.
I'm not 100% certain whether that alone will solve the issue, but it's a first step.
Once it's merged, I'll let you know.
comment:14 Changed 4 years ago by Christopher Nielsen <62156882+mascguy@…>
comment:15 follow-ups: 16 17 Changed 4 years ago by mascguy (Christopher Nielsen)
The update to hwloc has been merged, and is now available.
Run a port sync (or selfupdate), and then update all ports. Once that's done, try rerunning your test.
comment:16 Changed 4 years ago by Guymer (Thomas Guymer)
Thank you, I will try that today and report back on my progress, cheers.
Replying to mascguy:
The update to hwloc has been merged, and is now available.
Run a port sync (or selfupdate), and then update all ports. Once that's done, try rerunning your test.
comment:17 Changed 4 years ago by Guymer (Thomas Guymer)
Thank you very much for that. I can confirm that both the "minimum working example" and my FORTRAN MPI projects are now compiling and running fine. Thank you very much for solving this bug, I really do appreciate it, cheers!
Replying to mascguy:
The update to hwloc has been merged, and is now available.
Run a port sync (or selfupdate), and then update all ports. Once that's done, try rerunning your test.
comment:18 Changed 4 years ago by mascguy (Christopher Nielsen)
Beautiful, so glad we could solve your problem!
Maintainers, this ticket can be closed.
comment:19 Changed 4 years ago by Christopher Nielsen <mascguy@…>
Resolution: | → fixed |
---|---|
Status: | assigned → closed |
example C "hello world" program