Re: devel/openmpi mpifort error; compiler

[Martin Reindl]

On Mon, Jan 27, 2020 at 09:30:15AM -0700, j...@bitminer.ca wrote:
> Hi Martin,
> 
> Thanks for the pointer to a ports page (I needed to reread it,
> clearly!).
> 
> Just one nit to your example: perhaps reformat to style(9).

Sure, why not!
And README needs to go into the PLIST of course.


Index: Makefile
===
RCS file: /cvs/ports/devel/openmpi/Makefile,v
retrieving revision 1.29
diff -u -p -u -p -r1.29 Makefile
--- Makefile22 Dec 2019 15:47:35 -  1.29
+++ Makefile27 Jan 2020 18:36:49 -
@@ -4,18 +4,19 @@ COMMENT = open source MPI-3.1 implement
 
 V =4.0.2
 DISTNAME = openmpi-$V
+REVISION = 0
 
-SHARED_LIBS +=  mca_common_dstore 0.0 # 1.0
+SHARED_LIBS +=  mca_common_dstore 0.0 # 1.1
 SHARED_LIBS +=  mca_common_monitoring 0.0 # 60.0
-SHARED_LIBS +=  mca_common_ompio  0.0 # 60.1
+SHARED_LIBS +=  mca_common_ompio  0.0 # 60.2
 SHARED_LIBS +=  mca_common_sm 2.0 # 60.0
-SHARED_LIBS +=  mpi   1.0 # 60.1
-SHARED_LIBS +=  mpi_mpifh 0.0 # 60.1
+SHARED_LIBS +=  mpi   2.0 # 60.2
+SHARED_LIBS +=  mpi_mpifh 0.0 # 60.2
 SHARED_LIBS +=  mpi_usempi_ignore_tkr 0.0 # 60.0
-SHARED_LIBS +=  mpi_usempif08 0.0 # 60.0
+SHARED_LIBS +=  mpi_usempif08 0.0 # 60.1
 SHARED_LIBS +=  ompitrace 0.0 # 60.0
-SHARED_LIBS +=  open-pal  1.0 # 60.1
-SHARED_LIBS +=  open-rte  1.0 # 60.1
+SHARED_LIBS +=  open-pal  2.0 # 60.2
+SHARED_LIBS +=  open-rte  2.0 # 60.2
 
 CATEGORIES =   devel
 
@@ -30,11 +31,19 @@ WANTLIB += c execinfo m pciaccess pthrea
 
 MASTER_SITES = 
${HOMEPAGE}/software/ompi/v${V:C/^([0-9]+\.[0-9]+).*/\1/}/downloads/
 
-COMPILER = base-clang ports-gcc
+COMPILER = ports-gcc
+
+# MODULES=fortran always uses ports-gcc (and overrides COMPILER)
+# the openmpi applications and libraries will be built with ports-gcc, but
+# are compatible with base-clang on archs where it is available
 MODULES =  fortran
 MODFORTRAN_COMPILER =  gfortran
 BUILD_DEPENDS =devel/libtool,-ltdl
 LIB_DEPENDS =  devel/libexecinfo
+
+CONFIGURE_ARGS +=  --enable-mpi-fortran=usempif08 \
+   FC=egfortran \
+   CC=egcc
 
 MAKE_FLAGS =   V=1
 FAKE_FLAGS =   sysconfdir=${PREFIX}/share/examples/openmpi/
Index: pkg/PLIST
===
RCS file: /cvs/ports/devel/openmpi/pkg/PLIST,v
retrieving revision 1.6
diff -u -p -u -p -r1.6 PLIST
--- pkg/PLIST   22 Dec 2019 15:47:36 -  1.6
+++ pkg/PLIST   27 Jan 2020 18:36:49 -
@@ -41,37 +41,37 @@ include/openmpi/mpiext/mpiext_cuda_c.h
 include/openmpi/mpiext/mpiext_pcollreq_c.h
 include/openmpi/mpiext/mpiext_pcollreq_mpifh.h
 include/openmpi/mpiext/pmpiext_pcollreq_c.h
-lib/libmca_common_dstore.a
+@static-lib lib/libmca_common_dstore.a
 lib/libmca_common_dstore.la
 @lib lib/libmca_common_dstore.so.${LIBmca_common_dstore_VERSION}
-lib/libmca_common_monitoring.a
+@static-lib lib/libmca_common_monitoring.a
 lib/libmca_common_monitoring.la
 @lib lib/libmca_common_monitoring.so.${LIBmca_common_monitoring_VERSION}
-lib/libmca_common_ompio.a
+@static-lib lib/libmca_common_ompio.a
 lib/libmca_common_ompio.la
 @lib lib/libmca_common_ompio.so.${LIBmca_common_ompio_VERSION}
-lib/libmca_common_sm.a
+@static-lib lib/libmca_common_sm.a
 lib/libmca_common_sm.la
 @lib lib/libmca_common_sm.so.${LIBmca_common_sm_VERSION}
-lib/libmpi.a
+@static-lib lib/libmpi.a
 lib/libmpi.la
 @lib lib/libmpi.so.${LIBmpi_VERSION}
-lib/libmpi_mpifh.a
+@static-lib lib/libmpi_mpifh.a
 lib/libmpi_mpifh.la
 @lib lib/libmpi_mpifh.so.${LIBmpi_mpifh_VERSION}
-lib/libmpi_usempi_ignore_tkr.a
+@static-lib lib/libmpi_usempi_ignore_tkr.a
 lib/libmpi_usempi_ignore_tkr.la
 @lib lib/libmpi_usempi_ignore_tkr.so.${LIBmpi_usempi_ignore_tkr_VERSION}
-lib/libmpi_usempif08.a
+@static-lib lib/libmpi_usempif08.a
 lib/libmpi_usempif08.la
 @lib lib/libmpi_usempif08.so.${LIBmpi_usempif08_VERSION}
-lib/libompitrace.a
+@static-lib lib/libompitrace.a
 lib/libompitrace.la
 @lib lib/libompitrace.so.${LIBompitrace_VERSION}
-lib/libopen-pal.a
+@static-lib lib/libopen-pal.a
 lib/libopen-pal.la
 @lib lib/libopen-pal.so.${LIBopen-pal_VERSION}
-lib/libopen-rte.a
+@static-lib lib/libopen-rte.a
 lib/libopen-rte.la
 @lib lib/libopen-rte.so.${LIBopen-rte_VERSION}
 lib/mpi.mod
@@ -84,288 +84,288 @@ lib/mpi_f08_interfaces_callbacks.mod
 lib/mpi_f08_types.mod
 lib/ompi_monitoring_prof.a
 lib/ompi_monitoring_prof.la
-lib/ompi_monitoring_prof.so
+@so lib/ompi_monitoring_prof.so
 lib/openmpi/
-lib/openmpi/libompi_dbg_msgq.a
+@static-lib lib/openmpi/libompi_dbg_msgq.a
 lib/openmpi/libompi_dbg_msgq.la
-lib/openmpi/libompi_dbg_msgq.so
+@so lib/openmpi/libompi_

Re: devel/openmpi mpifort error; compiler

[j]

Hi Martin,

Thanks for the pointer to a ports page (I needed to reread it,
clearly!).

Just one nit to your example: perhaps reformat to style(9).


John

On 2020-01-27 01:12, Martin Reindl wrote:

[CCing Dave Raymond who helped with the openmpi-4.0.1 update]

On Sun, Jan 26, 2020 at 09:21:30AM -0700, j...@bitminer.ca wrote:

Hi Martin,

I don't know how to compare the libraries (md5?).  I reviewed the
build logs and diff'd the text files (.h).  The build logs showed
the same compilers (gnu) was used to create mpi binaries and
libraries.  The .h files had no differences.


Please have a look at
https://www.openbsd.org/faq/ports/specialtopics.html#SharedLibs


Reviewing the source
is what convinced me that FC (and CC) were used only in
defining the compiler name used by mpicc and mpifort commands.

And the default cc compiler has changed to egcc as intended:


