NetCDF 4.10.1: file extension issue when cross-compiling plugins for Mac OS X on Linux using autotools

[Alexander-Barth]

When cross-compiling the netCDF plugins for Mac OS X on Linux, the compiled plugins have the .so extension (using autotool, build script):

$ cd ~/src/Yggdrasil-mine/N/NetCDF/build/aarch64-apple-darwin/7Uod5EXx/aarch64-apple-darwin20-libgfortran5-cxx11/destdir/hdf5/lib/plugin 
$ ls
lib__nch5blosc.so  lib__nch5deflate.so     lib__nch5shuffle.so  lib__nch5zstd.so        lib__nczstdfilters.so
lib__nch5bzip2.so  lib__nch5fletcher32.so  lib__nch5szip.so     lib__nczhdf5filters.so

The binary seems to be correct:

$ file lib__nczhdf5filters.so
lib__nczhdf5filters.so: Mach-O 64-bit arm64 bundle, flags:<NOUNDEFS|DYLDLINK|TWOLEVEL>

I was wondering if the use of the .so extension (rather than .dynlib) is intended ?

Conda distributes these plugins with the ".dynlib" extension. The issue might be build system dependent. We are using autotools and Conda is using cmake. I am not sure if Conda is cross-compiling.

[Alexander-Barth]

Indeed, cmake installs the plugins with the correct extension for apple-darwin (when cross-compiling).

[WardF]

I'm not 100% certain whether this is something that would be under my control, I don't do a lot of cross compiling. Can you provide your script/workflow? I have access to both Linux and MacOS, I can poke around and see what I can figure out. Thanks!

[WardF]

Update: I see you have your build script attached, I'll take a look! :)

[Alexander-Barth]

For information, libnetcdf has the expected file extension, but not the plugins. Maybe this helps to narrow down the issue. In any case, renaming the files works for us.

I am wondering if you have a general recommendation whether to use cmake vs autotool for distributing precompiled binaries. Is this just a question of preferences or are there also technical reasons? Cmake is preinstalled in the Julia build environment.