On a M1 Macbook I get errors trying to use NetCDF from Julia. Any idea which libnetcdf it is looking for? Isn’t NetCDF in Julia self-sufficient? https://github.com/JuliaGeo/NetCDF.jl does not mention any external system package dependencies.
Thank you.
[~]᳅ julia
_
_ _ ()_ | Documentation: https://docs.julialang.org
() | () () |
_ _ | | __ _ | Type “?” for help, “]?” for Pkg help.
| | | | | | |/ ` | |
| | || | | | (| | | Version 1.7.0 (2021-11-30) / |_‘|||_’_| | Official https://julialang.org/ release
|__/ |
It’s not yet supported (except as mentioned in the end). NetCDF.jl has a dependency on NetCDF_jll. JLL packages, are often written in C (which CAN possibly support M1, not a guarantee independently of Julia), to me JLL is “code” for C, but could be other languages.
When people say ARM, or M1, is supported by Julia, it means for pure Julia code (one reason to have that, I still like the ability, and no reason not to use with C, except security, and might not be supported), and Julia itself.
You probably can use x86 Julia (and then indirectly the Rosetta transpiler).
I’m not sure what it takes to get NetCDF_jll updated. It (and other JLLs, but HDF5_jll and OpenSSL_jll are already taken care of, so this seems to be your last hurdle for that package) need to compile too for M1. It’s clearly not automatic, but might be around the corner. Maybe you can help with (trying) compiling libnetcdf and/or investigating.
In that case I noticed the JLL dependency in the Projects.toml file, but it could have been a dependency of one of those… so I use JuliaHub to see all the dependencies usually, if I need to. It should work, but isn’t always updated with some info, so the Manifest file might be a better place to look…
However, it looks like HDF5 now has precompiled binaries for MacOS on ARM via conda-forge, so once the HDF5 build script is updated, then it should be possible to update NetCDF to build on MacOS/ARM as well.
It seems we/you, know why this didn’t work out of the box, AND the solution(s). I was going by:
HDF5_jll.jl is available for the following platforms:
macOS aarch64 ( aarch64-apple-darwin ) […]
Still, this is sub-optimal for new users. I’m thinking, did the user get a warning? NetCDF_jll was seemingly installed with no (working) support. Should it not have installed? I’m not sure that’s possible, at best to install, and provide a warning on install time. Then that package needs to implement it, or strictly something else (Yggrasil?) for all of them.
In general, Python (and R) has a lot of C/otherlang or C++ (very common for R, less so for Python?) dependencies. That works very smoothly most of the time, and users may not even know that Python isn’t doing the heavy lifting. For new platforms, such as M1, maybe they have greater problems, more to fix.
I installed NetCDF on a M1 Mac Mini with Julia 1.8-rc3 but still couldn’t use it for the same reason. I got the following message with status --outdated -m:
For NetCDF_jll basically we haven’t been able to build a version that works on all platforms for a while. The problems seem related to limited cross compilation support of both libnetcdf and libhdf5. That means we got to a state where users on different platforms will have to pin different NetCDF_jll versions for things to work, which we cannot really make easier since Pkg works platform independently. There are many threads and issues but NCDatasets.jl#164 and Yggdrasil#4511 have quite some discussion, and links to upstream issues. Our most recent attempt at updating HDF5_jll did unfortunately not help NetCDF_jll.
I have also a stalled attempt to build GMT due to cross compiling difficulties. I think all will be better when it is accepted that Windows-is-not-Unix.I have no idea on how difficult is to change the building tools. But if we could build the dll’s with Visual Studio (or clang if whatever the Cmake accepts to build native Windows libs) then all those problems would go away.
During years we suffered to learn how completely port GMT to windows. The biggest shit was the cross dll problem (one cannot allocate memory or open a file in one dll and free it/close file in another). There was also the problem of text files on Windows must be explicitly open as such, which Unix does not obliges to. And there several cases of POSIX functions not existing on the Windows API and we had to find the equivalent functionality.
But this has all been solved and GMT builds perfectly fine on Windows using MSVC. We (I’m talking as a GMT dev) never claimed that GMT could be build with MinGW and in fact we say use Cygwin and MinGW at your own risk. That is not officially supported
The problem you refer comes exactly from an apparently issue with building with MinGW. So, at the end I still think that the Windows-is-not-Unix applies here.
Likely because MSVC sneakily links the library for some other reasons. You don’t address the fact that you use a function which requires a specific library and you don’t link that library explicitly. That’s wrong whatever toolchain you use.