C++ headers are not found after updating to CLTs version 16.0

[SaintBol]

Fresh reinstall of macports on Sequoia. Plenty of ports no longer compile, looks like a generic problem with Apple clang version 16.0.0 (clang-1600.0.26.3).

Many of them complain about fatal error / file not found for #include lines with some <include> stuff, like in bug #70749

Other ones complain (error) either during compilation or even configure phase about: «ISO C99 and later do not support implicit int [-Wimplicit-int]» or «ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration]»

Attached logs for db48, lzip, lrzsz, libssh2, python312, lz4, smartmontools, tmux, unrar.

[SaintBol]

compilation logs

[mbaehr (Michael Baehr)]

I've been digging on this issue quite a bit today, and as far as the packages that fail with an include error from libstdc++ (see #70749, #70716), the problem is specific to the environment when MacPorts is executing either the configure or the build step. By process of elimination from my own testing, this particular variable seems to be the root of the issue:

DEVELOPER_DIR='/Library/Developer/CommandLineTools'

If I reproduce the precise environment that MacPorts is exporting, minus that variable, and execute the same command, the failure does not occur. If I export that variable, it does. Could be a red herring but I'm having a lot of success with multiple packages so far.

[reneeotten (Renee Otten)]

that's shouldn't be too surprising given that the OS was released earlier today and with every new macOS versions there will be issues that need to be resolved. A "general" ticket with an archive of build logs isn't very helpful. If you find issues, please submit a ticket for each port and/or have a bit of patience while people adopt the new OS and maintainers will get to fixing issues.

[mbaehr (Michael Baehr)]

@ Renee - I disagree with that approach when there is, as there is in this case, a common failure affecting multiple packages. Opening a ticket for each port will just spam Trac.

I can already verify that making sure DEVELOPER_DIR is not exported (requires modifications to portutil.tcl and portconfigure.tcl) resolves the issue with C++ builds not being able to include headers from the standard library.

However, I'll need to do some git blameing to better understand why this is being done at all - appears to have been the behavior for several years, so perhaps it is now harmful with Sequoia.

[ryandesign (Ryan Carsten Schmidt)]

Implicit function declaration errors are not new in Xcode 16 and macOS 15; they've been around since Xcode 12 and macOS 10.15. Each port needs individual fixes for those issues so individual tickets are needed for those. See WimplicitFunctionDeclaration for more.

[neverpanic (Clemens Lang)]

Looks to me like a bug in the Command Line Tools:

On Sonoma with the updated CLTs:

:) cllang@gallumbits:/tmp$ cat test.cxx
#include <iostream>

using namespace std;

int main(int argc, char *argv[]) {
	cerr << "Hello World!" << endl;
}
:) cllang@gallumbits:/tmp$ DEVELOPER_DIR=/Library/Developer/CommandLineTools/ clang++ -v -std=c++17 -Wall -Werror -pedantic -o test test.cxx |& grep -A5 '#include <'
#include <...> search starts here:
 /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/c++/v1
 /Library/Developer/CommandLineTools/usr/lib/clang/16/include
 /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include
 /Library/Developer/CommandLineTools/usr/include
 /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/System/Library/Frameworks (framework directory)

Note the presence of /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/c++/v1, which contains the iostream header.

On Sequoia, contributed by AShapiro on IRC:

$ cat > testiostream.cc
#include <iostream>
using namespace std;
 
