clang @19.1.1_0+analyzer: can't find standard headers

[paul-j-lucas (Paul J. Lucas)]

I had the previous clang-19 installed and everything worked fine, but since the update, trying to compile a simple "hello, world" program results in:

$ clang-mp-19 hello.c -o hello
hello.c:1:10: fatal error: 'stdio.h' file not found
    1 | #include <stdio.h>
      |          ^~~~~~~~~
1 error generated.

The files, however, are there:

$ port contents clang-19 | grep stdio.h
  /opt/local/libexec/llvm-19/include/c++/v1/stdio.h
  /opt/local/libexec/llvm-19/lib/clang/19/include/llvm_libc_wrappers/stdio.h

Other information of likely interest:

$ system_profiler SPSoftwareDataType SPHardwareDataType
Software:

    System Software Overview:

      System Version: macOS 13.6.9 (22G830)
      Kernel Version: Darwin 22.6.0
      Boot Volume: Macintosh HD
      Boot Mode: Normal
      Computer Name: iMac
      User Name: Paul J. Lucas (pjl)
      Secure Virtual Memory: Enabled
      System Integrity Protection: Enabled
      Time since boot: 41 days, 7 hours, 49 minutes

Hardware:

    Hardware Overview:

      Model Name: iMac
      Model Identifier: iMac18,3
      Processor Name: Quad-Core Intel Core i5
      Processor Speed: 3.4 GHz
      Number of Processors: 1
      Total Number of Cores: 4
      L2 Cache (per Core): 256 KB
      L3 Cache: 6 MB
      Memory: 16 GB
      System Firmware Version: 529.140.2.0.0
      OS Loader Version: 577.140.2~22
      SMC Version (system): 2.41f2
      Serial Number (system): C02YF02SJ1GN
      Hardware UUID: 2FCAC61C-2069-55F8-95A6-058A0DAE8522
      Provisioning UDID: 2FCAC61C-2069-55F8-95A6-058A0DAE8522

$ pkgutil --pkg-info=com.apple.pkg.CLTools_Executables
package-id: com.apple.pkg.CLTools_Executables
version: 15.1.0.0.1.1700200546
volume: /
location: /
install-time: 1703338038

BTW: the previous version of the port installed binaries; this version of the port compiles from source (and it takes a really long time).

[ryandesign (Ryan Carsten Schmidt)]

The clang-19 port was just updated to version 19.1.1 five days ago. The x86_64 macOS 13 build server has been offline for longer than that so it has not yet gotten around to trying to build this, which is why you had to build from source. I am trying to get that build machine back online now.

I assume that clang-19 and other compilers would find stdio.h and other standard system headers in the macOS SDK, not in files that are installed with the port. I'm actually not sure why clang-19 would include a copy of stdio.h or any other standard system header but there's probably a good reason. Which version of Xcode and the Xcode command line tools do you have installed? Which of them is selected, according to xcode-select -p?

[ryandesign (Ryan Carsten Schmidt)]

Oops, you already showed that you have CLT 15.1. What about Xcode?

[paul-j-lucas (Paul J. Lucas)]

I don't have Xcode installed — only Command Line Tools.

$ xcode-select -p
/Library/Developer/CommandLineTools

Reminder: this used to work just fine one minor revision ago.

[paul-j-lucas (Paul J. Lucas)]

One possible reason why clang might install its own headers is because clang's C23 support is farther along than Apple's bastardized clang-as-gcc version is, hence clang's headers likely have more C23 goodness in them that Apple's headers.

[ryandesign (Ryan Carsten Schmidt)]

Replying to paul-j-lucas:

Apple's bastardized clang-as-gcc version

That's not a thing.

[kencu (Ken)]

Edit: sorry, looked like that, until I read further.

[paul-j-lucas (Paul J. Lucas)]

Apple's bastardized clang-as-gcc version

That's not a thing.

I don't know about you, but when I do:

$ $ gcc --version
Apple clang version 15.0.0 (clang-1500.1.0.2.5)
Target: x86_64-apple-darwin22.6.0
Thread model: posix
InstalledDir: /Library/Developer/CommandLineTools/usr/bin

I'd normally expect to see what version of gcc is installed, not clang. It even says "Apple clang." But I really don't care since this isn't the issue.

[paul-j-lucas (Paul J. Lucas)]

If you update an older version of the Command Line Tools for Xcode to version 16.0, clang++ may no longer be able to find standard C++ headers.

FYI: I did not recently update CLT nor did I go from CLT to Xcode.

[paul-j-lucas (Paul J. Lucas)]

FYI, I've since discovered it's not just the headers it can't find. If I compile a trivial program that includes nothing, e.g.

int main() {
}

I get:

$ clang foo.c
ld: library 'System' not found
clang: error: linker command failed with exit code 1 (use -v to see invocation)

The output with -v is:

