netcdf-c FTBFS on ocdump.c with Homebrew Clang 19.1.7 on MacOS 15.3

[czender]

A few months ago my default build environment on MacOS stopped working due to a Clang compiler error on the file ocdump.c. I usually do not report compiler errors because they have nothing to do with netCDF per se, and the compiler authors usually resolved these things eventually. So consider this a heads-up and feel free to resolve without taking action. However, note that this particular compiler error on this particular file has been there for ~3-4 months, and survived many patch releases of Clang. So it may be something that prevents other users from building/testing netCDF 4.9.3. Everything here (Clang, MacOS, and the netCDF-main branch are the latest available as of today.

zender@spectral:~/netcdf-c$ clang --version
Homebrew clang version 19.1.7
Target: arm64-apple-darwin24.3.0
Thread model: posix
InstalledDir: /opt/homebrew/Cellar/llvm/19.1.7/bin
Configuration file: /opt/homebrew/etc/clang/arm64-apple-darwin24.cfg
zender@spectral:~/netcdf-c$ 
zender@spectral:~/netcdf-c$ make
...
Normal output ...
...
/bin/sh ../libtool  --tag=CC   --mode=compile clang -DHAVE_CONFIG_H -I. -I..  -I.. -I.. -I../include -I/opt/homebrew/include  -fno-strict-aliasing -MT liboc_la-ocdump.lo -MD -MP -MF .deps/liboc_la-ocdump.Tpo -c -o liboc_la-ocdump.lo `test -f 'ocdump.c' || echo './'`ocdump.c
libtool: compile:  clang -DHAVE_CONFIG_H -I. -I.. -I.. -I.. -I../include -I/opt/homebrew/include -fno-strict-aliasing -MT liboc_la-ocdump.lo -MD -MP -MF .deps/liboc_la-ocdump.Tpo -c ocdump.c  -fno-common -DPIC -o .libs/liboc_la-ocdump.o
PLEASE submit a bug report to https://github.com/Homebrew/homebrew-core/issues and include the crash backtrace, preprocessed source, and associated run script.
Stack dump:
0.      Program arguments: clang -DHAVE_CONFIG_H -I. -I.. -I.. -I.. -I../include -I/opt/homebrew/include -fno-strict-aliasing -MT liboc_la-ocdump.lo -MD -MP -MF .deps/liboc_la-ocdump.Tpo -c ocdump.c -fno-common -DPIC -o .libs/liboc_la-ocdump.o
1.      <eof> parser at end of file
2.      Code generation
3.      Running pass 'Function Pass Manager' on module 'ocdump.c'.
4.      Running pass 'InstructionSelect' on function '@dumpfield'
 #0 0x00000001186da9dc llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) (/opt/homebrew/Cellar/llvm/19.1.7/lib/libLLVM.dylib+0x4a129dc)
 #1 0x0000000113e27808 llvm::sys::CleanupOnSignal(unsigned long) (/opt/homebrew/Cellar/llvm/19.1.7/lib/libLLVM.dylib+0x15f808)
 #2 0x00000001186caa00 (anonymous namespace)::CrashRecoveryContextImpl::HandleCrash(int, unsigned long) (/opt/homebrew/Cellar/llvm/19.1.7/lib/libLLVM.dylib+0x4a02a00)
 #3 0x00000001186caadc CrashRecoverySignalHandler(int) (/opt/homebrew/Cellar/llvm/19.1.7/lib/libLLVM.dylib+0x4a02adc)
 #4 0x000000019aa3ede4 (/usr/lib/system/libsystem_platform.dylib+0x180482de4)
 #5 0x0000000114b644fc llvm::InstructionSelect::runOnMachineFunction(llvm::MachineFunction&) (/opt/homebrew/Cellar/llvm/19.1.7/lib/libLLVM.dylib+0xe9c4fc)
 #6 0x0000000114b644fc llvm::InstructionSelect::runOnMachineFunction(llvm::MachineFunction&) (/opt/homebrew/Cellar/llvm/19.1.7/lib/libLLVM.dylib+0xe9c4fc)
 #7 0x0000000114344c18 llvm::MachineFunctionPass::runOnFunction(llvm::Function&) (/opt/homebrew/Cellar/llvm/19.1.7/lib/libLLVM.dylib+0x67cc18)
 #8 0x000000011400aa9c llvm::FPPassManager::runOnModule(llvm::Module&) (/opt/homebrew/Cellar/llvm/19.1.7/lib/libLLVM.dylib+0x342a9c)
 #9 0x0000000113ffe70c llvm::legacy::PassManagerImpl::run(llvm::Module&) (/opt/homebrew/Cellar/llvm/19.1.7/lib/libLLVM.dylib+0x33670c)
#10 0x00000001071d2f68 clang::EmitBackendOutput(clang::DiagnosticsEngine&, clang::HeaderSearchOptions const&, clang::CodeGenOptions const&, clang::TargetOptions const&, clang::LangOptions const&, llvm::StringRef, llvm::Module*, clang::BackendAction, llvm::IntrusiveRefCntPtr<llvm::vfs::FileSystem>, std::__1::unique_ptr<llvm::raw_pwrite_stream, std::__1::default_delete<llvm::raw_pwrite_stream>>, clang::BackendConsumer*) (/opt/homebrew/Cellar/llvm/19.1.7/lib/libclang-cpp.dylib+0x17def68)
#11 0x000000010759f700 clang::BackendConsumer::HandleTranslationUnit(clang::ASTContext&) (/opt/homebrew/Cellar/llvm/19.1.7/lib/libclang-cpp.dylib+0x1bab700)
#12 0x0000000105c2af60 clang::ParseAST(clang::Sema&, bool, bool) (/opt/homebrew/Cellar/llvm/19.1.7/lib/libclang-cpp.dylib+0x236f60)
#13 0x0000000107d692f0 clang::FrontendAction::Execute() (/opt/homebrew/Cellar/llvm/19.1.7/lib/libclang-cpp.dylib+0x23752f0)
#14 0x0000000107cdfda8 clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) (/opt/homebrew/Cellar/llvm/19.1.7/lib/libclang-cpp.dylib+0x22ebda8)
#15 0x0000000107dc2e04 clang::ExecuteCompilerInvocation(clang::CompilerInstance*) (/opt/homebrew/Cellar/llvm/19.1.7/lib/libclang-cpp.dylib+0x23cee04)
#16 0x00000001006e6b3c cc1_main(llvm::ArrayRef<char const*>, char const*, void*) (/opt/homebrew/Cellar/llvm/19.1.7/bin/clang-19+0x100006b3c)
#17 0x00000001006e478c ExecuteCC1Tool(llvm::SmallVectorImpl<char const*>&, llvm::ToolContext const&) (/opt/homebrew/Cellar/llvm/19.1.7/bin/clang-19+0x10000478c)
#18 0x000000010791a9b4 void llvm::function_ref<void ()>::callback_fn<clang::driver::CC1Command::Execute(llvm::ArrayRef<std::__1::optional<llvm::StringRef>>, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char>>*, bool*) const::$_0>(long) (/opt/homebrew/Cellar/llvm/19.1.7/lib/libclang-cpp.dylib+0x1f269b4)
#19 0x0000000113d5822c llvm::CrashRecoveryContext::RunSafely(llvm::function_ref<void ()>) (/opt/homebrew/Cellar/llvm/19.1.7/lib/libLLVM.dylib+0x9022c)
#20 0x000000010791a1e4 clang::driver::CC1Command::Execute(llvm::ArrayRef<std::__1::optional<llvm::StringRef>>, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char>>*, bool*) const (/opt/homebrew/Cellar/llvm/19.1.7/lib/libclang-cpp.dylib+0x1f261e4)
#21 0x00000001078d06bc clang::driver::Compilation::ExecuteCommand(clang::driver::Command const&, clang::driver::Command const*&, bool) const (/opt/homebrew/Cellar/llvm/19.1.7/lib/libclang-cpp.dylib+0x1edc6bc)
#22 0x00000001078f8140 clang::driver::Driver::ExecuteCompilation(clang::driver::Compilation&, llvm::SmallVectorImpl<std::__1::pair<int, clang::driver::Command const*>>&) (/opt/homebrew/Cellar/llvm/19.1.7/lib/libclang-cpp.dylib+0x1f04140)
#23 0x00000001006e3500 clang_main(int, char**, llvm::ToolContext const&) (/opt/homebrew/Cellar/llvm/19.1.7/bin/clang-19+0x100003500)
#24 0x00000001006f104c main (/opt/homebrew/Cellar/llvm/19.1.7/bin/clang-19+0x10001104c)
#25 0x000000019a688274 
clang: error: clang frontend command failed with exit code 139 (use -v to see invocation)
Homebrew clang version 19.1.7
Target: arm64-apple-darwin24.3.0
Thread model: posix
InstalledDir: /opt/homebrew/Cellar/llvm/19.1.7/bin
Configuration file: /opt/homebrew/etc/clang/arm64-apple-darwin24.cfg
clang: note: diagnostic msg: 
********************

PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT:
Preprocessed source(s) and associated run script(s) are located at:
clang: note: diagnostic msg: /var/folders/ct/rzzvxlqn4_3f9cr8wgn2pm480000gn/T/ocdump-2069b1.c
clang: note: diagnostic msg: /var/folders/ct/rzzvxlqn4_3f9cr8wgn2pm480000gn/T/ocdump-2069b1.sh
clang: note: diagnostic msg: Crash backtrace is located in
clang: note: diagnostic msg: /Users/zender/Library/Logs/DiagnosticReports/clang-19_<YYYY-MM-DD-HHMMSS>_<hostname>.crash
clang: note: diagnostic msg: (choose the .crash file that corresponds to your crash)
clang: note: diagnostic msg: 

********************
gmake[2]: *** [Makefile:643: liboc_la-ocdump.lo] Error 1
gmake[2]: Leaving directory '/Users/zender/netcdf-c/oc2'
gmake[1]: *** [Makefile:816: all-recursive] Error 1
gmake[1]: Leaving directory '/Users/zender/netcdf-c'
gmake: *** [Makefile:658: all] Error 2
zender@spectral:~/netcdf-c$ 

[WardF]

Interesting; I work in MacOS and have not encountered this with the clang distributed by Apple as part of their dev tools. Using homebrew to try to install clang returns no available formula with the name clang; which package did you install via brew that provided clang? My next guess was llvm but homebrew only appears to provide versions 11-18, not 19 as clang reports above. I'll see if I can get this replicated in a different environment, but if you can point me towards the specific source for your homebrew-installed clang, I'll try to get this fixed.

[czender]

Yes, that's curious. Thanks for looking into this. LMK if I can provide any other information...

zender@spectral:~$ uname -a
Darwin spectral 24.3.0 Darwin Kernel Version 24.3.0: Thu Jan  2 20:24:16 PST 2025; root:xnu-11215.81.4~3/RELEASE_ARM64_T6000 arm64 arm Darwin
zender@spectral:~$ brew --version
Homebrew 4.4.20
zender@spectral:~$ brew upgrade
zender@spectral:~$ brew install llvm
Warning: llvm 19.1.7 is already installed and up-to-date.
To reinstall 19.1.7, run:
  brew reinstall llvm
zender@spectral:~$ 

[WardF]

Thanks Charlie, llvm was hiding there in plain sight. 4.9.3 is going out tomorrow but I will see if I can figure this out, and it it reflects something in the source code itself. I'll also see what happens with clang 19 in a Linux VM.

[WardF]

Ok, I can replicate this. Thanks @czender. I'm not sure what to do about it, other than to make a note of it. Do you have XCode/Apple-supplied developer tools installed? Or are you working in a homebrew-only development environment? I'm trying to establish some fenceposts around this issue. How curious. I have the Apple dev tools installed, which include their own clang, so I'm wondering if this is some conflict between homebrew-supplied clang and supporting libraries installed by XCode.

[czender]

I'm relieved I'm not the only one seeing ghosts in the compiler. I also have the normal (free) Xcode tools installed, though my development environment paths give precedence to Homebrew. I have not filed a bug report with
https://github.com/Homebrew/homebrew-core/issues
That might be a place to start. Would you like me to do that, or would you prefer to do it?

[WardF]

It now occurs to me that you cannot install homebrew without first installing MacOS devtools, so I can stop setting up the VM to replicate a 'homebrew-only' environment. In a linux VM, I installed clang:

(forgive the screenshot, copy and paste from my VM isn't working and this was expedient).

I'm not seeing this issue using clang 19.x on Linux. This makes me wonder if th

[WardF]

@czender I will be happy to open it, although it will be largely cutting and pasting the information you have provided. Thanks!

[WardF]

I'm curious, as an aside, why you prefer the homebrew-provided clang/llvm-based tools? I don't know what I don't know, so I'm curious what makes them preferable for you :). Thanks!

[czender]

I want to use Homebrew-provided C++ or Fortran90 libraries with your C++/F90 code, so it's safer to compile using the same compilers. Less chance of compiler mis-match errors. Also Homebrew updates on a rolling schedule, much less lag than Apple updates.