int main (int argc, char *argv[]) {
  cout << "foooooo\n";
}
$ export DEVELOPER_DIR='/Library/Developer/CommandLineTools'
$ clang++ -v testiostream.cc
Apple clang version 16.0.0 (clang-1600.0.26.3)
Target: arm64-apple-darwin24.0.0
Thread model: posix
InstalledDir: /Library/Developer/CommandLineTools/usr/bin
 "/Library/Developer/CommandLineTools/usr/bin/clang" -cc1 -triple arm64-apple-macosx15.0.0 -Wundef-prefix=TARGET_OS_ -Wdeprecated-objc-isa-usage -Werror=deprecated-objc-isa-usage -Werror=implicit-function-declaration -emit-obj -mrelax-all -dumpdir a- -disable-free -clear-ast-before-backend -disable-llvm-verifier -discard-value-names -main-file-name testiostream.cc -mrelocation-model pic -pic-level 2 -mframe-pointer=non-leaf -fno-strict-return -ffp-contract=on -fno-rounding-math -funwind-tables=1 -fobjc-msgsend-selector-stubs -target-sdk-version=15.0 -fvisibility-inlines-hidden-static-local-var -fno-modulemap-allow-subdirectory-search -target-cpu apple-m1 -target-feature +v8.5a -target-feature +aes -target-feature +crc -target-feature +dotprod -target-feature +fp-armv8 -target-feature +fp16fml -target-feature +lse -target-feature +ras -target-feature +rcpc -target-feature +rdm -target-feature +sha2 -target-feature +sha3 -target-feature +neon -target-feature +zcm -target-feature +zcz -target-feature +fullfp16 -target-abi darwinpcs -debugger-tuning=lldb -target-linker-version 1115.7.3 -v -fcoverage-compilation-dir=/Users/REDACTED -resource-dir /Library/Developer/CommandLineTools/usr/lib/clang/16 -isysroot /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk -I/usr/local/include -internal-isystem /Library/Developer/CommandLineTools/usr/bin/../include/c++/v1 -internal-isystem /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/local/include -internal-isystem /Library/Developer/CommandLineTools/usr/lib/clang/16/include -internal-externc-isystem /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include -internal-externc-isystem /Library/Developer/CommandLineTools/usr/include -Wno-reorder-init-list -Wno-implicit-int-float-conversion -Wno-c99-designator -Wno-final-dtor-non-final-class -Wno-extra-semi-stmt -Wno-misleading-indentation -Wno-quoted-include-in-framework-header -Wno-implicit-fallthrough -Wno-enum-enum-conversion -Wno-enum-float-conversion -Wno-elaborated-enum-base -Wno-reserved-identifier -Wno-gnu-folding-constant -fdeprecated-macro -fdebug-compilation-dir=/Users/REDACTED -ferror-limit 19 -stack-protector 1 -fstack-check -mdarwin-stkchk-strong-link -fblocks -fencode-extended-block-signature -fregister-global-dtors-with-atexit -fgnuc-version=4.2.1 -fno-cxx-modules -fcxx-exceptions -fexceptions -fmax-type-align=16 -fcommon -fcolor-diagnostics -clang-vendor-feature=+disableNonDependentMemberExprInCurrentInstantiation -fno-odr-hash-protocols -clang-vendor-feature=+enableAggressiveVLAFolding -clang-vendor-feature=+revert09abecef7bbf -clang-vendor-feature=+thisNoAlignAttr -clang-vendor-feature=+thisNoNullAttr -clang-vendor-feature=+disableAtImportPrivateFrameworkInImplementationError -D__GCC_HAVE_DWARF2_CFI_ASM=1 -o /var/folders/k6/83jnw8qs48ddw8b71h8gnz480000gn/T/testiostream-0c16ee.o -x c++ testiostream.cc
clang -cc1 version 16.0.0 (clang-1600.0.26.3) default target arm64-apple-darwin24.0.0
ignoring nonexistent directory "/usr/local/include"
ignoring nonexistent directory "/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/local/include"
ignoring nonexistent directory "/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/Library/Frameworks"
#include "..." search starts here:
#include <...> search starts here:
 /Library/Developer/CommandLineTools/usr/bin/../include/c++/v1
 /Library/Developer/CommandLineTools/usr/lib/clang/16/include
 /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include
 /Library/Developer/CommandLineTools/usr/include
 /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/System/Library/Frameworks (framework directory)
End of search list.
testiostream.cc:1:10: fatal error: 'iostream' file not found
    1 | #include <iostream>
      |          ^~~~~~~~~~
1 error generated.

Note the lack of /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/c++/v1 in the list of include directories.

With DEVELOPER_DIR unset, Xcode is used, which works correctly:

[…]
#include <...> search starts here:
 /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/c++/v1
 /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/clang/16/include
 /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include
 /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include
 /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/System/Library/Frameworks (framework directory)
End of search list.
[…]

[neverpanic (Clemens Lang)]

That's now ​FB15152777.

[jmroot (Joshua Root)]

The best workaround for now may be to not install the CLTs and only use Xcode.

[cjones051073 (Chris Jones)]

Clemens - That FB link does not work for me, I think only you can view it, so please post any feedback back here.

[jmroot (Joshua Root)]

I disagree with that approach when there is, as there is in this case, a common failure affecting multiple packages. Opening a ticket for each port will just spam Trac.

If there is a common underlying issue, that makes sense, but there should still be separate tickets for separate issues. This one can be for the CLTs failing to find C++ headers. Please open separate individual tickets for implicit int errors.

[neverpanic (Clemens Lang)]

Replying to cjones051073:

Clemens - That FB link does not work for me, I think only you can view it, so please post any feedback back here.

I'm aware of that. I just shared it just in case some Apple engineer reads this and wants to raise it internally, in which case they'd probably need this number.

[johnjxw (John Jiang)]

Replying to jmroot:

The best workaround for now may be to not install the CLTs and only use Xcode.

Thanks, this workaround worked for me. Simply sudo rm -r /Library/Developer/CommandLineTools and install Xcode App. Don't forget to clean failed ports you tried.

[SaintBol]

Still have some problems with lftp (using Xcode clang). Will open a separate ticket if needed, if it's specific to this port...

Some logs:

