elmerfem: some errors with the port on specific macOS versions

[barracuda156]

Two problems discovered:

1. Fortran argument mismatch errs out on some systems (but not all). Example:

   cd /opt/local/var/macports/build/_opt_bblocal_var_buildworker_ports_build_ports_science_elmerfem/elmerfem/work/build/meshgen2d/src && /usr/bin/clang++ -DHAVE_EXECUTECOMMANDLINE -DUSE_ARPACK -DUSE_ISO_C_BINDINGS -I/opt/local/include -I/opt/local/var/macports/build/_opt_bblocal_var_buildworker_ports_build_ports_science_elmerfem/elmerfem/work/elmerfem-0d2f040f4a49ea0c994c27ddf85b88924676cdfa/meshgen2d/src/include -I/opt/local/var/macports/build/_opt_bblocal_var_buildworker_ports_build_ports_science_elmerfem/elmerfem/work/build/meshgen2d/src/include -I/opt/local/var/macports/build/_opt_bblocal_var_buildworker_ports_build_ports_science_elmerfem/elmerfem/work/build/meshgen2d/src -pipe -Os -DNDEBUG -I/opt/local/include -stdlib=libc++ -arch x86_64 -mmacosx-version-min=10.8 -fPIE   -DCONTIG= -MD -MT meshgen2d/src/CMakeFiles/Mesh2D.dir/BGTriangleMesh.o -MF CMakeFiles/Mesh2D.dir/BGTriangleMesh.o.d -o CMakeFiles/Mesh2D.dir/BGTriangleMesh.o -c /opt/local/var/macports/build/_opt_bblocal_var_buildworker_ports_build_ports_science_elmerfem/elmerfem/work/elmerfem-0d2f040f4a49ea0c994c27ddf85b88924676cdfa/meshgen2d/src/BGTriangleMesh.cpp
   /opt/local/var/macports/build/_opt_bblocal_var_buildworker_ports_build_ports_science_elmerfem/elmerfem/work/elmerfem-0d2f040f4a49ea0c994c27ddf85b88924676cdfa/mathlibs/src/arpack/cnaitr.f:666:35:
   
     383 |             call svout (logfil, 1, rnorm, ndigit,
         |                                   2
   ......
     666 |             call svout (logfil, 2, rtemp, ndigit,
         |                                   1
   Error: Rank mismatch between actual argument at (1) and actual argument at (2) (scalar and rank-1)
   /opt/local/var/macports/build/_opt_bblocal_var_buildworker_ports_build_ports_science_elmerfem/elmerfem/work/elmerfem-0d2f040f4a49ea0c994c27ddf85b88924676cdfa/mathlibs/src/arpack/cnaitr.f:737:39:
   
     383 |             call svout (logfil, 1, rnorm, ndigit,
         |                                   2    
   ......
     737 |                 call svout (logfil, 2, rtemp, ndigit,
         |                                       1
   Error: Rank mismatch between actual argument at (1) and actual argument at (2) (scalar and rank-1)
   make[2]: *** [mathlibs/src/arpack/CMakeFiles/arpack.dir/cnaitr.o] Error 1
   

​https://build.macports.org/builders/ports-10.8_x86_64-builder/builds/135502/steps/install-port/logs/stdio

2. I got a seemingly random install names failure on one of my PowerMacs: build is successful, but the port is detected as broken, as some dylibs are not linked correctly. Looks strange, since out of numerous dylibs only a few are broken. I will look into that.

Apparently this issue does not happen on buildbots, so may be either PPC-specific or something went wrong with a particular build attempt.

[barracuda156]

Specifically, I got this now:

--->  Cleaning elmerfem
--->  Removing work directory for elmerfem
--->  Updating database of binaries
--->  Scanning binaries for linking errors
Could not open /opt/local/lib/libfhuti.dylib: Error opening or reading file (referenced from /opt/local/bin/ElmerSolver)
Could not open /opt/local/lib/libmatc.dylib: Error opening or reading file (referenced from /opt/local/bin/ElmerSolver)
Could not open /opt/local/lib/libmpi_stubs.dylib: Error opening or reading file (referenced from /opt/local/bin/ElmerSolver)
Could not open /opt/local/lib/libelmersolver.dylib: Error opening or reading file (referenced from /opt/local/bin/ElmerSolver)
Could not open /opt/local/lib/EliminateDirichlet.dylib: Error opening or reading file (referenced from /opt/local/share/elmersolver/lib/EliminatePeriodic.dylib)

These are wrong paths. Correct ones are:

/opt/local/lib/elmersolver/libelmersolver.dylib
/opt/local/lib/elmersolver/libfhuti.dylib
/opt/local/lib/elmersolver/libmatc.dylib
/opt/local/lib/elmersolver/libmpi_stubs.dylib
/opt/local/share/elmersolver/lib/EliminateDirichlet.dylib

UPD. And no, all paths are wrong, Macports just does not report every broken one upon a scan.

[barracuda156]

UPD2. In fact, it is broken on Intel, just Macports fails to detect that, ironically. Look at that:

--->  Cleaning elmerfem
--->  Removing work directory for elmerfem
10:~ svacchanda$ otool -L /opt/local/bin/ElmerSolver
/opt/local/bin/ElmerSolver:
	/opt/local/lib/libMacportsLegacySupport.dylib (compatibility version 1.0.0, current version 1.0.10)
	/opt/local/lib/libelmersolver.dylib (compatibility version 0.0.0, current version 0.0.0)
	/opt/local/lib/libmpi_stubs.dylib (compatibility version 0.0.0, current version 0.0.0)
	/opt/local/lib/libmatc.dylib (compatibility version 0.0.0, current version 0.0.0)
	/opt/local/lib/libfhuti.dylib (compatibility version 0.0.0, current version 0.0.0)
	/opt/local/lib/libarpack.dylib (compatibility version 0.0.0, current version 0.0.0)
	/opt/local/lib/libvecLibFort.dylib (compatibility version 0.0.0, current version 0.0.0)
	/opt/local/lib/libgcc/libgfortran.5.dylib (compatibility version 6.0.0, current version 6.0.0)
	/opt/local/lib/libgcc/libgcc_s.1.1.dylib (compatibility version 1.0.0, current version 1.1.0)
	/opt/local/lib/libgcc/libquadmath.0.dylib (compatibility version 1.0.0, current version 1.0.0)
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 125.2.11)

Expectedly then:

10:~ svacchanda$ /opt/local/bin/ElmerSolver
dyld: Library not loaded: /opt/local/lib/libelmersolver.dylib
  Referenced from: /opt/local/bin/ElmerSolver
  Reason: image not found
Trace/BPT trap

[barracuda156]

Issue with upstream: ​https://github.com/ElmerCSC/elmerfem/issues/398

But I will fix it manually today. I was concerned that it is PPC-only issue, but now it is proved it is not specific (second example if from a standard 10.6.8 x86_64 with Xcode 4.2 and libc++).

[ryandesign (Ryan Carsten Schmidt)]

Replying to barracuda156:

1. Fortran argument mismatch errs out on some systems (but not all). Example:

This occurs on all OS versions but it's considered an error on 10.13 and earlier but only a warning on 10.14 and later; I don't know why.

[ryandesign (Ryan Carsten Schmidt)]

Re wrong dylib paths, I would not be surprised if this is not the fault of elmerfem but of the cmake portgroup. The cmake portgroup includes a lot of well-meaning defaults that sometimes override things in the project's cmake files which have unexpected results. For example, elmerfem's CMakeLists.txt seems designed to force the use of relative paths and rpath on macOS, but the cmake portgroup disables that and overrides the project's own install names with -DCMAKE_INSTALL_NAME_DIR="${cmake.install_prefix}/lib".

[barracuda156]

Replying to ryandesign:

Replying to barracuda156:

1. Fortran argument mismatch errs out on some systems (but not all). Example:

This occurs on all OS versions but it's considered an error on 10.13 and earlier but only a warning on 10.14 and later; I don't know why.

I think due to this:

IF("${CMAKE_Fortran_COMPILER_ID}" MATCHES "GNU")
  IF(CMAKE_CXX_COMPILER_VERSION VERSION_GREATER 9.9)
    SET(CMAKE_Fortran_FLAGS "${CMAKE_Fortran_FLAGS} -fallow-argument-mismatch")

I.e. they check for GCC version via CXX compiler, but Macports uses Clang, so the comparison cannot work as intended.

[barracuda156]

Replying to ryandesign:

Re wrong dylib paths, I would not be surprised if this is not the fault of elmerfem but of the cmake portgroup. The cmake portgroup includes a lot of well-meaning defaults that sometimes override things in the project's cmake files which have unexpected results. For example, elmerfem's CMakeLists.txt seems designed to force the use of relative paths and rpath on macOS, but the cmake portgroup disables that and overrides the project's own install names with -DCMAKE_INSTALL_NAME_DIR="${cmake.install_prefix}/lib".

Oh, okay. Thank you, this seems plausible. I can try dropping PG-added flags.

[barracuda156]

Replying to ryandesign:

So I reinstalled with this flag deleted from pre_args. In result dylibs have rpaths:

36-140% otool -L /opt/local/bin/ElmerSolver
/opt/local/bin/ElmerSolver:
	/opt/local/lib/libMacportsLegacySupport.dylib (compatibility version 1.0.0, current version 1.0.99)
	@rpath/libelmersolver.dylib (compatibility version 0.0.0, current version 0.0.0)
	@rpath/libmpi_stubs.dylib (compatibility version 0.0.0, current version 0.0.0)
	@rpath/libmatc.dylib (compatibility version 0.0.0, current version 0.0.0)
	@rpath/libfhuti.dylib (compatibility version 0.0.0, current version 0.0.0)
	@rpath/libarpack.dylib (compatibility version 0.0.0, current version 0.0.0)
	/opt/local/lib/libvecLibFort.dylib (compatibility version 0.0.0, current version 0.0.0)
	/opt/local/lib/libgcc/libgfortran.5.dylib (compatibility version 6.0.0, current version 6.0.0)
	/opt/local/lib/libgcc/libgomp.1.dylib (compatibility version 2.0.0, current version 2.0.0)
	/opt/local/lib/libgcc/libgcc_s.1.1.dylib (compatibility version 1.0.0, current version 1.1.0)
	/usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0)
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 117.0.0)

However the binary does not complain anymore and loads fine.

Should I leave it at this? I.e., rpaths are okay?

[kencu (Ken)]

We try not to use rpaths unless there is no other option.

The usual thing to do would be something like this:

configure.pre_args-replace \
    -DCMAKE_INSTALL_NAME_DIR="${cmake.install_prefix}/lib" \
    -DCMAKE_INSTALL_NAME_DIR="${cmake.install_prefix}/lib/elmersolver"

that has to be tested, but should work.

There should probably be a cmake portgroup option for this, but it appears there is not.

[kencu (Ken)]

BTW, there is an option in the compilers PortGroup to allow argument mismatches for legacy fortran code -- fortran exhibits this issue fairly frequently. (re your initial problem).

[barracuda156]

In e0b86786afc217b48edc3f84e4c95eac3000e2f4/macports-ports (master):

elmerfem: fix dylib paths broken by cmake PG

Fixes: #67502