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

Reply via email to