:info:build lftp_ssl.cc:783:47: error: invalid application of 'sizeof' to an incomplete type 'X509_OBJECT' (aka 'x509_object_st')
:info:build lftp_ssl.cc:789:5: error: use of undeclared identifier 'X509_OBJECT_free_contents'; did you mean 'X509_OBJECT_up_ref_count'?
:info:build lftp_ssl.cc:795:10: error: member access into incomplete type 'X509_OBJECT' (aka 'x509_object_st')
:info:build lftp_ssl.cc:1214:43: error: member access into incomplete type 'X509_REVOKED' (aka 'x509_revoked_st')

[jmroot (Joshua Root)]

@SaintBol: Yes, that's a different issue, so please open a separate ticket for it.

[ATL-Flaneur (Andreas Yankopolus)]

Replying to johnjxw:

Replying to jmroot:

The best workaround for now may be to not install the CLTs and only use Xcode.

Thanks, this workaround worked for me. Simply sudo rm -r /Library/Developer/CommandLineTools and install Xcode App. Don't forget to clean failed ports you tried.

Installing db48 goes a little farther after I do this, but then stops when it can't find sys/types.h.

See #70761

[reneeotten (Renee Otten)]

Replying to neverpanic:

Looks to me like a bug in the Command Line Tools:

On Sequoia with updated XCode and CLT I see:

❯ cat testiostream.cc
#include <iostream>
using namespace std;

int main (int argc, char *argv[]) {
  cout << "foooooo\n";
}

❯ export DEVELOPER_DIR='/Library/Developer/CommandLineTools'

❯ which clang++
/usr/bin/clang++

❯ clang++ -v testiostream.cc
Apple clang version 16.0.0 (clang-1600.0.26.3)
Target: x86_64-apple-darwin24.0.0
Thread model: posix
InstalledDir: /Library/Developer/CommandLineTools/usr/bin
ignoring nonexistent directory "/Library/Developer/CommandLineTools/usr/bin/../include/c++/v1"
 "/Library/Developer/CommandLineTools/usr/bin/clang" -cc1 -triple x86_64-apple-macosx15.0.0 -Wundef-prefix=TARGET_OS_ -Wdeprecated-objc-isa-usage -Werror=deprecated-objc-isa-usage -Werror=implicit-function-declaration -emit-obj -mrelax-all -dumpdir a- -disable-free -clear-ast-before-backend -disable-llvm-verifier -discard-value-names -main-file-name testiostream.cc -mrelocation-model pic -pic-level 2 -mframe-pointer=all -fno-strict-return -ffp-contract=on -fno-rounding-math -funwind-tables=2 -target-sdk-version=15.0 -fvisibility-inlines-hidden-static-local-var -fno-modulemap-allow-subdirectory-search -target-cpu penryn -tune-cpu generic -debugger-tuning=lldb -target-linker-version 1115.7.3 -v -fcoverage-compilation-dir=/Users/renee -resource-dir /Library/Developer/CommandLineTools/usr/lib/clang/16 -isysroot /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk -I/usr/local/include -internal-isystem /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/c++/v1 -internal-isystem /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/local/include -internal-isystem /Library/Developer/CommandLineTools/usr/lib/clang/16/include -internal-externc-isystem /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include -internal-externc-isystem /Library/Developer/CommandLineTools/usr/include -Wno-reorder-init-list -Wno-implicit-int-float-conversion -Wno-c99-designator -Wno-final-dtor-non-final-class -Wno-extra-semi-stmt -Wno-misleading-indentation -Wno-quoted-include-in-framework-header -Wno-implicit-fallthrough -Wno-enum-enum-conversion -Wno-enum-float-conversion -Wno-elaborated-enum-base -Wno-reserved-identifier -Wno-gnu-folding-constant -fdeprecated-macro -fdebug-compilation-dir=/Users/renee -ferror-limit 19 -stack-protector 1 -fstack-check -mdarwin-stkchk-strong-link -fblocks -fencode-extended-block-signature -fregister-global-dtors-with-atexit -fgnuc-version=4.2.1 -fno-cxx-modules -fcxx-exceptions -fexceptions -fmax-type-align=16 -fcommon -fcolor-diagnostics -clang-vendor-feature=+disableNonDependentMemberExprInCurrentInstantiation -fno-odr-hash-protocols -clang-vendor-feature=+enableAggressiveVLAFolding -clang-vendor-feature=+revert09abecef7bbf -clang-vendor-feature=+thisNoAlignAttr -clang-vendor-feature=+thisNoNullAttr -clang-vendor-feature=+disableAtImportPrivateFrameworkInImplementationError -D__GCC_HAVE_DWARF2_CFI_ASM=1 -o /var/folders/qn/5bwbztqn3kqd3sd888hb_llm0000gn/T/testiostream-21103f.o -x c++ testiostream.cc
