A similar thread: https://developer.apple.com/forums/thread/698628
I had the same issues with my M1 mac, getting constantly annoying kernel warnings spamming my log output when using some of the tools bundled with Xcode, such as xcodebuild.
None of the solutions above or elsewhere helped, such as resetting (sudo xcode-select -r), reinstalling command line tools (sudo rm -rf /Library/Developer/CommandLineTools; sudo xcode-select --install), exporting SDKROOT environment variable (export SDKROOT=$(xcrun --sdk macosx --show-sdk-path)), installing older Xcode versions from Apple's website (https://developer.apple.com/download/all/?q=xcode and then sudo xcode-select -s /Applications/Xcode_13_0.app) -- in fact older versions made it worse and in Xcode 13.4 they fixed at least the symbol collisions with libauthinstall.dylib and when I switched to older versions they came back.
This is consistently triggered when just using xcodebuild -h command.
This is very annoying, especially for users using the command line. I even tried filtering them through /etc/asl.conf with custom rules and failed, so my solution for now (although ugly, but works) is to wrap the xcodebuild command with a script that greps out the annoying logs that do not affect the build:
- Rename
xcodebuild executable to xcodebuildd:
sudo mv /Applications/Xcode.app/Contents/Developer/usr/bin/{xcodebuild,xcodebuildd}
- Create the wrapper script filtering annoying messages:
sudo vim /Applications/Xcode.app/Contents/Developer/usr/bin/xcodebuild
#!/bin/bash
/Applications/Xcode.app/Contents/Developer/usr/bin/xcodebuildd "${@}" 2>&1 | grep -vE "is implemented in both /usr/lib/libauthinstall\.dylib|with identifier Xcode\.IDEKit"
- Add permissions to execute:
sudo chmod +x /Applications/Xcode.app/Contents/Developer/usr/bin/xcodebuild
And viola, clean output!
Note however that this may cause problems if your application parses xcodebuild's output, because in some cases it outputs the process name (e.g. when using xcodebuild -h). In that case, it's a little bit more tricky to make it output the same xcodebuild name, since if we move it to a custom directory, the @rpath libraries where xcodebuild depends upon are relative to the executable, so if we move it to a different directory, we need to change the executable @rpaths to absolute paths and then force sign it. This can be done with the following commands:
cd /tmp
cp /Applications/Xcode.app/Contents/Developer/usr/bin/xcodebuildd xcodebuild
install_name_tool ./xcodebuild \
-add_rpath /Applications/Xcode.app/Contents/Frameworks \
-add_rpath /Applications/Xcode.app/Contents/SystemFrameworks \
-add_rpath /Applications/Xcode.app/Contents/SharedFrameworks \
-add_rpath /Applications/Xcode.app/Contents/PlugIns
codesign -s '-' xcodebuild -f
sudo mkdir -p /Applications/Xcode.app/Contents/Developer/usr/bin/ext
sudo mv xcodebuild /Applications/Xcode.app/Contents/Developer/usr/bin/ext/xcodebuild
So now we can update our wrapper script to use it instead:
#!/bin/bash
/Applications/Xcode.app/Contents/Developer/usr/bin/ext/xcodebuild "${@}" 2>&1 | grep -vE "is implemented in both /usr/lib/libauthinstall\.dylib|with identifier Xcode\.IDEKit"
Probably resetting the mac to factory settings may help with things, but if this is not an option for you, hopefully this temporarily solution helps until Apple fixes this issue.