o67snap$ mpicc -v
Using built-in specs.
COLLECT_GCC=/usr/local/bin/egcc
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/x86_64-unknown-openbsd6.6/8.3.0/lto-wrapper
...etc etc.


Now as for C++, it's likely that the clang C++ compiler is to be
preferred by users (on AMD64) as all C++ ports are built with that.
OpenMPI has no C++ API and C++ code therefore uses the C interface.
And that works (I tried a couple of open-source codes to verify). By
"works" I mean it compiles and runs using clang C++ and linked with
the gcc-built OpenMPI.  (https://ascl.net/1911.001 PLAN, and
https://ascl.net/1511.022 ZInCo).



Thanks for the feedback, I've decided to put everything in a single 
diff

and tested these changes now:

- reenable fortran support
- switch COMPILER to ports-gcc only, due to limitations in the
  build system, MODULES=fortran requires ports-gcc anyway. If problems
  with C++ ever show up, we might make a version with fortran disabled
  and base-clang only. For compiling mpi applications, base-clang
  is still an option as you have showed.
- adjust SHARED_LIBS accordingly, add @so lib markers while there
- add your README, amended by an example code to have everything at
  hand to run a simple mpi program

I think this reflects reality best and I would like to commit this soon 
:)


-m


Index: Makefile
===
RCS file: /cvs/ports/devel/openmpi/Makefile,v
retrieving revision 1.29
diff -u -p -u -p -r1.29 Makefile
--- Makefile22 Dec 2019 15:47:35 -  1.29
+++ Makefile27 Jan 2020 07:39:23 -
@@ -4,18 +4,19 @@ COMMENT = open source MPI-3.1 implement

 V =4.0.2
 DISTNAME = openmpi-$V
+REVISION = 0

-SHARED_LIBS +=  mca_common_dstore 0.0 # 1.0
+SHARED_LIBS +=  mca_common_dstore 0.0 # 1.1
 SHARED_LIBS +=  mca_common_monitoring 0.0 # 60.0
-SHARED_LIBS +=  mca_common_ompio  0.0 # 60.1
+SHARED_LIBS +=  mca_common_ompio  0.0 # 60.2
 SHARED_LIBS +=  mca_common_sm 2.0 # 60.0
-SHARED_LIBS +=  mpi   1.0 # 60.1
-SHARED_LIBS +=  mpi_mpifh 0.0 # 60.1
+SHARED_LIBS +=  mpi   2.0 # 60.2
+SHARED_LIBS +=  mpi_mpifh 0.0 # 60.2
 SHARED_LIBS +=  mpi_usempi_ignore_tkr 0.0 # 60.0
-SHARED_LIBS +=  mpi_usempif08 0.0 # 60.0
+SHARED_LIBS +=  mpi_usempif08 0.0 # 60.1
 SHARED_LIBS +=  ompitrace 0.0 # 60.0
-SHARED_LIBS +=  open-pal  1.0 # 60.1
-SHARED_LIBS +=  open-rte  1.0 # 60.1
+SHARED_LIBS +=  open-pal  2.0 # 60.2
+SHARED_LIBS +=  open-rte  2.0 # 60.2

 CATEGORIES =   devel

@@ -30,11 +31,19 @@ WANTLIB += c execinfo m pciaccess pthrea

 MASTER_SITES
=   
${HOMEPAGE}/software/ompi/v${V:C/^([0-9]+\.[0-9]+).*/\1/}/downloads/

-COMPILER = base-clang ports-gcc
+COMPILER = ports-gcc
+
+# MODULES=fortran always uses ports-gcc (and overrides COMPILER)
+# the openmpi applications and libraries will be built with ports-gcc, 
but

+# are compatible with base-clang on archs where it is available
 MODULES =  fortran
 MODFORTRAN_COMPILER =  gfortran
 BUILD_DEPENDS =devel/libtool,-ltdl
 LIB_DEPENDS =  devel/libexecinfo
+
+CONFIGURE_ARGS +=  --enable-mpi-fortran=usempif08 \
+   FC=egfortran \
+   CC=egcc

 MAKE_FLAGS =   V=1
 FAKE_FLAGS =   sysconfdir=${PREFIX}/share/examples/openmpi/
Index: pkg/PLIST
===
RCS file: /cvs/ports/devel/openmpi/pkg/PLIST,v
retrieving revision 1.6
diff -u -p -u -p -r1.6 PLIST
--- pkg/PLIST   22 Dec 2019 15:47:36 -  1.6
+++ pkg/PLIST   27 Jan 2020 07:39:23 -
@@ -41,37 +41,37 @@ include/openmpi/mpiext/mpiext_cuda_c.h
 include/openmpi/mpiext/mpiext_pcollreq_c.h
 include/openmpi/mpiext/mpiext_pcollreq_mpifh.h
 include/openmpi/mpiext/pmp

Re: devel/openmpi mpifort error; compiler

[Martin Reindl]

[CCing Dave Raymond who helped with the openmpi-4.0.1 update]

On Sun, Jan 26, 2020 at 09:21:30AM -0700, j...@bitminer.ca wrote:
> Hi Martin,
> 
> I don't know how to compare the libraries (md5?).  I reviewed the
> build logs and diff'd the text files (.h).  The build logs showed
> the same compilers (gnu) was used to create mpi binaries and
> libraries.  The .h files had no differences.

Please have a look at
https://www.openbsd.org/faq/ports/specialtopics.html#SharedLibs
 
> Reviewing the source
> is what convinced me that FC (and CC) were used only in
> defining the compiler name used by mpicc and mpifort commands.
> 
> And the default cc compiler has changed to egcc as intended:
> 
> 
> o67snap$ mpicc -v
> Using built-in specs.
> COLLECT_GCC=/usr/local/bin/egcc
> COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/x86_64-unknown-openbsd6.6/8.3.0/lto-wrapper
> ...etc etc.
> 
> 
> Now as for C++, it's likely that the clang C++ compiler is to be
> preferred by users (on AMD64) as all C++ ports are built with that.
> OpenMPI has no C++ API and C++ code therefore uses the C interface.
> And that works (I tried a couple of open-source codes to verify). By
> "works" I mean it compiles and runs using clang C++ and linked with
> the gcc-built OpenMPI.  (https://ascl.net/1911.001 PLAN, and
> https://ascl.net/1511.022 ZInCo).
> 

Thanks for the feedback, I've decided to put everything in a single diff
and tested these changes now:

- reenable fortran support
- switch COMPILER to ports-gcc only, due to limitations in the
  build system, MODULES=fortran requires ports-gcc anyway. If problems
  with C++ ever show up, we might make a version with fortran disabled
  and base-clang only. For compiling mpi applications, base-clang
  is still an option as you have showed.
- adjust SHARED_LIBS accordingly, add @so lib markers while there
- add your README, amended by an example code to have everything at
  hand to run a simple mpi program

I think this reflects reality best and I would like to commit this soon :)

-m


Index: Makefile
===
RCS file: /cvs/ports/devel/openmpi/Makefile,v
retrieving revision 1.29
diff -u -p -u -p -r1.29 Makefile
--- Makefile22 Dec 2019 15:47:35 -  1.29
+++ Makefile27 Jan 2020 07:39:23 -
@@ -4,18 +4,19 @@ COMMENT = open source MPI-3.1 implement
 
 V =4.0.2
 DISTNAME = openmpi-$V
+REVISION = 0
 
-SHARED_LIBS +=  mca_common_dstore 0.0 # 1.0
+SHARED_LIBS +=  mca_common_dstore 0.0 # 1.1
 SHARED_LIBS +=  mca_common_monitoring 0.0 # 60.0
-SHARED_LIBS +=  mca_common_ompio  0.0 # 60.1
+SHARED_LIBS +=  mca_common_ompio  0.0 # 60.2
 SHARED_LIBS +=  mca_common_sm 2.0 # 60.0
-SHARED_LIBS +=  mpi   1.0 # 60.1
-SHARED_LIBS +=  mpi_mpifh 0.0 # 60.1
+SHARED_LIBS +=  mpi   2.0 # 60.2
+SHARED_LIBS +=  mpi_mpifh 0.0 # 60.2
 SHARED_LIBS +=  mpi_usempi_ignore_tkr 0.0 # 60.0