clang -cc1 version 16.0.0 (clang-1600.0.26.3) default target x86_64-apple-darwin24.0.0
ignoring nonexistent directory "/usr/local/include"
ignoring nonexistent directory "/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/local/include"
ignoring nonexistent directory "/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/Library/Frameworks"
#include "..." search starts here:
#include <...> search starts here:
 /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/c++/v1
 /Library/Developer/CommandLineTools/usr/lib/clang/16/include
 /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include
 /Library/Developer/CommandLineTools/usr/include
 /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/System/Library/Frameworks (framework directory)
End of search list.
 "/Library/Developer/CommandLineTools/usr/bin/ld" -demangle -lto_library /Library/Developer/CommandLineTools/usr/lib/libLTO.dylib -no_deduplicate -dynamic -arch x86_64 -platform_version macos 15.0.0 15.0 -syslibroot /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk -mllvm -enable-linkonceodr-outlining -o a.out -L/usr/local/lib /var/folders/qn/5bwbztqn3kqd3sd888hb_llm0000gn/T/testiostream-21103f.o -lc++ -lSystem /Library/Developer/CommandLineTools/usr/lib/clang/16/lib/darwin/libclang_rt.osx.a

the directory is present in the include and so far all ports are installing just fine (the port migrate is still running as we speak).

As suggested by Josh in the e-mail thread here some additional info that perhaps could be helpful:

❯ pkgutil --pkg-info=com.apple.pkg.{CLTools_Executables,CLTools_Base,DeveloperToolsCLI,DeveloperToolsCLILeo} 2>/dev/null | sed -n 's/^version: //p'
16.0.0.0.1.1724870825

❯ sh -c 'echo "macOS $(sw_vers -productVersion) $(sw_vers -buildVersion) $(uname -m)"; xcode=$(xcodebuild -version 2>/dev/null); if [ $? == 0 ]; then echo "$(echo "$xcode" | awk '\''NR==1{x=$0}END{print x" "$NF}'\'')"; else echo "Command Line Tools $(pkgutil --pkg-info=com.apple.pkg.CLTools_Executables | awk '\''/version:/ {print $2}'\'')"; fi' | tee /dev/tty
macOS 15.0 24A335 x86_64
Command Line Tools 16.0.0.0.1.1724870825

Not sure whether it can be architecture related; most (all?) of the reports I have seen so far are on ARM.

[neverpanic (Clemens Lang)]

The version number for the command line tools is the same as the one on IRC where it was buggy, so maybe something non-deterministic is going on here?

[SaintBol]

Is xcode-select -p useful in this case, or not ?

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

% xcode-select -p                              
/Applications/Xcode.app/Contents/Developer

[ryandesign (Ryan Carsten Schmidt)]

xcode-select -p is useful for telling you what Xcode or command line tools you have selected. MacPorts will use the command line tools unless use_xcode yes is set in the portfile.

[jmroot (Joshua Root)]

Is everyone affected by this using Apple Silicon hardware?

[SaintBol]

Here is a 2019 MBP (the last x86_64 one), with buggy commandlinetools freshly removed as workaround:

% sysctl machdep.cpu.brand_string
machdep.cpu.brand_string: Intel(R) Core(TM) i9-9980HK CPU @ 2.40GHz

% sysctl kern.version            
kern.version: Darwin Kernel Version 24.0.0: Mon Aug 12 20:54:30 PDT 2024; root:xnu-11215.1.10~2/RELEASE_X86_64

% clang --version             
Apple clang version 16.0.0 (clang-1600.0.26.3)
Target: x86_64-apple-darwin24.0.0
Thread model: posix
InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin

[byronhicks (Byron Hicks)]

Both my Mac mini and MacBook air are affected by this, and both are Apple M1 CPU.

[jmroot (Joshua Root)]

OK, thanks. Still no clue why only some users are affected then.

[nortcele]

I don't know if I'm affected by the problem as I haven't tried to migrate ports.

My MacBookPro (M1 Pro), is updated to Sequoia and I have Xcode 16 + CLT.

macOS 15.0 24A335 arm64
Command Line Tools 16.0.0.0.1.1724870825

If I compile the test.cxx file either with

DEVELOPER_DIR=/Library/Developer/CommandLineTools/ clang++ -v -std=c++17 -Wall -Werror -pedantic -o test test.cxx |& grep -A5 '#include <'

or

export DEVELOPER_DIR='/Library/Developer/CommandLineTools'
clang++ -v test.cxx

the compilation is successful and the code works.

I updated my ports before updating to Sequoia.

[jmroot (Joshua Root)]

Replying to nortcele:

If I compile the test.cxx file either with

DEVELOPER_DIR=/Library/Developer/CommandLineTools/ clang++ -v -std=c++17 -Wall -Werror -pedantic -o test test.cxx |& grep -A5 '#include <'

the compilation is successful and the code works.

