Opened 5 weeks ago
Last modified 5 weeks ago
#71053 new defect
clang @19.1.1_0+analyzer: can't find standard headers
Reported by: | paul-j-lucas (Paul J. Lucas) | Owned by: | |
---|---|---|---|
Priority: | Normal | Milestone: | |
Component: | ports | Version: | 2.10.2 |
Keywords: | ventura | Cc: | eborisch (Eric A. Borisch) |
Port: | clang-19 |
Description
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).
Change History (14)
comment:1 Changed 5 weeks ago by ryandesign (Ryan Carsten Schmidt)
Summary: | clang 19.1.1_0+analyzer: can't find standard headers → clang @19.1.1_0+analyzer: can't find standard headers |
---|
comment:2 Changed 5 weeks ago by ryandesign (Ryan Carsten Schmidt)
Oops, you already showed that you have CLT 15.1. What about Xcode?
comment:3 Changed 5 weeks ago by 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.
comment:4 follow-up: 5 Changed 5 weeks ago by 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.
comment:5 Changed 5 weeks ago by ryandesign (Ryan Carsten Schmidt)
comment:6 Changed 5 weeks ago by kencu (Ken)
comment:7 follow-up: 11 Changed 5 weeks ago by 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.
comment:8 Changed 5 weeks ago by 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.
comment:9 Changed 5 weeks ago by 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}}}
comment:10 Changed 5 weeks ago by eborisch (Eric A. Borisch)
Cc: | eborisch added |
---|
comment:11 Changed 5 weeks ago by 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/binI'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
.
comment:12 Changed 5 weeks ago by 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.
comment:13 Changed 5 weeks ago by 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.
comment:14 Changed 5 weeks ago by 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.
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
?