-SHARED_LIBS +=  mpi_usempif08 0.0 # 60.0
+SHARED_LIBS +=  mpi_usempif08 0.0 # 60.1
 SHARED_LIBS +=  ompitrace 0.0 # 60.0
-SHARED_LIBS +=  open-pal  1.0 # 60.1
-SHARED_LIBS +=  open-rte  1.0 # 60.1
+SHARED_LIBS +=  open-pal  2.0 # 60.2
+SHARED_LIBS +=  open-rte  2.0 # 60.2
 
 CATEGORIES =   devel
 
@@ -30,11 +31,19 @@ WANTLIB += c execinfo m pciaccess pthrea
 
 MASTER_SITES = 
${HOMEPAGE}/software/ompi/v${V:C/^([0-9]+\.[0-9]+).*/\1/}/downloads/
 
-COMPILER = base-clang ports-gcc
+COMPILER = ports-gcc
+
+# MODULES=fortran always uses ports-gcc (and overrides COMPILER)
+# the openmpi applications and libraries will be built with ports-gcc, but
+# are compatible with base-clang on archs where it is available
 MODULES =  fortran
 MODFORTRAN_COMPILER =  gfortran
 BUILD_DEPENDS =devel/libtool,-ltdl
 LIB_DEPENDS =  devel/libexecinfo
+
+CONFIGURE_ARGS +=  --enable-mpi-fortran=usempif08 \
+   FC=egfortran \
+   CC=egcc
 
 MAKE_FLAGS =   V=1
 FAKE_FLAGS =   sysconfdir=${PREFIX}/share/examples/openmpi/
Index: pkg/PLIST
===
RCS file: /cvs/ports/devel/openmpi/pkg/PLIST,v
retrieving revision 1.6
diff -u -p -u -p -r1.6 PLIST
--- pkg/PLIST   22 Dec 2019 15:47:36 -  1.6
+++ pkg/PLIST   27 Jan 2020 07:39:23 -
@@ -41,37 +41,37 @@ include/openmpi/mpiext/mpiext_cuda_c.h
 include/openmpi/mpiext/mpiext_pcollreq_c.h
 include/openmpi/mpiext/mpiext_pcollreq_mpifh.h
 include/openmpi/mpiext/pmpiext_pcollreq_c.h