If compilation succeeds then you are not affected. The definitive indicator that it's working correctly is that the verbose output shows /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/c++/v1 in the include search paths rather than /Library/Developer/CommandLineTools/usr/bin/../include/c++/v1.

[nortcele]

Here the output.

tmp % DEVELOPER_DIR=/Library/Developer/CommandLineTools/ clang++ -v -std=c++17 -Wall -Werror -pedantic -o test test.cxx |& grep -A5 '#include <'

#include <...> search starts here:
 /Library/Developer/CommandLineTools/usr/bin/../include/c++/v1
 /Library/Developer/CommandLineTools/usr/lib/clang/16/include
 /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include
 /Library/Developer/CommandLineTools/usr/include
 /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/System/Library/Frameworks (framework directory)

[nortcele]

And here is test.cxx

#include <iostream>

using namespace std;

int main(int argc, char *argv[]) {
	cerr << "Hello World!" << endl;
}

[kencu (Ken)]

On an M! Mac I upgraded the CLTs and got the same error listed here.

I downloaded the current Xcode 16 CLTs from ​https://developer.apple.com/download/all/ and installed them and got the same error.

I downloaded the new Xcode 16.1 beta CLTs from ​https://developer.apple.com/download/all/ and installed them and got the same error.

Then I blew out the CLTs with sudo rm -rf /Library/Developer/CommandLineTools and installed the current CLTs (Xcode 16, not Xcode 16.1 beta) and then everything works fine.

Go figure.

[kencu (Ken)]

% sudo rm -rf /Library/Developer/CommandLineTools

Install CLTs (from the DMG from Apple as above)

% DEVELOPER_DIR=/Library/Developer/CommandLineTools/ clang++ -v -std=c++17 -Wall -Werror -pedantic -o test test.cxx
Apple clang version 16.0.0 (clang-1600.0.26.3)
Target: arm64-apple-darwin24.0.0
Thread model: posix
InstalledDir: /Library/Developer/CommandLineTools/usr/bin
ignoring nonexistent directory "/Library/Developer/CommandLineTools/usr/bin/../include/c++/v1"
 "/Library/Developer/CommandLineTools/usr/bin/clang" -cc1 -triple arm64-apple-macosx15.0.0 -Wundef-prefix=TARGET_OS_ -Wdeprecated-objc-isa-usage -Werror=deprecated-objc-isa-usage -Werror=implicit-function-declaration -emit-obj -mrelax-all -dumpdir test- -disable-free -clear-ast-before-backend -disable-llvm-verifier -discard-value-names -main-file-name test.cxx -mrelocation-model pic -pic-level 2 -mframe-pointer=non-leaf -fno-strict-return -ffp-contract=on -fno-rounding-math -funwind-tables=1 -fobjc-msgsend-selector-stubs -target-sdk-version=15.0 -fvisibility-inlines-hidden-static-local-var -fno-modulemap-allow-subdirectory-search -target-cpu apple-m1 -target-feature +v8.5a -target-feature +aes -target-feature +crc -target-feature +dotprod -target-feature +fp-armv8 -target-feature +fp16fml -target-feature +lse -target-feature +ras -target-feature +rcpc -target-feature +rdm -target-feature +sha2 -target-feature +sha3 -target-feature +neon -target-feature +zcm -target-feature +zcz -target-feature +fullfp16 -target-abi darwinpcs -debugger-tuning=lldb -target-linker-version 1115.7.3 -v -fcoverage-compilation-dir=/Users/cunningh -resource-dir /Library/Developer/CommandLineTools/usr/lib/clang/16 -isysroot /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk -I/usr/local/include -internal-isystem /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/c++/v1 -internal-isystem /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/local/include -internal-isystem /Library/Developer/CommandLineTools/usr/lib/clang/16/include -internal-externc-isystem /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include -internal-externc-isystem /Library/Developer/CommandLineTools/usr/include -Wall -Werror -Wno-reorder-init-list -Wno-implicit-int-float-conversion -Wno-c99-designator -Wno-final-dtor-non-final-class -Wno-extra-semi-stmt -Wno-misleading-indentation -Wno-quoted-include-in-framework-header -Wno-implicit-fallthrough -Wno-enum-enum-conversion -Wno-enum-float-conversion -Wno-elaborated-enum-base -Wno-reserved-identifier -Wno-gnu-folding-constant -pedantic -std=c++17 -fdeprecated-macro -fdebug-compilation-dir=/Users/cunningh -ferror-limit 19 -stack-protector 1 -fstack-check -mdarwin-stkchk-strong-link -fblocks -fencode-extended-block-signature -fregister-global-dtors-with-atexit -fgnuc-version=4.2.1 -fno-cxx-modules -fcxx-exceptions -fexceptions -fmax-type-align=16 -fcommon -fcolor-diagnostics -clang-vendor-feature=+disableNonDependentMemberExprInCurrentInstantiation -fno-odr-hash-protocols -clang-vendor-feature=+enableAggressiveVLAFolding -clang-vendor-feature=+revert09abecef7bbf -clang-vendor-feature=+thisNoAlignAttr -clang-vendor-feature=+thisNoNullAttr -clang-vendor-feature=+disableAtImportPrivateFrameworkInImplementationError -D__GCC_HAVE_DWARF2_CFI_ASM=1 -o /var/folders/97/nn3swcb52bg003_4bctdbyd80000gn/T/test-6b1fdb.o -x c++ test.cxx
