Can't launch clang on MacBook M2 Pro running 13.5.2

From the Terminal, what does the following report?

xcode-select -p

Is the result /Library/Developer/CommandLineTools ? If not, do the following if you have installed them:

xcode-select -s /Library/Developer/CommandLineTools

I suggest that you consider updating Ventura to 13.6.1. If your version of Xcode is not 15.0.1, make it so. Then run the following in the Terminal to update the command line tools to 15.0.1:

xcode-select --install

Reboot the Mac and if your PATH is correct, you should have normal access to clang, swift, swiftc, lldb, and Python 3.9.6.

I am on Sonoma 14.1 and your post has some wacky paths that do not exist on my current Xcode and Command Line Tools implementation.

Mark Turner3 wrote:

What am I doing wrong, or what is missing? Why does it not seem to know the architecture that is needed ("...need ' ' ")? I have an old version of Xcode that migrated over from my previous Intel MacBook, but it is grayed out with a prohibition sign.

Could be....

Is it getting in the way; should I uninstall it (how?)?

Drag it to the trash.

Do I need (a new version of) Xcode to run clang?

Yep.

Does my executable search path need to be modified?

Nope.

Does my library search path need to be modified?

Nope.

What is the name of the ISA for M2 Pro? Is it "arm64e"? I thought that was the iPhone A12 silicon, or something like that.

Not sure where you're going here. You already answered your own question. Dig too deeply and you'll just cause problems for yourself.

Mark Turner3 wrote:

Is uninstalling Xcode really as simple as dragging it to the Trash?

Yep.

From other online discussions there seem to be many other steps, like deleting *plist or *xcode* files, deleting Developer directories, clearing caches, and so on.

Pro tip: the internet is wrong

Mind you, the old (Intel) Xcode that seems to be in the way is v8.3.3, a relative antique.

The biggest problem is that an Xcode that old won't run on a modern Apple Silicon machine. Apple Silicon breaks lots of existing backwards compatibility expectations.

However, sometimes it is good to keep an old copy of Xcode around running in a virtual machine. As much as Apple likes to push updates onto end users, that's nothing compared to the way they treat developers.

Sometimes, old versions of Xcode will be the only way to create new projects with legacy (but relatively bug free) app architectures. If you wanted to write an app based on Nib files instead of Storyboards, for example, you'll have to either try to clone an existing project or have an old copy of Xcode. Also, Apple sometimes provides automated upgrades for things like Swift, CoreData, or old application architectures. But Apple assumes that developers will upgrade promptly, so Apple is very quick to pull those automated upgrade features. If you have some cool, open-source project written in Swift 3, for example, you'll have to either manually redo it or find an old version of Xcode that will still update it.

But as I said, on Apple Silicon, that would be very limited right now. It remains to be seen how well current versions of macOS like Ventura will run on VMs in the future. I can still run every version of macOS since 10.7 in a VM on an Intel machine. But I think those days are gone for good.

Will deleting Xcode also delete .xcodeproj files, or are these considered user documents?

Those would be considered user documents. But you may have trouble opening those old files. You will probably have to update the signing information and the deployment version.

It seems like what I want is the CommandLineTools, which I didn't know existed separate from Xcode. Of course that won't let me run existing .xcodeproj files. I've seen complaints that Xcode is a space hog. How do the CommandLineTools compare space-wise?

Storage space is a commodity. For anyone doing any kind of professional work, if they have storage problems, they are doing it wrong. If you can't handle 300 GB free space for Xcode projects, then you shouldn't be doing Xcode projects.

If you have existing xcodeproj files, then those will require Xcode. You might be able to just build them with the Command Line tools, but that's all, if that. The Command Line tools are designed only for a certain class of open-source and academic masochists who need to build software from source on a Mac, but suffer from a terminal case of cognitive dissonance. In other words, they use and depend on the Mac, but hate everything about it.

Lately, however, another class of even more clueless people have adopted the Command Line tools as a requirement for using various 3rd party tools like Homebrew, VS, CLion, CMake, etc. Apple does not actually support this usage. So when Apple updates Xcode and the Command Line tools, users these types of apps experience significant problems.

Mark Turner3 wrote:

there exist runtime environments other than MacOS (!). I'm thinking particularly of *nix/GNU.

macOS actually is Unix. Neither Linux or GNU are.

there is a robust FOSS development community that unfortunately (or fortunately, depending on your POV) has to rely on least-common-denominator command-line tools and runtime environments.

In fact, there is an exceptionally-fragile modern FOSS development community that relies on a wide range of ever-more complicated "meta-build" systems. Modern projects aren't built with "configure; make install" anymore.

Xcode would not be of help there (unless it has fancy cross-development features that I'm not yet aware of).

That's literally its primary function. The Command Line tools are for building code on your Mac. That is a tiny fraction of all development activity on the Mac. Most of it uses Xcode to build targets for various other Apple platforms.