Coming at you from 2025, where people are once again deleting Rosetta 2 because it blocks an update. Do not delete libexec, delete libexec/oah, because there's an executable in libexec that isn't part of Rosetta 2. Unless this is something new. Then just pay attention to that package listing and only delete folders that were explicitly created by the packager, and not if they contain anything else not in the installer list.

Can confirm it also affects CPU profiling on macOS on Apple Silicon. macOS 15.3, Xcode 16.2, M4 Pro Edit: https://stackoverflow.com/questions/79311572/kpc-config-sysctl-call-returns-1-in-ibiremes-kpc-demo-on-m4-apple-silicon Thanks, Apple! Looks like it's broken on the M4 too.

Now that Sequoia is out, you'll be forced to use Xcode 16. Try that and see if they didn't keep it broken?

Xcode 15 beta 3 and newer (including the current beta 5) fails to link certain x86_64 objects. It also fails to link libbass and friends from un4seen.com, unless they are built to target macOS 10.6 or newer. The current public distributions of those are built with Xcode 8 and target 10.5 or newer. The same problem may apply to code built with non-Xcode versions of GCC or Clang. This appears to be a regression in Xcode, which I have reported as FB 12698037. Though they may just close it as intentional behavior, in which case, say goodbye to compatibility for who knows how long.

It seems I was able to work around this issue, by actually opening a project first before attempting to attach to something.

And how do I set a minimum size for a toolbar item with a slider control in it? I want a minimum size, but I want it to be able to get wider than the minimum size on its own. If I don't set a minimum size, the toolbar shrinks the slider to as small as 32px wide, which I don't want.

This whole thing raises the point as to whether it is even worth running the betas at all if you're a developer. If you're a developer, you need to release your app to the App Store on a regular basis, and you can't do this with a beta. So why even bother testing it? I cannot take a four month vacation from releasing app updates, and dual booting is inconvenient when I actually have to use the machine, as I'd rather spend time using the OS I can actually develop from.

I solved my Xcode Cloud issue, but dual booting is not really that useful of an option. I have the 256GB storage option, which is criminally small.

I have this issue randomly with Xcode 13.4.1 under macOS 12.4 on Apple Silicon, debugging a Mac app, not Rosetta. Breaking the app shows the main thread is stuck in a function called uniquing_table_stack_retain, underneath of an NSWindow function. The rest of the app is non-responsive. The only thing I've found to fix it is to completely terminate the debug session and hope the next one doesn't get stuck. I should mention that my hangups mostly happen when debugging with full Guard Malloc and Malloc Scribble enabled for the run, which also has a huge impact on memory usage and allocation overhead, both used memory and time to allocate.

Whee, I guess I shouldn't allocate temporary audio buffers on the stack. Fixed.

Oh, I forgot, that function has some significant stack usage.

For some reason, a function that has barely any local variables incurs a local stack frame difference like this:       sp = 0x000000016ec7eb40       sp = 0x000000016ebfea40

Oh, drat. I have to --unshallow the repository to get the commit counts. I hope that works.

Okay, nope, it needs to be in the pre xcodebuild script, since the submodules aren't fetched yet.

Okay, I figured out what was wrong. Xcode Cloud build system isn't fetching the tags in my repository when pulling it. So I need to add a git fetch --tags to the post clone script.