clang -cc1 version 16.0.0 (clang-1600.0.26.3) default target arm64-apple-darwin24.0.0
ignoring nonexistent directory "/usr/local/include"
ignoring nonexistent directory "/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/local/include"
ignoring nonexistent directory "/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/Library/Frameworks"
#include "..." search starts here:
#include <...> search starts here:
 /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/c++/v1
 /Library/Developer/CommandLineTools/usr/lib/clang/16/include
 /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include
 /Library/Developer/CommandLineTools/usr/include
 /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/System/Library/Frameworks (framework directory)
End of search list.
 "/Library/Developer/CommandLineTools/usr/bin/ld" -demangle -lto_library /Library/Developer/CommandLineTools/usr/lib/libLTO.dylib -no_deduplicate -dynamic -arch arm64 -platform_version macos 15.0.0 15.0 -syslibroot /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk -mllvm -enable-linkonceodr-outlining -o test -L/usr/local/lib /var/folders/97/nn3swcb52bg003_4bctdbyd80000gn/T/test-6b1fdb.o -lc++ -lSystem /Library/Developer/CommandLineTools/usr/lib/clang/16/lib/darwin/libclang_rt.osx.a

[wdormann]

Replying to kencu:

Then I blew out the CLTs with sudo rm -rf /Library/Developer/CommandLineTools and installed the current CLTs (Xcode 16, not Xcode 16.1 beta) and then everything works fine.

OK, so this is interesting. I attempted this (removing the directory) and then installing CLT via xcode-select --install on my system that has Xcode 16 installed. The result of this?

Error: The installed version of the Command Line Tools for Xcode (15.3.0.0.1.1708646388) is too old to use on the installed OS version. Please install version 16 or later on macOS 15.
Error: Follow https://guide.macports.org/#project.tickets if you believe there is a bug.
Error: Processing of port pcre failed

