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

[SaintBol]

(For new arrivals not wanting to read through all the ticket comments, the fix is here: ProblemHotlist#clts16)

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. So this is "case solved" for me.

[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 very 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

So I would suggest you install the CLTs.

[linuxgemini (İlteriş Eroğlu)]

Heya,

Replying to ldionne:

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.

I uploaded a text tree output of that folder to ​https://paste.debian.net/plainh/c9fd06d1.

The setup is:

macOS 14.7 23H124 arm64

Xcode 16.0 16A242d

[ldionne (Louis Dionne)]

Thanks everyone. What's wild to me is that the contents are different for everyone, and they don't seem to make any sense. It's like a random subset of the old libc++ headers stays at that location after an update. We're looking into it, but for the time being the official workaround would be to remove c++/v1 directory entirely.

[wdormann]

I suspect that the contents of the directory are artifacts of what versions of CLT were ever installed. So the contents of the directory will depend on what versions of the CLT were installed in the past. If installing new CLT doesn't clean up old directory contents, then it's a crap shoot as to what the actual contents are.

However the mere presence of the directory (regardless of contents) will break some ports.

[the-man-machine (Maxim Byshevski-Konopko)]

Caught the same problem, but, unfortunately, none of the workarounds in this ticket worked for me. macOS 15, latest Xcode from AppStore.

Tried:

• removing /Library/Developer/CommandLineTools and rebuilding everything without it (db48 doesn't find sys/types.h)
• reinstalling Command Line Tools from the pkg and rebuilding everything (db48 now cannot find iostream.h, which is, uhh. what?).

tmux, however, breaks in a different way, and says error: call to undeclared function 'TAILQ_REPLACE'. But most of the ports build fine (no matter without CLT or after manually reinstalling CLT).

---

WHAT. I didn't change anything, did port clean db48 and port -d install db48, and it worked now. I'm sorry. Will continue to investigate.

[SaintBol]

Replying to the-man-machine:

Caught the same problem, but, unfortunately, none of the workarounds in this ticket worked for me. macOS 15, latest Xcode from AppStore.

You must cleanup the failed-to-compile ports once you remove or fresh-reinstall the CLI Tools. Go for sudo port reclaim, yes to all.

[the-man-machine (Maxim Byshevski-Konopko)]

Replying to SaintBol:

Replying to the-man-machine:

Caught the same problem, but, unfortunately, none of the workarounds in this ticket worked for me. macOS 15, latest Xcode from AppStore.

You must cleanup the failed-to-compile ports once you remove or fresh-reinstall the CLI Tools. Go for sudo port reclaim, yes to all.

Oh, thanks! I guess the manual port clean does the same?

[ldionne (Louis Dionne)]

The issue discussed in this thread will break even the most basic C++ program. Try this on the command-line:

$ cat <<EOF | clang++ -xc++ - -fsyntax-only
#include <iostream>
int main() { }
EOF

If that works (i.e. doesn't output any error), then whatever issue you're running into when building a package is not the same issue as what's being discussed in this thread. If that fails with some issue like a header not being found, then that's the issue discussed in this thread.

[hnarayanan (Harish Narayanan)]

I am in the same boat as many other people (M1 Max from 2021).

[~] xcode-select -p
/Applications/Xcode.app/Contents/Developer

I have tried to:

1. Delete Command Line Tools (with sudo rm -fr /Library/Developer/CommandLineTools) and reinstall via xcode-select --install, and this installed a version that was deemed too old and needed to be updated first (presumably from 15.x to 16.0).

2.Delete Command Line Tools and reinstall via xcode-select --install, and this installed a version from the DMG (16.0) on the Apple Developer Website.

Both of these don't do anything, and I still end up with the same error on the most basic C++ program.

[~] clang++ -o main main.cc                                                              
main.cc:1:9: fatal error: 'iostream.h' file not found
    1 | #include<iostream.h>
      |         ^~~~~~~~~~~~
1 error generated.

I feel the output of xcode-select -p implies none of this is being used at all in my case?

[wdormann]

In my testing, installing CLT via xcode-select doesn't get me the right stuff that I need. Try deleting /Library/Developer/CommandLineTools and then installing CLT via the DMG only.

[Iritscen]

Yes, I didn't trust xcode-select after reading kencu's posts above, so I downloaded the CLT directly from ​https://developer.apple.com/download/all/ . That, plus uninstalling and reinstalling MacPorts itself to make sure everything that failed was totally cleared out, fixed my port building issues.

[hnarayanan (Harish Narayanan)]

I have deleted /Library/Developer/CommandLineTools and reinstalled it with the DMG only, and I cannot get things to work.

wdormann or Iritscen, could you please share with me the output of your xcode-select -p? i.e. should that output be pointing to /Library/Developer/CommandLineTools?

[Iritscen]

xcode-select returns /Applications/Xcode.app/Contents/Developer for me.

You might want to try uninstalling MacPorts per these instructions, then reinstalling: ​https://guide.macports.org/chunked/installing.macports.uninstalling.html

[hnarayanan (Harish Narayanan)]

Thank you all. The issue came down to needing to clean before rebuilding broken packages, a step I had missed. This was pointed out to me by jmroot on another thread.

[jlg89]

I'm on M1 hardware. Another confirmation of the fix.

Do the stuff in comment:37

"port clean" whichever port(s) failed.

"port install" whichever port(s) failed.

[dagui0 (Daekyu Lee)]

Finally I succeded to build c++ ports.

1. Uninstall Xcode

It was upgraded from 15 to 16. There was Developer folder under /Applications/XCode.app/. It seems to make confused to macports. So I decided to uninstall and clean install.

2. Uninstall Command Line Tools

'xcode-select --install' still installs 15.x command line tools. So I had to remove it. sudo rm -rf /Library/Developer/CommandLineTools

3. Re install Command Line Tools

Download for Coomand Line Tools for Xcode 16 and Install it. ​https://developer.apple.com/download/all/?q=for%20Xcode

4. Build ports

Even I do not install Xcode, building port is possible. sudo port install cmake

[kencu (Ken)]

Replying to dagui0:

4. Build ports

Even I do not install Xcode, building port is possible.

Although many ports build with just the CLTs installed, some ports require a full Xcode installation to build.

[lcvisser (Ludo Visser)]

I'm still stuck. I got here after trying to install wget, which failed because lerc wouldn't build, failing with various

fatal error: 'algorithm' file not found
   24 | #include <algorithm>

The strange thing is (or at least, the part I don't understand): I can build C++ applications just fine. The sample provided in comment:75 compiles without error, so does all my normal work (although I use CMake, which may set some paths differently).

I too have an apparently stale/incomplete /Library/Developer/CommandLineTools/usr/include/c++/v1:

% ls -l /Library/Developer/CommandLineTools/usr/include/c++/v1 
total 24
drwxr-xr-x   3 root  wheel    96 Oct 19  2022 __bit
drwxr-xr-x   5 root  wheel   160 Oct 19  2022 __charconv
drwxr-xr-x   9 root  wheel   288 Oct 19  2022 __compare
drwxr-xr-x  24 root  wheel   768 Oct 19  2022 __concepts
-rw-r--r--   1 root  wheel  3142 Oct 18  2022 __cxxabi_config.h
drwxr-xr-x  14 root  wheel   448 Oct 23  2023 __format
drwxr-xr-x   4 root  wheel   128 Oct 23  2023 __functional
drwxr-xr-x   3 root  wheel    96 Oct 23  2023 __iterator
drwxr-xr-x   9 root  wheel   288 Oct 23  2023 __ranges
drwxr-xr-x   3 root  wheel    96 Oct 23  2023 __utility
-rw-r--r--   1 root  wheel  7215 Oct 18  2022 cxxabi.h

But again, this is not a problem if I compile my own work.

Caveat here is that I'm on a corporate machine: I have built MacPorts from source and build all ports from source, so I'm used to having to solve the occasional problem, but this has me stumped so far. I did get an Xcode update pushed last week. I have Xcode 16.0 (16A242d) and clang version 16.0.0 (clang-1600.0.26.3) on macOS Sonoma 14.5 (23F79)

% clang --version
Apple clang version 16.0.0 (clang-1600.0.26.3)
Target: arm64-apple-darwin23.5.0
Thread model: posix
InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin
% xcode-select -p
/Applications/Xcode.app/Contents/Developer

I don't have administrative rights, but I can ask IT for an admin to do things if asked nicely. Should I ask to

1. sudo rm -rf /Library/Developer/CommandLineTools/usr/include/c++/v1 ?
2. Reinstall CLT?
3. Reinstall Xcode?
4. All of the above?

I also don't mind to rebuild MacPorts and all the ports if that makes any sense: I do prefer to solve the issue without having to involve IT.

[kencu (Ken)]

Replying to lcvisser:

This:

1. sudo rm -rf /Library/Developer/CommandLineTools/usr/include/c++ ?

Direct IT to this MacPorts ticket if they have any questions.

Or to here:

ProblemHotlist#clts16

If they say they would prefer to fully remove the CLTs and reinstall them from the DMG, that is equally good and they may prefer to do that.

[jmroot (Joshua Root)]

Replying to lcvisser:

The strange thing is (or at least, the part I don't understand): I can build C++ applications just fine. The sample provided in comment:75 compiles without error, so does all my normal work (although I use CMake, which may set some paths differently).

As your clang --version output shows, you are using Xcode, not the CLTs. If you export DEVELOPER_DIR=/Library/Developer/CommandLineTools before trying the example, you should reproduce the issue. This happens because /usr/bin/clang is a shim that finds and runs the real compiler based on your settings.

[lcvisser (Ludo Visser)]

Replying to jmroot:

Replying to lcvisser:

The strange thing is (or at least, the part I don't understand): I can build C++ applications just fine. The sample provided in comment:75 compiles without error, so does all my normal work (although I use CMake, which may set some paths differently).

As your clang --version output shows, you are using Xcode, not the CLTs. If you export DEVELOPER_DIR=/Library/Developer/CommandLineTools before trying the example, you should reproduce the issue. This happens because /usr/bin/clang is a shim that finds and runs the real compiler based on your settings.

Ah, yes, you're right. With the DEVELOPER_DIR I can reproduce it with the example, I overlooked that part. Thanks!

[lcvisser (Ludo Visser)]

Replying to kencu:

Replying to lcvisser:

This:

1. sudo rm -rf /Library/Developer/CommandLineTools/usr/include/c++ ?

Thanks, this works. I'm not entirely sure how Xcode installs are managed on corporate Macs (they run a bunch of post-install scripts), but removing the directory also resolved the issue for me. No further action needed.

[jwoehr (Jack J. Woehr)]

Was trying to install mc and it was failing on building pcre.

sudo rm -rf /Library/Developer/CommandLineTools/usr/include/c++ worked for me as well, thank you all.

(Actually I moved c++ to a temp dir "just in case".)

[FuturePilot (Nick)]

Replying to kencu:

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.

Confirming that this fixed the problem for me too

[mouse07410 (Mouse)]

MacPorts will use the command line tools unless use_xcode yes is set in the portfile.

It would be great if one could set use_xcode yes as a global Macports option, e.g., in /opt/local/etc/macports/macports.conf.

[ryandesign (Ryan Carsten Schmidt)]

Replying to mouse07410:

I wish that Macports would not insist on CLT in presence of the "full" Xcode.

It does not.

Replying to mouse07410:

MacPorts will use the command line tools unless use_xcode yes is set in the portfile.

It would be great if one could set use_xcode yes as a global Macports option, e.g., in /opt/local/etc/macports/macports.conf.

There is no need for that. If you do not have the command line tools installed and you only have Xcode installed, then MacPorts will always use Xcode.

[mouse07410 (Mouse)]

Please let users configure Macports (system-wide) to use Xcode even when CLT is installed.

[ryandesign (Ryan Carsten Schmidt)]

Why do you believe that that would be helpful?

[ryandesign (Ryan Carsten Schmidt)]

Better yet, don't answer here, because it has nothing to do with this ticket. You can file a new ticket or discuss it on the mailing list.