clang version 19.1.1
Target: x86_64-apple-darwin22.6.0
Thread model: posix
InstalledDir: /opt/local/libexec/llvm-19/bin
 "/opt/local/libexec/llvm-19/bin/clang" -cc1 -triple x86_64-apple-macosx13.0.0 -Wundef-prefix=TARGET_OS_ -Werror=undef-prefix -Wdeprecated-objc-isa-usage -Werror=deprecated-objc-isa-usage -emit-obj -dumpdir a- -disable-free -clear-ast-before-backend -disable-llvm-verifier -discard-value-names -main-file-name foo.c -mrelocation-model pic -pic-level 2 -mframe-pointer=all -ffp-contract=on -fno-rounding-math -funwind-tables=2 -fcompatibility-qualified-id-block-type-checking -fvisibility-inlines-hidden-static-local-var -fbuiltin-headers-in-system-modules -fdefine-target-os-macros -target-cpu penryn -tune-cpu generic -debugger-tuning=lldb -fdebug-compilation-dir=/tmp -target-linker-version 1022.1 -v -fcoverage-compilation-dir=/tmp -resource-dir /opt/local/libexec/llvm-19/lib/clang/19 -internal-isystem /usr/local/include -internal-isystem /opt/local/libexec/llvm-19/lib/clang/19/include -internal-externc-isystem /usr/include -std=c23 -ferror-limit 19 -stack-protector 1 -fblocks -fencode-extended-block-signature -fregister-global-dtors-with-atexit -fgnuc-version=4.2.1 -fskip-odr-check-in-gmf -fmax-type-align=16 -fcolor-diagnostics -D__GCC_HAVE_DWARF2_CFI_ASM=1 -o /var/folders/1z/zglqg15d0v1ccgml070ydxs00000gn/T/foo-d381f6.o -x c foo.c
clang -cc1 version 19.1.1 based upon LLVM 19.1.1 default target x86_64-apple-darwin22.6.0
ignoring nonexistent directory "/usr/include"
#include "..." search starts here:
#include <...> search starts here:
 /usr/local/include
 /opt/local/libexec/llvm-19/lib/clang/19/include
 /System/Library/Frameworks (framework directory)
 /Library/Frameworks (framework directory)
End of search list.
 "/opt/local/libexec/llvm-19/bin/ld" -demangle -lto_library /opt/local/libexec/llvm-19/lib/libLTO.dylib -no_deduplicate -dynamic -arch x86_64 -platform_version macos 13.0.0 13.0.0 -mllvm -enable-linkonceodr-outlining -o a.out /var/folders/1z/zglqg15d0v1ccgml070ydxs00000gn/T/foo-d381f6.o -lSystem /opt/local/libexec/llvm-19/lib/clang/19/lib/darwin/libclang_rt.osx.a}}}

[ryandesign (Ryan Carsten Schmidt)]

Replying to paul-j-lucas:

Apple's bastardized clang-as-gcc version

That's not a thing.

I don't know about you, but when I do:

$ gcc --version
Apple clang version 15.0.0 (clang-1500.1.0.2.5)
Target: x86_64-apple-darwin22.6.0
Thread model: posix
InstalledDir: /Library/Developer/CommandLineTools/usr/bin

I'd normally expect to see what version of gcc is installed, not clang. It even says "Apple clang." But I really don't care since this isn't the issue.

There were many software projects out there prior the creation of clang (and after) that checked to make sure they were being compiled with gcc. The intention of those projects was to ensure they were not being compiled with older pre-gcc compilers; they could not have anticipated that clang would later be created. So as not to break these programs, the developers of clang decided to have it pretend to be gcc in a variety of ways. And yes, on macOS, Apple also provides gcc as an alternative name for calling clang, again for the benefit of old software, or software written for other systems where gcc is the system compiler, that inadvisedly hardcode the name gcc in their build systems.

The preceding does not make anything "bastardized". It is for interoperability.

If you want gcc on macOS, you can install it using MacPorts. If you want it to be accessible by typing gcc, you can do that by running sudo port select gcc.

[paul-j-lucas (Paul J. Lucas)]

Like I said, I don't care about the gcc-as-clang thing. Call it whatever you want. I only mentioned it because it's 4 major revisions old compared to clang-19, so its C23 support (and, presumably, C23 stuff in headers) is lacking, hence the hypothesis for clang installing its own headers and not relying on either Xcode's or CLT's headers.

[kencu (Ken)]

somehow, when you built clang-19, it did not build with a proper reference to the SDK and SDK headers.

Compare:

% clang-mp-19 -v foo.c
clang version 19.1.1
Target: x86_64-apple-darwin24.0.0
Thread model: posix
InstalledDir: /opt/local/libexec/llvm-19/bin
 "/opt/local/libexec/llvm-19/bin/clang" -cc1 -triple x86_64-apple-macosx15.0.0 -Wundef-prefix=TARGET_OS_ -Werror=undef-prefix -Wdeprecated-objc-isa-usage -Werror=deprecated-objc-isa-usage -emit-obj -dumpdir a- -disable-free -clear-ast-before-backend -disable-llvm-verifier -discard-value-names -main-file-name foo.c -mrelocation-model pic -pic-level 2 -mframe-pointer=all -ffp-contract=on -fno-rounding-math -funwind-tables=2 -target-sdk-version=15.0 -fcompatibility-qualified-id-block-type-checking -fvisibility-inlines-hidden-static-local-var -fdefine-target-os-macros -target-cpu penryn -tune-cpu generic -debugger-tuning=lldb -fdebug-compilation-dir=/Users/cunningh -target-linker-version 1115.7.3 -v -fcoverage-compilation-dir=/Users/cunningh -resource-dir /opt/local/libexec/llvm-19/lib/clang/19 -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk -I/usr/local/include -internal-isystem /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/local/include -internal-isystem /opt/local/libexec/llvm-19/lib/clang/19/include -internal-externc-isystem /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include -ferror-limit 19 -stack-protector 1 -fblocks -fencode-extended-block-signature -fregister-global-dtors-with-atexit -fgnuc-version=4.2.1 -fskip-odr-check-in-gmf -fmax-type-align=16 -fcolor-diagnostics -D__GCC_HAVE_DWARF2_CFI_ASM=1 -o /var/folders/mn/s7mk_ptj3d39y51m_hpjnrpm0000gn/T/foo-7b0e5d.o -x c foo.c
clang -cc1 version 19.1.1 based upon LLVM 19.1.1 default target x86_64-apple-darwin24.0.0
ignoring nonexistent directory "/usr/local/include"
ignoring nonexistent directory "/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/local/include"
ignoring nonexistent directory "/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/Library/Frameworks"
#include "..." search starts here:
#include <...> search starts here:
 /opt/local/libexec/llvm-19/lib/clang/19/include
 /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include
 /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/System/Library/Frameworks (framework directory)
End of search list.
 "/opt/local/libexec/llvm-19/bin/ld" -demangle -lto_library /opt/local/libexec/llvm-19/lib/libLTO.dylib -no_deduplicate -dynamic -arch x86_64 -platform_version macos 15.0.0 15.0 -syslibroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk -mllvm -enable-linkonceodr-outlining -o a.out -L/usr/local/lib /var/folders/mn/s7mk_ptj3d39y51m_hpjnrpm0000gn/T/foo-7b0e5d.o -lSystem /opt/local/libexec/llvm-19/lib/clang/19/lib/darwin/libclang_rt.osx.a

I realize you think that the headers in Xcode or the SDK in the CLTs should not be used, however -- they do need to be used, otherwise the compiler is broken, as you are demonstrating.

Now, I have no idea how you built clang-19 exactly to force it to ignore the SDK. It is impossible for me to know that without knowing what you did.

But if you want clang-19 to work, you'll have to undo it.

Or you can just uninstall your version that you built, and use the prebuilt binary that presumably should exist by now.

[paul-j-lucas (Paul J. Lucas)]

I realize you think that the headers in Xcode or the SDK in the CLTs should not be used ...

That's not what I said. I only hypothesized as to why clang/llvm might be installing their own full set of headers. I never said anything about use of headers.

Now, I have no idea how you built clang-19 exactly to force it to ignore the SDK

I didn't do anything to force anything. I just did port install clang-19. FYI, the CLT's clang-as-gcc can find the headers and build working executables just fine.

FYI:

$ cd /Library/Developer/CommandLineTools/SDKs
$ ls -l
lrwxr-xr-x 1 root wheel  14 Oct 12 09:47 MacOSX.sdk -> MacOSX14.2.sdk/
drwxr-xr-x 7 root wheel 224 Oct 12 09:47 MacOSX13.3.sdk/
lrwxr-xr-x 1 root wheel  14 Oct 12 09:46 MacOSX13.sdk -> MacOSX13.3.sdk/
drwxr-xr-x 7 root wheel 224 Oct 12 09:48 MacOSX14.2.sdk/
lrwxr-xr-x 1 root wheel  14 Oct 12 09:45 MacOSX14.sdk -> MacOSX14.2.sdk/

From experience, on a system such as mine that's running a macOS (13.7) older that the SDK to which the MacOSX.sdk symlink points (14.2), it can sometimes matter. (I guess my kind-of-old Intel iMac is running the latest supported OS for its hardware; otherwise, I would have been prompted to upgrade.)

When you build, do you build against only when CLT is installed? Or the full Xcode? Also from experience, it can make a difference.

Just for the heck of it, I reinstalled CLT 15.1, but now that the clang-19 binaries have been built, I get those installed instead --- which work. So I guess I'm personally fine for now.