So oddly the xcode-select tool (from Xcode 16? xcode-select version 2409), installs CLT 15.3.0.0.1.1708646388? In the past I recall using xcode-select (I think? It's a bit of a blur to me by now) to upgrade from the Terminal CLT 15.3.0.0.1.1708646388 to CLT 16, and that worked well enough to get MacPorts working, though in a semi-broken way as outlined in this bug.

I don't have the environment available to me at the moment, but I wonder if somehow my broken state was encountered because the system somehow had both CLT 16 installed, but also remnants of the prior CLT 15.3.0.0.1.1708646388?

Anyway, I was able to get MacPorts fully working by:

1. sudo rm -rf /Library/Developer/CommandLineTools
2. Install CLT 16 from the DMG available from ​https://developer.apple.com/download/all/ (Command_Line_Tools_for_Xcode_16.dmg)

After this, everything is working fine.

[kencu (Ken)]

Glad the fix worked for you too.

My failing upgraded CLTs showed the exact same version of clang as the version that now works when installed freshly.

Some remnant left behind in the upgraded CLTs would appear to be causing the issue, fixed by the blowout and clean reinstall.

[hwinkler (Hugh Winkler)]

After upgrading to Sequoia and the Command Line Tools to 16, my port install git failed building dependencies: first cmake-bootstrap, then, after removing the sudo rm -rf /Library/Developer/CommandLineTools, db48.

I had not upgrade my XCode, however. After upgrading to XCode 16, and having removed /Library/Developer/CommandLineTools, building and installing the git port succeeded.

[SaintBol]

By the way, is CommandLineTools of any use if Xcode is installed, actually ?

[kencu (Ken)]

simply removing /Library/Developer/CommandLineTools will cause a number of ports to be built with references hard-coded into Xcode.

This will be a problem in the medium to longer term. GCC and other things will be built incorreclty.

However, removing /Library/Developer/CommandLineTools and then reinstalling the Command Line Tools (I used the DMG, as did the other user above who found success) puts things into their ocrrect places and everything works.

So that is a better solution, assuming it works for everyone.

I haven't tried removing /Library/Developer/CommandLineTools and then reinstalling the CLTs using the xcode-select method. Perhaps it works as well. A user above said it didn't work for him, but there is some indication there of a mixup in versions.

[jmroot (Joshua Root)]

Thanks Ken. With that information I was able to create working and non-working CLT installations and recursively diff them. It turns out the problematic leftover is the /Library/Developer/CommandLineTools/usr/include/c++ directory, which doesn't exist in a working installation, and when deleted from a broken one makes it work.

[SaintBol]

Therefore the issue seems to be in the Apple CommandLineTools Updater

[wdormann]

Replying to jmroot:

It turns out the problematic leftover is the /Library/Developer/CommandLineTools/usr/include/c++ directory, which doesn't exist in a working installation, and when deleted from a broken one makes it work.

Courtesy of a Time Machine backup, I can confirm that in my case, this was also the case. /Library/Developer/CommandLineTools/usr/include/c++ was present:

$ find c++/
c++/
c++/v1
c++/v1/experimental
c++/v1/experimental/any
c++/v1/experimental/chrono
c++/v1/experimental/numeric
c++/v1/experimental/optional
c++/v1/experimental/ratio
c++/v1/experimental/string_view
c++/v1/experimental/system_error
c++/v1/experimental/tuple
c++/v1/__cxx_version
c++/v1/__functional_03
c++/v1/__functional_base_03
c++/v1/__sso_allocator

Not a lot there, but presumably its mere presence (without the relevant includes that some things are looking for) is enough to confuse the build process for some packages.

Aside from fixing this MacPorts problem, deleting that directory also cleared up about 1.5GB of disk space as well, as the old directory also had SDK directories for MacOSX 10.14, 10.15, 11.1, and 12.1.

[jmroot (Joshua Root)]

Replying to wdormann:

Not a lot there, but presumably its mere presence (without the relevant includes that some things are looking for) is enough to confuse the build process for some packages.

Its existence seems to actually make the compiler look there for C++ headers instead of the correct place inside the SDK.

[mouse07410 (Mouse)]

I haven't tried removing /Library/Developer/CommandLineTools and then reinstalling the CLTs using the xcode-select method. Perhaps it works as well. A user above said it didn't work for him, but there is some indication there of a mixup in versions.

I did not have a good experience doing this. I'm pretty sure there was no version mixup in my setup. Via .dmg seems the only reliable method to install CLT, though I wish that Macports would not insist on CLT in presence of the "full" Xcode.

[EvilJordan (Jordan Holberg)]

I removed only the /Library/Developer/CommandLineTools/usr/include/c++ directory and reran port restore --last and things seem to be ok!

Not sure what the long-term ramifications are, but... yay?

UPDATE: ok, that super-didn't work. Lots of failures on later ports. Going to try again by removing CommandLineTools completely.

[Marius Schamschula <mschamschula@…>]

In 33b99775d9b2ec126dea659e794c4440c29164b2/macports-ports (master):

lftp: remove Sequoia C++ workaround

See: #70750#comment:42

[ATL-Flaneur (Andreas Yankopolus)]

Replying to EvilJordan:

I removed only the /Library/Developer/CommandLineTools/usr/include/c++ directory and reran port restore --last and things seem to be ok!

Not sure what the long-term ramifications are, but... yay?

UPDATE: ok, that super-didn't work. Lots of failures on later ports. Going to try again by removing CommandLineTools completely.

Port alex fails to build if /Library/Developer/CommandLineTools/ isn't present.

[shpokas]

Unfortunately, complete removal of CLT with

 rm -fr /Library/Developer/CommandLineTools/

and reinstallation from DMG does not work for me.

I have two Apple Silicon M2 powered machines and on one port compilation works fine even with folder

/Library/Developer/CommandLineTools/usr/include/c++

being present but does not work on the other one where after CLT reinstallation folder

 /Library/Developer/CommandLineTools/usr/include/c++

is not present.

The port that fails is db48, error is

   bc++ -isysroot/Library/Developer/CommandLineTools/SDKs/MacOSX15.sdk -arch arm64 ../dist/../cxx/cxx_logc.cpp
   :info:build In file included from ../dist/../cxx/cxx_db.cpp:13:
   :info:build ./db_cxx.h:59:10: fatal error: 'iostream.h' file not found
   :info:build    59 | #include <iostream.h>
   :info:build       |          ^~~~~~~~~~~~

File iostream.h is present on both machines. On the erratic machine:

$ find /Library/Developer/CommandLineTools/ -iname iostream.h | xargs ls -l
-rw-r--r--  1 root  wheel  21722 Apr 25 06:09 /Library/Developer/CommandLineTools//SDKs/MacOSX14.5.sdk/System/Library/Frameworks/Kernel.framework/Versions/A/Headers/IOKit/stream/IOStream.h
-rw-r--r--  1 root  wheel  21722 Aug 13 06:56 /Library/Developer/CommandLineTools//SDKs/MacOSX15.0.sdk/System/Library/Frameworks/Kernel.framework/Versions/A/Headers/IOKit/stream/IOStream.h

Using CLT on both machines.

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

And version is

$ clang --version  
Apple clang version 16.0.0 (clang-1600.0.26.3)
Target: arm64-apple-darwin24.0.0
Thread model: posix
InstalledDir: /Library/Developer/CommandLineTools/usr/bin

[SaintBol]

But does it work with Xcode installed and up-to-date, and CommandLineTools removed ?

[kencu (Ken)]

There can (and will) be a number of other issues that come up with various other ports. But as far as we can tell the c++ compiler in the CLTs does work with a clean installation of the CLTs from the DMG, whereas it does not work with an upgraded installation of the CLTs. (modulo Josh's specific fix).

If you just delete the CLTs and build everything using Xcode, then some things will be hard coded against the SDKs in Xcode. This will work for a while, or maybe not, as all of MacPorts has been set up to use the SDKs in /Library/Developer/CommandLineTools/SDKS and base and Portfiles are not written to use Xcode.

After you do the fixes here to make the CLTs work, if you find issues with certain ports that don't build, just post up tickets (or add to existing tickets) and things will be sorted out.

[shpokas]

Replying to SaintBol:

But does it work with Xcode installed and up-to-date, and CommandLineTools removed ?

Yes, it does work after installing XCode and uninstalling and cleaning (port uninstall db48 && port clean db48), then installing db48 again.

[jmroot (Joshua Root)]

Replying to EvilJordan:

UPDATE: ok, that super-didn't work. Lots of failures on later ports. Going to try again by removing CommandLineTools completely.

What kind of failures? If it's not a standard C++ header failing to be found, please open a new ticket.

[jmroot (Joshua Root)]

Replying to shpokas:

Yes, it does work after installing XCode and uninstalling and cleaning (port uninstall db48 && port clean db48), then installing db48 again.

Yeah, you definitely have to clean after making any kind of fix to your toolchain, since the configure step could have made any number of wrong decisions due to the brokenness.

[ldionne (Louis Dionne)]

Hi, I work on the C++ Standard Library and I am currently investigating this issue. The workaround that was mentioned by many people (clean reinstall of the CLTs) should definitely fix this issue, and so would removing all the contents of /Library/Developer/CommandLineTools/usr/include/c++. The issue seems to be that stale headers were present in that directory, leading Clang to think that the C++ Standard Library headers to use were in that directory. However, the canonical location for C++ Standard Library headers nowadays (and for a few years) has been inside the SDK (/Library/Developer/CommandLineTools/SDKs/MacOSX14.5.sdk/usr/include/c++/v1).

It would be really helpful if someone who can reproduce the problem locally could share the contents of their /Library/Developer/CommandLineTools/usr/include/c++ directory. It seems like not everyone has the same content and I have been unable to reproduce this issue when installing the CLTs from a clean install, making it a bit challenging to investigate.

[wdormann]

I shared a list of the filenames from my (problematic) system above. Do you need an actual tarball of the directory?

$ find c++/
c++/
c++/v1
c++/v1/experimental
c++/v1/experimental/any
c++/v1/experimental/chrono
c++/v1/experimental/numeric
c++/v1/experimental/optional
c++/v1/experimental/ratio
c++/v1/experimental/string_view
c++/v1/experimental/system_error
c++/v1/experimental/tuple
c++/v1/__cxx_version
c++/v1/__functional_03
c++/v1/__functional_base_03
c++/v1/__sso_allocator

[Iritscen]

Personally I only have the files…

 c++/v1/__functional_03
 c++/v1/__functional_base_03
 c++/v1/__sso_allocator

…in my directory and it's enough to cause the same issue that everyone else here is having. About to try wiping and reinstalling the CLT, but I made a zip backup of this folder in case it's of interest to anyone.

[jmroot (Joshua Root)]

All I had on my system when I reproduced the issue was one file dating from 2020:

% ls -lR /Library/Developer/CommandLineTools/usr/include/c++ 
total 0
drwxr-xr-x  3 root  wheel  96 12 Dec  2023 v1

/Library/Developer/CommandLineTools/usr/include/c++/v1:
total 32
-rw-r--r--  1 root  wheel  14688 22 Dec  2020 __cxx_version

[ldionne (Louis Dionne)]

Replying to wdormann:

I shared a list of the filenames from my (problematic) system above. Do you need an actual tarball of the directory?

Yes, that would be useful!

Indeed, the mere presence of /Library/Developer/CommandLineTools/usr/include/c++/v1 will trip up the compiler. Clang looks at whether that directory exists, and if so, it tries to use the headers at that location. When the headers in that location are incomplete/stale, things break.

[wdormann]

Sample /Library/Developer/CommandLineTools/usr/include/c++ contents

[kencu (Ken)]

Replying to shpokas:

So this is "case solved" for me.

For the moment perhaps.

But you will likely find things will soon be oddly broken and dysfunctional and will need to be rebuilt, as the SDK location that MacPorts' base and Portfiles are written to use is:

/Library/Developer/CommandLineTools/SDKs