-lib/libmca_common_dstore.a
+@static-lib lib/libmca_common_dstore.a
 lib/libmca_common_dstore.la
 @lib lib/libmca_common_dstore.so.${

Re: devel/openmpi mpifort error; compiler

[j]

Hi Martin,

I don't know how to compare the libraries (md5?).  I reviewed the
build logs and diff'd the text files (.h).  The build logs showed
the same compilers (gnu) was used to create mpi binaries and
libraries.  The .h files had no differences.

Reviewing the source
is what convinced me that FC (and CC) were used only in
defining the compiler name used by mpicc and mpifort commands.

And the default cc compiler has changed to egcc as intended:


o67snap$ mpicc -v
Using built-in specs.
COLLECT_GCC=/usr/local/bin/egcc
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/x86_64-unknown-openbsd6.6/8.3.0/lto-wrapper
...etc etc.


Now as for C++, it's likely that the clang C++ compiler is to be
preferred by users (on AMD64) as all C++ ports are built with that.
OpenMPI has no C++ API and C++ code therefore uses the C interface.
And that works (I tried a couple of open-source codes to verify). By
"works" I mean it compiles and runs using clang C++ and linked with
the gcc-built OpenMPI.  (https://ascl.net/1911.001 PLAN, and
https://ascl.net/1511.022 ZInCo).


cheers

--John


On 2020-01-26 03:05, Martin Reindl wrote:

Hi John,

Did you check the libraries for changes?
I will see if I can find time to commit just the fortran bits tonight.
Then I will look at the CC and README additions.

Thanks for the effort to improve the openmpi port!

-m

Am 25.01.20 um 00:17 schrieb j...@bitminer.ca:

Hi Martin,

I have added the CC definition and rebuilt with your other patches
and it works OK on AMD64.


John



Ensure openmpi mpicc and mpifort use GNU compilers

Index: Makefile
===
RCS file: /cvs/ports/devel/openmpi/Makefile,v
retrieving revision 1.29
diff -u -p -r1.29 Makefile
--- Makefile22 Dec 2019 15:47:35 -  1.29
+++ Makefile24 Jan 2020 23:09:17 -
@@ -4,18 +4,19 @@ COMMENT = open source MPI-3.1 implement

 V =4.0.2
 DISTNAME = openmpi-$V
+REVISION = 0

-SHARED_LIBS +=  mca_common_dstore 0.0 # 1.0
+SHARED_LIBS +=  mca_common_dstore 0.0 # 1.1
 SHARED_LIBS +=  mca_common_monitoring 0.0 # 60.0
-SHARED_LIBS +=  mca_common_ompio  0.0 # 60.1
+SHARED_LIBS +=  mca_common_ompio  0.0 # 60.2
 SHARED_LIBS +=  mca_common_sm 2.0 # 60.0
-SHARED_LIBS +=  mpi   1.0 # 60.1
-SHARED_LIBS +=  mpi_mpifh 0.0 # 60.1
+SHARED_LIBS +=  mpi   1.0 # 60.2
+SHARED_LIBS +=  mpi_mpifh 0.0 # 60.2
 SHARED_LIBS +=  mpi_usempi_ignore_tkr 0.0 # 60.0
-SHARED_LIBS +=  mpi_usempif08 0.0 # 60.0
+SHARED_LIBS +=  mpi_usempif08 0.0 # 60.1
 SHARED_LIBS +=  ompitrace 0.0 # 60.0
-SHARED_LIBS +=  open-pal  1.0 # 60.1
-SHARED_LIBS +=  open-rte  1.0 # 60.1
+SHARED_LIBS +=  open-pal  1.1 # 60.2
+SHARED_LIBS +=  open-rte  1.1 # 60.2

 CATEGORIES =   devel

@@ -31,10 +32,18 @@ WANTLIB += c execinfo m pciaccess pthrea
 MASTER_SITES 
=		${HOMEPAGE}/software/ompi/v${V:C/^([0-9]+\.[0-9]+).*/\1/}/downloads/


 COMPILER = base-clang ports-gcc
+
+# MODULES=fortran always uses ports-gcc (and overrides COMPILER)
+# the openmpi application and libraries will be built with ports-gcc, 
but

+# are compatible with base-clang on archs where it is available
 MODULES =  fortran
 MODFORTRAN_COMPILER =  gfortran
 BUILD_DEPENDS =devel/libtool,-ltdl
 LIB_DEPENDS =  devel/libexecinfo
+
+CONFIGURE_ARGS +=  --enable-mpi-fortran=usempif08 \
+   FC=egfortran \
+   CC=egcc

 MAKE_FLAGS =   V=1
 FAKE_FLAGS =   sysconfdir=${PREFIX}/share/examples/openmpi/
Index: pkg/PLIST
===
RCS file: /cvs/ports/devel/openmpi/pkg/PLIST,v
retrieving revision 1.6
diff -u -p -r1.6 PLIST
--- pkg/PLIST   22 Dec 2019 15:47:36 -  1.6
+++ pkg/PLIST   24 Jan 2020 23:09:17 -
@@ -41,37 +41,37 @@ include/openmpi/mpiext/mpiext_cuda_c.h
 include/openmpi/mpiext/mpiext_pcollreq_c.h
 include/openmpi/mpiext/mpiext_pcollreq_mpifh.h
 include/openmpi/mpiext/pmpiext_pcollreq_c.h
-lib/libmca_common_dstore.a
+@static-lib lib/libmca_common_dstore.a
 lib/libmca_common_dstore.la
 @lib lib/libmca_common_dstore.so.${LIBmca_common_dstore_VERSION}
-lib/libmca_common_monitoring.a
+@static-lib lib/libmca_common_monitoring.a
 lib/libmca_common_monitoring.la
 @lib 
lib/libmca_common_monitoring.so.${LIBmca_common_monitoring_VERSION}

-lib/libmca_common_ompio.a
+@static-lib lib/libmca_common_ompio.a
 lib/libmca_common_ompio.la
 @lib lib/libmca_common_ompio.so.${LIBmca_common_ompio_VERSION}
-lib/libmca_common_sm.a
+@static-lib lib/libmca_common_sm.a
 lib/libmca_common_sm.la
 @lib lib/libmca_common_sm.so.${LIBmca_common_sm_VERSION}
-lib/libmpi.a
+@static-lib lib/libmpi.a
 lib/libmpi.la
 @lib lib/libmpi.so.${L

Re: devel/openmpi mpifort error; compiler

[Martin Reindl]

Hi John,

Did you check the libraries for changes?
I will see if I can find time to commit just the fortran bits tonight.
Then I will look at the CC and README additions.

Thanks for the effort to improve the openmpi port!

-m

Am 25.01.20 um 00:17 schrieb j...@bitminer.ca:
> Hi Martin,
> 
> I have added the CC definition and rebuilt with your other patches
> and it works OK on AMD64.
> 
> 
> John
> 
> 
> 
> Ensure openmpi mpicc and mpifort use GNU compilers
> 
> Index: Makefile
> ===
> RCS file: /cvs/ports/devel/openmpi/Makefile,v
> retrieving revision 1.29
> diff -u -p -r1.29 Makefile
> --- Makefile  22 Dec 2019 15:47:35 -  1.29
> +++ Makefile  24 Jan 2020 23:09:17 -
> @@ -4,18 +4,19 @@ COMMENT =   open source MPI-3.1 implement
>  
>  V =  4.0.2
>  DISTNAME =   openmpi-$V
> +REVISION =   0
>  
> -SHARED_LIBS +=  mca_common_dstore 0.0 # 1.0
> +SHARED_LIBS +=  mca_common_dstore 0.0 # 1.1
>  SHARED_LIBS +=  mca_common_monitoring 0.0 # 60.0
> -SHARED_LIBS +=  mca_common_ompio  0.0 # 60.1
> +SHARED_LIBS +=  mca_common_ompio  0.0 # 60.2
>  SHARED_LIBS +=  mca_common_sm 2.0 # 60.0
> -SHARED_LIBS +=  mpi   1.0 # 60.1
> -SHARED_LIBS +=  mpi_mpifh 0.0 # 60.1
> +SHARED_LIBS +=  mpi   1.0 # 60.2
> +SHARED_LIBS +=  mpi_mpifh 0.0 # 60.2
>  SHARED_LIBS +=  mpi_usempi_ignore_tkr 0.0 # 60.0
> -SHARED_LIBS +=  mpi_usempif08 0.0 # 60.0
> +SHARED_LIBS +=  mpi_usempif08 0.0 # 60.1
>  SHARED_LIBS +=  ompitrace 0.0 # 60.0
> -SHARED_LIBS +=  open-pal  1.0 # 60.1
> -SHARED_LIBS +=  open-rte  1.0 # 60.1
> +SHARED_LIBS +=  open-pal  1.1 # 60.2
> +SHARED_LIBS +=  open-rte  1.1 # 60.2
>  
>  CATEGORIES = devel
>  
> @@ -31,10 +32,18 @@ WANTLIB += c execinfo m pciaccess pthrea
>  MASTER_SITES =   
> ${HOMEPAGE}/software/ompi/v${V:C/^([0-9]+\.[0-9]+).*/\1/}/downloads/
>  
>  COMPILER =   base-clang ports-gcc
> +
> +# MODULES=fortran always uses ports-gcc (and overrides COMPILER)
> +# the openmpi application and libraries will be built with ports-gcc, but
> +# are compatible with base-clang on archs where it is available
>  MODULES =fortran
>  MODFORTRAN_COMPILER =gfortran
>  BUILD_DEPENDS =  devel/libtool,-ltdl
>  LIB_DEPENDS =devel/libexecinfo
> +
> +CONFIGURE_ARGS +=--enable-mpi-fortran=usempif08 \
> + FC=egfortran \
> + CC=egcc
>  
>  MAKE_FLAGS = V=1
>  FAKE_FLAGS = sysconfdir=${PREFIX}/share/examples/openmpi/
> Index: pkg/PLIST
> ===
> RCS file: /cvs/ports/devel/openmpi/pkg/PLIST,v
> retrieving revision 1.6
> diff -u -p -r1.6 PLIST
> --- pkg/PLIST 22 Dec 2019 15:47:36 -  1.6
> +++ pkg/PLIST 24 Jan 2020 23:09:17 -
> @@ -41,37 +41,37 @@ include/openmpi/mpiext/mpiext_cuda_c.h
>  include/openmpi/mpiext/mpiext_pcollreq_c.h
>  include/openmpi/mpiext/mpiext_pcollreq_mpifh.h
>  include/openmpi/mpiext/pmpiext_pcollreq_c.h
> -lib/libmca_common_dstore.a
> +@static-lib lib/libmca_common_dstore.a
>  lib/libmca_common_dstore.la
>  @lib lib/libmca_common_dstore.so.${LIBmca_common_dstore_VERSION}
> -lib/libmca_common_monitoring.a
> +@static-lib lib/libmca_common_monitoring.a
>  lib/libmca_common_monitoring.la
>  @lib lib/libmca_common_monitoring.so.${LIBmca_common_monitoring_VERSION}
> -lib/libmca_common_ompio.a
> +@static-lib lib/libmca_common_ompio.a
>  lib/libmca_common_ompio.la
>  @lib lib/libmca_common_ompio.so.${LIBmca_common_ompio_VERSION}
> -lib/libmca_common_sm.a
> +@static-lib lib/libmca_common_sm.a
>  lib/libmca_common_sm.la
>  @lib lib/libmca_common_sm.so.${LIBmca_common_sm_VERSION}
> -lib/libmpi.a
> +@static-lib lib/libmpi.a
>  lib/libmpi.la
>  @lib lib/libmpi.so.${LIBmpi_VERSION}
> -lib/libmpi_mpifh.a
> +@static-lib lib/libmpi_mpifh.a
>  lib/libmpi_mpifh.la
>  @lib lib/libmpi_mpifh.so.${LIBmpi_mpifh_VERSION}
> -lib/libmpi_usempi_ignore_tkr.a
> +@static-lib lib/libmpi_usempi_ignore_tkr.a
>  lib/libmpi_usempi_ignore_tkr.la
>  @lib lib/libmpi_usempi_ignore_tkr.so.${LIBmpi_usempi_ignore_tkr_VERSION}
> -lib/libmpi_usempif08.a
> +@static-lib lib/libmpi_usempif08.a
>  lib/libmpi_usempif08.la
>  @lib lib/libmpi_usempif08.so.${LIBmpi_usempif08_VERSION}
> -lib/libompitrace.a
> +@static-lib lib/libompitrace.a
>  lib/libompitrace.la
>  @lib lib/libompitrace.so.${LIBompitrace_VERSION}
> -lib/libopen-pal.a
> +@static-lib lib/libopen-pal.a
>  lib/libopen-pal.la
>  @lib lib/libopen-pal.so.${LIBopen-pal_VERSION}
> -lib/libopen-rte.a
> +@static-lib lib/libopen-rte.a
>  lib/libopen-rte.la
>  @lib lib/libopen-rte.so.${LIBopen-rte_VERSION}
>  lib/mpi.mod
> @@ -84,288 +84,288 @@ lib/mpi_f08_interfaces_callba

Re: devel/openmpi mpifort error; compiler

[j]

Hi Martin,

I have added the CC definition and rebuilt with your other patches
and it works OK on AMD64.


John



Ensure openmpi mpicc and mpifort use GNU compilers

Index: Makefile
===
RCS file: /cvs/ports/devel/openmpi/Makefile,v
retrieving revision 1.29
diff -u -p -r1.29 Makefile
--- Makefile22 Dec 2019 15:47:35 -  1.29
+++ Makefile24 Jan 2020 23:09:17 -
@@ -4,18 +4,19 @@ COMMENT = open source MPI-3.1 implement
 
 V =4.0.2
 DISTNAME = openmpi-$V
+REVISION = 0
 
-SHARED_LIBS +=  mca_common_dstore 0.0 # 1.0
+SHARED_LIBS +=  mca_common_dstore 0.0 # 1.1
 SHARED_LIBS +=  mca_common_monitoring 0.0 # 60.0
-SHARED_LIBS +=  mca_common_ompio  0.0 # 60.1
+SHARED_LIBS +=  mca_common_ompio  0.0 # 60.2
 SHARED_LIBS +=  mca_common_sm 2.0 # 60.0
-SHARED_LIBS +=  mpi   1.0 # 60.1
-SHARED_LIBS +=  mpi_mpifh 0.0 # 60.1
+SHARED_LIBS +=  mpi   1.0 # 60.2
+SHARED_LIBS +=  mpi_mpifh 0.0 # 60.2
 SHARED_LIBS +=  mpi_usempi_ignore_tkr 0.0 # 60.0
-SHARED_LIBS +=  mpi_usempif08 0.0 # 60.0
+SHARED_LIBS +=  mpi_usempif08 0.0 # 60.1
 SHARED_LIBS +=  ompitrace 0.0 # 60.0
-SHARED_LIBS +=  open-pal  1.0 # 60.1
-SHARED_LIBS +=  open-rte  1.0 # 60.1
+SHARED_LIBS +=  open-pal  1.1 # 60.2
+SHARED_LIBS +=  open-rte  1.1 # 60.2
 
 CATEGORIES =   devel
 
@@ -31,10 +32,18 @@ WANTLIB += c execinfo m pciaccess pthrea
 MASTER_SITES = 
${HOMEPAGE}/software/ompi/v${V:C/^([0-9]+\.[0-9]+).*/\1/}/downloads/
 
 COMPILER = base-clang ports-gcc
+
+# MODULES=fortran always uses ports-gcc (and overrides COMPILER)
+# the openmpi application and libraries will be built with ports-gcc, but
+# are compatible with base-clang on archs where it is available
 MODULES =  fortran
 MODFORTRAN_COMPILER =  gfortran
 BUILD_DEPENDS =devel/libtool,-ltdl
 LIB_DEPENDS =  devel/libexecinfo
+
+CONFIGURE_ARGS +=  --enable-mpi-fortran=usempif08 \
+   FC=egfortran \
+   CC=egcc
 
 MAKE_FLAGS =   V=1
 FAKE_FLAGS =   sysconfdir=${PREFIX}/share/examples/openmpi/
Index: pkg/PLIST
===
RCS file: /cvs/ports/devel/openmpi/pkg/PLIST,v
retrieving revision 1.6
diff -u -p -r1.6 PLIST
--- pkg/PLIST   22 Dec 2019 15:47:36 -  1.6
+++ pkg/PLIST   24 Jan 2020 23:09:17 -
@@ -41,37 +41,37 @@ include/openmpi/mpiext/mpiext_cuda_c.h
 include/openmpi/mpiext/mpiext_pcollreq_c.h
 include/openmpi/mpiext/mpiext_pcollreq_mpifh.h
 include/openmpi/mpiext/pmpiext_pcollreq_c.h
-lib/libmca_common_dstore.a
+@static-lib lib/libmca_common_dstore.a
 lib/libmca_common_dstore.la
 @lib lib/libmca_common_dstore.so.${LIBmca_common_dstore_VERSION}
-lib/libmca_common_monitoring.a
+@static-lib lib/libmca_common_monitoring.a
 lib/libmca_common_monitoring.la
 @lib lib/libmca_common_monitoring.so.${LIBmca_common_monitoring_VERSION}
-lib/libmca_common_ompio.a
+@static-lib lib/libmca_common_ompio.a
 lib/libmca_common_ompio.la
 @lib lib/libmca_common_ompio.so.${LIBmca_common_ompio_VERSION}
-lib/libmca_common_sm.a
+@static-lib lib/libmca_common_sm.a
 lib/libmca_common_sm.la
 @lib lib/libmca_common_sm.so.${LIBmca_common_sm_VERSION}
-lib/libmpi.a
+@static-lib lib/libmpi.a
 lib/libmpi.la
 @lib lib/libmpi.so.${LIBmpi_VERSION}
-lib/libmpi_mpifh.a
+@static-lib lib/libmpi_mpifh.a
 lib/libmpi_mpifh.la
 @lib lib/libmpi_mpifh.so.${LIBmpi_mpifh_VERSION}
-lib/libmpi_usempi_ignore_tkr.a
+@static-lib lib/libmpi_usempi_ignore_tkr.a
 lib/libmpi_usempi_ignore_tkr.la
 @lib lib/libmpi_usempi_ignore_tkr.so.${LIBmpi_usempi_ignore_tkr_VERSION}
-lib/libmpi_usempif08.a
+@static-lib lib/libmpi_usempif08.a
 lib/libmpi_usempif08.la
 @lib lib/libmpi_usempif08.so.${LIBmpi_usempif08_VERSION}
-lib/libompitrace.a
+@static-lib lib/libompitrace.a
 lib/libompitrace.la
 @lib lib/libompitrace.so.${LIBompitrace_VERSION}
-lib/libopen-pal.a
+@static-lib lib/libopen-pal.a
 lib/libopen-pal.la
 @lib lib/libopen-pal.so.${LIBopen-pal_VERSION}
-lib/libopen-rte.a
+@static-lib lib/libopen-rte.a
 lib/libopen-rte.la
 @lib lib/libopen-rte.so.${LIBopen-rte_VERSION}
 lib/mpi.mod
@@ -84,288 +84,288 @@ lib/mpi_f08_interfaces_callbacks.mod
 lib/mpi_f08_types.mod
 lib/ompi_monitoring_prof.a
 lib/ompi_monitoring_prof.la
-lib/ompi_monitoring_prof.so
+@so lib/ompi_monitoring_prof.so
 lib/openmpi/
-lib/openmpi/libompi_dbg_msgq.a
+@static-lib lib/openmpi/libompi_dbg_msgq.a
 lib/openmpi/libompi_dbg_msgq.la
-lib/openmpi/libompi_dbg_msgq.so
+@so lib/openmpi/libompi_dbg_msgq.so
 lib/openmpi/mca_allocator_basic.a
 lib/openmpi/mca_allocator_basic.la
-lib/openmpi/mca_allocator_basic.so
+@so lib/openmpi/mca_allocator_basic.so
 lib/openmpi/mc

Re: devel/openmpi mpifort error; compiler

[j]

Hi Martin,


On 2020-01-22 03:07, Martin Reindl wrote:

On Tue, Jan 21, 2020 at 01:20:29PM -0700, j...@bitminer.ca wrote:





[]


Hi John, Hi Stuart,

I've got around to testing this now a bit more:

- Currently, the port does not use flang. It used to before the update 
to
  openmpi-4.0.1. So every Fortran feature in the current state depends 
solely

  on gcc8 from ports-gcc
- Strictly speaking the COMPILER line is there for archs where there is 
no
  clang in base and base-gcc is too old. This gives archs like macppc 
and

  sparc64 a chance to compile and run openmpi
- with MODULES=fortran on a base-clang archs we now have the situation 
that we
  build the openmpi binaries and librariers with ports-gcc but at 
runtime we

  use base-clang:

  $ mpicc -v
  OpenBSD clang version 8.0.1 (tags/RELEASE_801/final) (based on LLVM 
8.0.1)


  for Fortran with Johns diff it's ports-gcc as usual:
  $ mpifort -v
  [...]
  gcc version 8.3.0 (GCC)


It occurs to me that the same approach for FC would apply to CC.
The value of CC=egcc is used to substitute in the mpicc command.

With that, mpicc and mpifort would both use ports-gcc.  Anyone
wanting clang can use "$ OMPI_CC=clang mpicc ."

This avoids the confusing use of two distinct compiler origins
with OpenMPI build commands.

[]

I've tested the folling diff and checked the libraries for changes with 
the
help of shared_libs.log. libopen-pal only has adress changes and 
libopen-rte
as a tiny symbol name changed - hence the minor bump. I've also fixed 
the
orig version in the comments for the other libraries and sprinkled some 
@lib

markers in the PLIST while there.


I build this as you described and it works for me on amd64.


cheers

--John

Re: devel/openmpi mpifort error; compiler

[j]

Hi Stuart,

On 2020-01-22 09:31, Stuart Henderson wrote:

On 2020/01/22 09:24, j...@bitminer.ca wrote:

The mixing of gcc-built code with clang "runtime" is not really
such a big deal on AMD64.


I know very little about openmpi but it looks like you're intending 
this
as a general statement. For C code it's not a problem. For C++ code 
it's

a big problem because the standard libraries conflict.


True -- I should have qualified the sentence "when using C and often
when using C++".

OpenMPI provides a C library, not C++.  So any[*] C++ source code
can be built with OpenMPI, with either compiler, provided any other
prerequisites are also available. OpenMPI people deprecated
their C++ interface long ago.

Much of this info exceeds the typical scope of documentation; I have
some web pages in progress that I hope to publish soon (once I
figure out github pages).

Perhaps the OpenMPI port needs an OpenBSD-specific set of guidelines
(e.g. useful runtime environment variables, compiling guidance, etc).



[*] In principle, although I haven't tried many.

Re: devel/openmpi mpifort error; compiler

[Stuart Henderson]

On 2020/01/22 09:24, j...@bitminer.ca wrote:
> The mixing of gcc-built code with clang "runtime" is not really
> such a big deal on AMD64.

I know very little about openmpi but it looks like you're intending this
as a general statement. For C code it's not a problem. For C++ code it's
a big problem because the standard libraries conflict.

Re: devel/openmpi mpifort error; compiler

[j]

Hi Martin,


On 2020-01-22 03:07, Martin Reindl wrote:

On Tue, Jan 21, 2020 at 01:20:29PM -0700, j...@bitminer.ca wrote:



On 2020-01-21 12:45, Martin Reindl wrote:
> Am 20.01.20 um 22:55 schrieb j...@bitminer.ca:
> > This fixes the mpifort command which can't find egfortran.
> >
> > I also propose removing COMPILER = base-clang since this compiles
> > with gcc anyway.  GCC also has some advantages for us fortran
> > users (coarray fortran).
>
> Hello John,
>
> - OK for the CONFIGURE_ARGS fortran bits, thanks for spotting!
> - REVISION should start at 0

Ahh, the perils of porting infrequently.  Good point.

> - egfortran actually is the one from ports-gcc (8.3.0), I don't see the
> point replacing base clang 8.0.1 if you need coarray fortran?

On AMD64, OpenMPI compiles with ports-gcc anyway, hence my notion
to avoid confusion by naming the one compiler:



===>  Checking files for openmpi-4.0.2p1
`/usr/distfiles/openmpi-4.0.2.tar.gz' is up to date.
> > (SHA256) openmpi-4.0.2.tar.gz: OK
===> openmpi-4.0.2p1 depends on: libltdl-* -> libltdl-2.4.2p1
===> openmpi-4.0.2p1 depends on: gcc->=8,<9 -> gcc-8.3.0p4
etc etc

Once built (using ports-gcc egcc and egfortran), then OpenMPI is
compatible with clang but not flang because the two Fortrans
have different array implementations (max rank=15 on egfortran
versus merely 8 or 9 on flang, and OpenMPI notices.)

The GCC gfortran compiler supports co-arrays but flang does
not, to my knowledge.  The coarrays lib is a very simple
port that I should post.



Hi John, Hi Stuart,

I've got around to testing this now a bit more:

- Currently, the port does not use flang. It used to before the update 
to
  openmpi-4.0.1. So every Fortran feature in the current state depends 
solely

  on gcc8 from ports-gcc
- Strictly speaking the COMPILER line is there for archs where there is 
no
  clang in base and base-gcc is too old. This gives archs like macppc 
and

  sparc64 a chance to compile and run openmpi
- with MODULES=fortran on a base-clang archs we now have the situation 
that we
  build the openmpi binaries and librariers with ports-gcc but at 
runtime we

  use base-clang:


(I think you mean at compile-time).



  $ mpicc -v
  OpenBSD clang version 8.0.1 (tags/RELEASE_801/final) (based on LLVM 
8.0.1)


Actually, compiling with clang is optional:

$ mpicc -v
OpenBSD clang version 8.0.1 (tags/RELEASE_801/final) (based on LLVM 
8.0.1)

[...]

$ OMPI_CC=egcc mpicc -v
Using built-in specs.
COLLECT_GCC=/usr/local/bin/egcc
[...] etc

The mixing of gcc-built code with clang "runtime" is not really
such a big deal on AMD64. The whole operating system is built with
clang.  Clang-compiled OpenMPI user code runs fine with the gcc-built
OpenMPI.  It's just flang-compiled OpenMPI user code that doesn't
work and I personally think the gfortran alternative is better,
as stated.


--John







  for Fortran with Johns diff it's ports-gcc as usual:
  $ mpifort -v
  [...]
  gcc version 8.3.0 (GCC)

We could use ports-gcc only but I am not sure what produces a more 
coherent
system on a base-clang arch where openmpi seems to be most likely to be 
useful

(meaning amd64 and arm64, mostly).

A possibility would be to split up the port:

a base-clang only version:
- Fortran disabled
- coherent on all base-clang archs
a ports-gcc version:
- Fortran enabled
- also available where there is no base-clang
	- possibly less coherent because mixing of libraries (as Stuart 
pointed)

  out


For a small userbase, this is probably too much work (and too difficult
to answer questions about "which should I use?").




For now I would keep base-clang, but given the small userbase it might 
be worth

to really just keep a ports-gcc version.

I've tested the folling diff and checked the libraries for changes with 
the
help of shared_libs.log. libopen-pal only has adress changes and 
libopen-rte
as a tiny symbol name changed - hence the minor bump. I've also fixed 
the
orig version in the comments for the other libraries and sprinkled some 
@lib

markers in the PLIST while there.

-m



cheers

--John

PS - question: has anyone ever tried to vet the lengthy list of shared 
libs
and tried to prune it?  Seems like a few might still be unnecessary on 
OpenBSD.

Re: devel/openmpi mpifort error; compiler

[Martin Reindl]

On Wed, Jan 22, 2020 at 10:20:10AM +, Stuart Henderson wrote:
> On 2020/01/22 11:07, Martin Reindl wrote:
> > I've tested the folling diff and checked the libraries for changes with the
> > help of shared_libs.log. libopen-pal only has adress changes and libopen-rte
> > as a tiny symbol name changed - hence the minor bump. I've also fixed the 
> > orig version in the comments for the other libraries and sprinkled some @lib
> > markers in the PLIST while there.
> 
> I can't think about the fortran/gcc/clang bits at the moment but a quick 
> comment
> on this, "symbol name changed" sounds like "1 removed 1 added" which is a 
> major bump.

On closer inspection only adress changes - my bad:

--- /tmp/old-open-rte.so.1.0Wed Jan 22 08:28:42 2020
+++ /tmp/new-open-rte.so.1.0Wed Jan 22 08:28:42 2020
@@ -1,5 +1,5 @@
-0002c820 r CSWTCH.50
-0002c5c0 r CSWTCH.99
+0002c860 r CSWTCH.50
+0002c600 r CSWTCH.99
 000af9d0 T MPIR_Breakpoint
 000be700 B MPIR_attach_fifo
 000bef28 B MPIR_being_debugged
@@ -1332,7 +1332,7 @@
 00049680 T orte_util_print_vpids
 000498a0 T orte_util_snprintf_jobid
 00057eb0 T orte_util_uncompress_block
-0002cd9c R orte_version_string
+0002cddc R orte_version_string
  F orte_wait.c
 00045850 T orte_wait_cb
 00045b10 T orte_wait_cb_cancel
@@ -1628,22 +1628,22 @@
 000a3670 t write_help_msg
 0009f670 t xfer_cons
 0004b5e0 t xml_format
-0002a680 r yy_accept
-00029fc0 r yy_base
+0002a6c0 r yy_accept
+0002a000 r yy_base
 000bd620 b yy_buffer_stack
 000bd628 b yy_buffer_stack_max
 000bd630 b yy_buffer_stack_top
 000bd608 b yy_c_buf_p
-00029420 r yy_chk
-00029da0 r yy_def
+00029460 r yy_chk
+00029de0 r yy_def
 000bd5fc b yy_did_buffer_switch_on_eof
-0002a280 r yy_ec
+0002a2c0 r yy_ec
 0004e0e0 t yy_fatal_error
 000bd618 b yy_hold_char
 000bd604 b yy_init
 000bd5f0 b yy_last_accepting_cpos
 000bd5f8 b yy_last_accepting_state
-0002a1e0 r yy_meta
+0002a220 r yy_meta
 000bd610 b yy_n_chars
-000298e0 r yy_nxt
+00029920 r yy_nxt
 000bd600 b yy_start

Re: devel/openmpi mpifort error; compiler

[Stuart Henderson]

On 2020/01/22 11:07, Martin Reindl wrote:
> I've tested the folling diff and checked the libraries for changes with the
> help of shared_libs.log. libopen-pal only has adress changes and libopen-rte
> as a tiny symbol name changed - hence the minor bump. I've also fixed the 
> orig version in the comments for the other libraries and sprinkled some @lib
> markers in the PLIST while there.

I can't think about the fortran/gcc/clang bits at the moment but a quick comment
on this, "symbol name changed" sounds like "1 removed 1 added" which is a major 
bump.

Re: devel/openmpi mpifort error; compiler

[Martin Reindl]

On Tue, Jan 21, 2020 at 01:20:29PM -0700, j...@bitminer.ca wrote:
> 
> 
> On 2020-01-21 12:45, Martin Reindl wrote:
> > Am 20.01.20 um 22:55 schrieb j...@bitminer.ca:
> > > This fixes the mpifort command which can't find egfortran.
> > > 
> > > I also propose removing COMPILER = base-clang since this compiles
> > > with gcc anyway.  GCC also has some advantages for us fortran
> > > users (coarray fortran).
> > 
> > Hello John,
> > 
> > - OK for the CONFIGURE_ARGS fortran bits, thanks for spotting!
> > - REVISION should start at 0
> 
> Ahh, the perils of porting infrequently.  Good point.
> 
> > - egfortran actually is the one from ports-gcc (8.3.0), I don't see the
> > point replacing base clang 8.0.1 if you need coarray fortran?
> 
> On AMD64, OpenMPI compiles with ports-gcc anyway, hence my notion
> to avoid confusion by naming the one compiler:
> 
> 
> 
> ===>  Checking files for openmpi-4.0.2p1
> `/usr/distfiles/openmpi-4.0.2.tar.gz' is up to date.
> > > (SHA256) openmpi-4.0.2.tar.gz: OK
> ===> openmpi-4.0.2p1 depends on: libltdl-* -> libltdl-2.4.2p1
> ===> openmpi-4.0.2p1 depends on: gcc->=8,<9 -> gcc-8.3.0p4
> etc etc
> 
> Once built (using ports-gcc egcc and egfortran), then OpenMPI is
> compatible with clang but not flang because the two Fortrans
> have different array implementations (max rank=15 on egfortran
> versus merely 8 or 9 on flang, and OpenMPI notices.)
> 
> The GCC gfortran compiler supports co-arrays but flang does
> not, to my knowledge.  The coarrays lib is a very simple
> port that I should post.
> 

Hi John, Hi Stuart,

I've got around to testing this now a bit more:

- Currently, the port does not use flang. It used to before the update to
  openmpi-4.0.1. So every Fortran feature in the current state depends solely
  on gcc8 from ports-gcc
- Strictly speaking the COMPILER line is there for archs where there is no
  clang in base and base-gcc is too old. This gives archs like macppc and
  sparc64 a chance to compile and run openmpi
- with MODULES=fortran on a base-clang archs we now have the situation that we
  build the openmpi binaries and librariers with ports-gcc but at runtime we
  use base-clang:

  $ mpicc -v
  OpenBSD clang version 8.0.1 (tags/RELEASE_801/final) (based on LLVM 8.0.1)

  for Fortran with Johns diff it's ports-gcc as usual:
  $ mpifort -v
  [...]
  gcc version 8.3.0 (GCC)

We could use ports-gcc only but I am not sure what produces a more coherent
system on a base-clang arch where openmpi seems to be most likely to be useful
(meaning amd64 and arm64, mostly).

A possibility would be to split up the port:

a base-clang only version:
- Fortran disabled
- coherent on all base-clang archs
a ports-gcc version:
- Fortran enabled
- also available where there is no base-clang
- possibly less coherent because mixing of libraries (as Stuart pointed)
  out

For now I would keep base-clang, but given the small userbase it might be worth
to really just keep a ports-gcc version.

I've tested the folling diff and checked the libraries for changes with the
help of shared_libs.log. libopen-pal only has adress changes and libopen-rte
as a tiny symbol name changed - hence the minor bump. I've also fixed the 
orig version in the comments for the other libraries and sprinkled some @lib
markers in the PLIST while there.

-m


Index: Makefile
===
RCS file: /cvs/ports/devel/openmpi/Makefile,v
retrieving revision 1.29
diff -u -p -u -p -r1.29 Makefile
--- Makefile22 Dec 2019 15:47:35 -  1.29
+++ Makefile22 Jan 2020 09:22:54 -
@@ -4,18 +4,19 @@ COMMENT = open source MPI-3.1 implement
 
 V =4.0.2
 DISTNAME = openmpi-$V
+REVISION = 0
 
-SHARED_LIBS +=  mca_common_dstore 0.0 # 1.0
+SHARED_LIBS +=  mca_common_dstore 0.0 # 1.1
 SHARED_LIBS +=  mca_common_monitoring 0.0 # 60.0
-SHARED_LIBS +=  mca_common_ompio  0.0 # 60.1
+SHARED_LIBS +=  mca_common_ompio  0.0 # 60.2
 SHARED_LIBS +=  mca_common_sm 2.0 # 60.0
-SHARED_LIBS +=  mpi   1.0 # 60.1
-SHARED_LIBS +=  mpi_mpifh 0.0 # 60.1
+SHARED_LIBS +=  mpi   1.0 # 60.2
+SHARED_LIBS +=  mpi_mpifh 0.0 # 60.2
 SHARED_LIBS +=  mpi_usempi_ignore_tkr 0.0 # 60.0
-SHARED_LIBS +=  mpi_usempif08 0.0 # 60.0
+SHARED_LIBS +=  mpi_usempif08 0.0 # 60.1
 SHARED_LIBS +=  ompitrace 0.0 # 60.0
-SHARED_LIBS +=  open-pal  1.0 # 60.1
-SHARED_LIBS +=  open-rte  1.0 # 60.1
+SHARED_LIBS +=  open-pal  1.1 # 60.2
+SHARED_LIBS +=  open-rte  1.1 # 60.2
 
 CATEGORIES =   devel
 
@@ -31,10 +32,17 @@ WANTLIB += c execinfo m pciaccess pthrea
 MASTER_SITES = 
${HOMEPAGE}/software/ompi/v${V:C/^([0-9]+\.[0-9]+).*/\1/}/downloads/
 
 COMPILER = 

Re: devel/openmpi mpifort error; compiler

[j]

On 2020-01-21 12:45, Martin Reindl wrote:

Am 20.01.20 um 22:55 schrieb j...@bitminer.ca:

This fixes the mpifort command which can't find egfortran.

I also propose removing COMPILER = base-clang since this compiles
with gcc anyway.  GCC also has some advantages for us fortran
users (coarray fortran).


Hello John,

- OK for the CONFIGURE_ARGS fortran bits, thanks for spotting!
- REVISION should start at 0


Ahh, the perils of porting infrequently.  Good point.


- egfortran actually is the one from ports-gcc (8.3.0), I don't see the
point replacing base clang 8.0.1 if you need coarray fortran?


On AMD64, OpenMPI compiles with ports-gcc anyway, hence my notion
to avoid confusion by naming the one compiler:



===>  Checking files for openmpi-4.0.2p1
`/usr/distfiles/openmpi-4.0.2.tar.gz' is up to date.

(SHA256) openmpi-4.0.2.tar.gz: OK

===> openmpi-4.0.2p1 depends on: libltdl-* -> libltdl-2.4.2p1
===> openmpi-4.0.2p1 depends on: gcc->=8,<9 -> gcc-8.3.0p4
etc etc

Once built (using ports-gcc egcc and egfortran), then OpenMPI is
compatible with clang but not flang because the two Fortrans
have different array implementations (max rank=15 on egfortran
versus merely 8 or 9 on flang, and OpenMPI notices.)

The GCC gfortran compiler supports co-arrays but flang does
not, to my knowledge.  The coarrays lib is a very simple
port that I should post.

--John




-m



--John

Index: Makefile
===
RCS file: /cvs/ports/devel/openmpi/Makefile,v
retrieving revision 1.29
diff -u -p -r1.29 Makefile
--- Makefile22 Dec 2019 15:47:35 -  1.29
+++ Makefile20 Jan 2020 19:19:35 -
@@ -4,6 +4,7 @@ COMMENT =   open source MPI-3.1 implement

 V =4.0.2
 DISTNAME = openmpi-$V
+REVISION = 1

 SHARED_LIBS +=  mca_common_dstore 0.0 # 1.0
 SHARED_LIBS +=  mca_common_monitoring 0.0 # 60.0
@@ -30,11 +31,14 @@ WANTLIB += c execinfo m pciaccess pthrea

 MASTER_SITES 
=		${HOMEPAGE}/software/ompi/v${V:C/^([0-9]+\.[0-9]+).*/\1/}/downloads/


-COMPILER = base-clang ports-gcc
+COMPILER = ports-gcc
 MODULES =  fortran
 MODFORTRAN_COMPILER =  gfortran
 BUILD_DEPENDS =devel/libtool,-ltdl
 LIB_DEPENDS =  devel/libexecinfo
+
+CONFIGURE_ARGS +=  --enable-mpi-fortran=usempif08
+CONFIGURE_ARGS +=  FC=egfortran

 MAKE_FLAGS =   V=1
 FAKE_FLAGS =   sysconfdir=${PREFIX}/share/examples/openmpi/

Re: devel/openmpi mpifort error; compiler

[Stuart Henderson]

On 2020/01/21 20:45, Martin Reindl wrote:
> Am 20.01.20 um 22:55 schrieb j...@bitminer.ca:
> > This fixes the mpifort command which can't find egfortran.
> > 
> > I also propose removing COMPILER = base-clang since this compiles
> > with gcc anyway.  GCC also has some advantages for us fortran
> > users (coarray fortran).
> 
> Hello John,
> 
> - OK for the CONFIGURE_ARGS fortran bits, thanks for spotting!
> - REVISION should start at 0
> - egfortran actually is the one from ports-gcc (8.3.0), I don't see the
> point replacing base clang 8.0.1 if you need coarray fortran?

COMPILER interacts poorly with the fortran module.

$ make show=CHOSEN_COMPILER
base-clang

Between this and the COMPILER line it suggests it's going to use clang, right?

$ make patch
[...]
===>  Compiler link: gcc -> /usr/local/bin/egcc
===>  Compiler link: cc -> /usr/local/bin/egcc
===>  Compiler link: gfortran -> /usr/local/bin/egfortran
===>  Compiler link: clang -> /usr/bin/clang
===>  Compiler link: clang++ -> /usr/bin/clang++
===>  Compiler link: c++ -> /usr/bin/c++

Wrong...that's (ports-)GCC.

(This also means that if such a port uses the c++ standard library
for some code, and uses or is used by some other library using c++,
the binaries will end up broken..not really sure how to deal with this
though).

> > -COMPILER = base-clang ports-gcc
> > +COMPILER = ports-gcc
> >  MODULES =  fortran
> >  MODFORTRAN_COMPILER =  gfortran

It could say something like this to make it a bit clearer (and leave
out the COMPILER line)..

# MODULES=fortran always uses ports-gcc (and overrides COMPILER)
MODULES =   fortran
MODFORTRAN_COMPILER =   gfortran
[...]

Re: devel/openmpi mpifort error; compiler

[Martin Reindl]

Am 20.01.20 um 22:55 schrieb j...@bitminer.ca:
> This fixes the mpifort command which can't find egfortran.
> 
> I also propose removing COMPILER = base-clang since this compiles
> with gcc anyway.  GCC also has some advantages for us fortran
> users (coarray fortran).

Hello John,

- OK for the CONFIGURE_ARGS fortran bits, thanks for spotting!
- REVISION should start at 0
- egfortran actually is the one from ports-gcc (8.3.0), I don't see the
point replacing base clang 8.0.1 if you need coarray fortran?

-m

> 
> --John
> 
> Index: Makefile
> ===
> RCS file: /cvs/ports/devel/openmpi/Makefile,v
> retrieving revision 1.29
> diff -u -p -r1.29 Makefile
> --- Makefile  22 Dec 2019 15:47:35 -  1.29
> +++ Makefile  20 Jan 2020 19:19:35 -
> @@ -4,6 +4,7 @@ COMMENT = open source MPI-3.1 implement
>  
>  V =  4.0.2
>  DISTNAME =   openmpi-$V
> +REVISION =   1
>  
>  SHARED_LIBS +=  mca_common_dstore 0.0 # 1.0
>  SHARED_LIBS +=  mca_common_monitoring 0.0 # 60.0
> @@ -30,11 +31,14 @@ WANTLIB += c execinfo m pciaccess pthrea
>  
>  MASTER_SITES =   
> ${HOMEPAGE}/software/ompi/v${V:C/^([0-9]+\.[0-9]+).*/\1/}/downloads/
>  
> -COMPILER =   base-clang ports-gcc
> +COMPILER =   ports-gcc
>  MODULES =fortran
>  MODFORTRAN_COMPILER =gfortran
>  BUILD_DEPENDS =  devel/libtool,-ltdl
>  LIB_DEPENDS =devel/libexecinfo
> +
> +CONFIGURE_ARGS +=--enable-mpi-fortran=usempif08
> +CONFIGURE_ARGS +=FC=egfortran
>  
>  MAKE_FLAGS = V=1
>  FAKE_FLAGS = sysconfdir=${PREFIX}/share/examples/openmpi/
> 

devel/openmpi mpifort error; compiler

[j]

This fixes the mpifort command which can't find egfortran.

I also propose removing COMPILER = base-clang since this compiles
with gcc anyway.  GCC also has some advantages for us fortran
users (coarray fortran).


--John

Index: Makefile
===
RCS file: /cvs/ports/devel/openmpi/Makefile,v
retrieving revision 1.29
diff -u -p -r1.29 Makefile
--- Makefile22 Dec 2019 15:47:35 -  1.29
+++ Makefile20 Jan 2020 19:19:35 -
@@ -4,6 +4,7 @@ COMMENT =   open source MPI-3.1 implement
 
 V =4.0.2
 DISTNAME = openmpi-$V
+REVISION = 1
 
 SHARED_LIBS +=  mca_common_dstore 0.0 # 1.0
 SHARED_LIBS +=  mca_common_monitoring 0.0 # 60.0
@@ -30,11 +31,14 @@ WANTLIB += c execinfo m pciaccess pthrea
 
 MASTER_SITES = 
${HOMEPAGE}/software/ompi/v${V:C/^([0-9]+\.[0-9]+).*/\1/}/downloads/
 
-COMPILER = base-clang ports-gcc
+COMPILER = ports-gcc
 MODULES =  fortran
 MODFORTRAN_COMPILER =  gfortran
 BUILD_DEPENDS =devel/libtool,-ltdl
 LIB_DEPENDS =  devel/libexecinfo
+
+CONFIGURE_ARGS +=  --enable-mpi-fortran=usempif08
+CONFIGURE_ARGS +=  FC=egfortran
 
 MAKE_FLAGS =   V=1
 FAKE_FLAGS =   sysconfdir=${PREFIX}/share/examples/openmpi/