macOS Xcode 15+ build failure

[adamjstewart]

On macOS 15.0.1 with Apple Clang 16.0.0 I see the following build failure:

nfo 5:0:0  -o libpnetcdf.la -rpath /Users/Adam/spack/opt/spack/darwin-sequoia-m2/apple-clang-16.0.0/parallel-netcdf-1.13.0-vqaapyaynlxfrqvdhcb22724vbkfgthk/lib   ../dispatchers/libdispatchers.la ../drivers/common/libcommon.la ../drivers/ncmpio/libncmpio.la     ../binding/cxx/libcxx.la ../binding/f77/libf77.la ../binding/f90/libf90.la -L/Users/Adam/spack/opt/spack/darwin-sequoia-m2/apple-clang-16.0.0/openmpi-5.0.5-ax66y3wxazux43dpjmc4bkuv3jgvjga4/lib -L/usr/local/gfortran/lib/gcc/aarch64-apple-darwin23/14.2.0 -L/usr/local/gfortran/lib/gcc/aarch64-apple-darwin23/14.2.0/../../.. -lemutls_w -lheapt_w -lmpi_usempif08 -lmpi_usempi_ignore_tkr -lmpi_mpifh -lmpi -lgfortran -lquadmath -L/Users/Adam/spack/opt/spack/darwin-sequoia-m2/apple-clang-16.0.0/openmpi-5.0.5-ax66y3wxazux43dpjmc4bkuv3jgvjga4/lib -L/usr/local/gfortran/lib/gcc/aarch64-apple-darwin23/14.2.0 -L/usr/local/gfortran/lib/gcc/aarch64-apple-darwin23/14.2.0/../../.. -lemutls_w -lheapt_w -lmpi_usempif08 -lmpi_usempi_ignore_tkr -lmpi_mpifh -lmpi -lgfortran -lquadmath
libtool: link: /Users/Adam/spack/opt/spack/darwin-sequoia-m2/apple-clang-16.0.0/openmpi-5.0.5-ax66y3wxazux43dpjmc4bkuv3jgvjga4/bin/mpic++ -std=gnu++11 -r -keep_private_externs -nostdlib -o .libs/libpnetcdf.5.dylib-master.o   -Wl,-force_load,../dispatchers/.libs/libdispatchers.a -Wl,-force_load,../drivers/common/.libs/libcommon.a -Wl,-force_load,../drivers/ncmpio/.libs/libncmpio.a -Wl,-force_load,../binding/cxx/.libs/libcxx.a -Wl,-force_load,../binding/f77/.libs/libf77.a -Wl,-force_load,../binding/f90/.libs/libf90.a
ld: -rpath can only be used when creating a dynamic final linked image
clang++: error: linker command failed with exit code 1 (use -v to see invocation)

It's possible that newer versions of Xcode ship with an ld that is incompatible with parallel-netcdf.

Full build log

[adamjstewart]

Also reported with Xcode/Apple Clang 15.0.0: spack/spack#45919

[skosukhin]

I'm pretty sure that it's a Spack-specific problem.

[wkliao]

While we are still looking for the Mac environment to test, I wonder if using the latest GNU autoconf 2.72, automate 1.17, and libtool 2.5.3 will resolve this issue.

[wkliao]

I think it is most likely the Spack problem, as @skosukhin suggested.

FYI. Not using Spack, I was able to build PnetCDF successfully a Mac OS 14.7 (the platform available to me) with the followings.

• PnetCDF 1.13.0 release
• clang16.0.0
• gfortran 13.2.0
• MPICH 4.2.3
• OpenMPI 5.0.5

[adamjstewart]

I'm also convinced this is a Spack problem, closing.

[haampie]

This is not a Spack bug, it's an issue with openmpi configured with --enable-wrapper-rpath --with-wrapper-ldflags=/path/to/something, which I think is common enough. It tells openmpi to add certain default rpaths (e.g. to gcc runtime libraries).

The issue is

mpic++ -r ...

invokes

clang++ -r -Wl,-rpath,/path/to/something

which calls the linker

ld -r -rpath /path/to/something

which pedantically errors out because -rpath does not apply when creating a new object file with -r.

---

So:

1. The issue is caused by OpenMPI's compiler wrapper adding -rpath even if -r is passed.
2. Maybe parallel-netcdf should just create a static archive with ar instead of combining into an object file with ld -r, since there's tons of other compiler wrappers that could add rpaths and are unaware of ld -r.