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.
