Post not yet marked as solved
Well the GM build shouldn't really be considered a beta anymore. A GM is a build that can reasonably be expected to not need further changes for release. I half expect it to release in this state too because of iOS 13. They might decide to fix it post release for Catalina, since there's more time until Catalina comes out.I only posted the workaround for other people in a similar position as the one I am in, which is one where I can't just suggest to wait with macOS 10.15 and Xcode 11. My job is either making stuff work, or coming up with a much more detailed explanation than "it crashes". The workaround is not for people who can just decide to not use Xcode 11. Thankfully, they've at least fixed the other bug with the stack check feature I referenced earlier in the thread.This is not a Catalina problem btw, it's Xcode 11. You can reproduce this bug on macOS 10.14 too with the Xcode GM build, but then you have to turn the feature on yourself with -fstack-check. The difference is that if you use Xcode 11 on macOS 10.15, it'll default to building for 10.15, and that turns this feature on automatically.The feature is also present in Xcode 10. But with Xcode 10, the stack stecking code is embedded in the compiled binary. Meaning the call doesn't go through the dynamic linker, which in turn means the 16 byte alignment requirement of the macOS ABI isn't enforced. So this is not like it's some major new thing in Xcode 11. It's the old combination of unfortunate circumstances.
Post not yet marked as solved
I would like to know this too.In general, Apple pref panes have been implemented as XPC services since a while ago, but I'm not aware of documentation or a way for normal humans to do the same.The legacyLoader thing is simply a way to isolate preference panes in their own process, so security wise this is a good change and I would actually be happy with it too if it was just named differently or if the non-legacy way was documented.
Post not yet marked as solved
You're not wrong, but there are workarounds in case you (or someone else finding this thread) just really need to make it workadd -fno-stack-check to CFLAGS/CXXFLAGS, orset MACOSX_DEPLOYMENT_TARGET=10.14 in the environment or choose 10.14 as deployment target in Xcode
Post not yet marked as solved
The headers are still there, what was removed is the package that installed them outside the SDK.Nowadays the SDK is part of the Xcode.app bundle, you can find the root withxcrun --sdk macosx --show-sdk-pathIf they rely on the compiler to find includes, it should work automatically, but in some cases adding something like this to CFLAGS/CXXFLAGS helps:-isysroot $(xcrun --show-sdk-path) -I/usr/include -L/usr/libBut this is specifically for projects that do detect macOS and do use the compiler for these tests, but explicitly specify outdated paths for includes and libraries.
Post not yet marked as solved
I don't know if there's some other sketchy way to build for 32 bit with newer Xcode, but since 32 bit executables don't run on macOS 10.15 I don't know how you would test your product on 10.15?Either way, the error doesn't look like you could expect someone to fix it. So downgrade it is, or a VM.
Post not yet marked as solved
Smaller test case:int main(void) {
register char a __asm("rbx") = 0;
char b[5000];
char c[100] = {0};
asm volatile("" : : "r,m"(a), "r,m"(b), "r,m"(c) : "memory");
return 0;
}
Post not yet marked as solved
Unfortunate combination:-mavx-O2-fstack-check (enabled by default when building for 10.15)Here's the start of main with all these options:a.out[0x100000e34] <+4>: pushq %rbx
a.out[0x100000e35] <+5>: andq $-0x20, %rsp
a.out[0x100000e39] <+9>: pushq %rax
a.out[0x100000e3a] <+10>: movl $0x1640, %eax ; imm = 0x1640
a.out[0x100000e3f] <+15>: callq 0x100000ef6 ; symbol stub for: ___chkstk_darwin
a.out[0x100000e44] <+20>: subq %rax, %rsp
a.out[0x100000e47] <+23>: popq %raxThe andq is only there with -mavx and -O2. This aligns the stack to 16.The call to ___chkstk_darwin is only there with the stack check feature enabled. For specifically this call, the stack is aligned to 8 if it was previously aligned to 16. This is where the error occurs.Side note: I'm not super confident in how much this stuff is being tested. I filed a bug a few weeks ago that your test case actually also triggers. If you build like this you get a different crash: cc -all_load a.c && ./a.out(This links in the compiler runtime that ships with Xcode, which has a different ___chkstk_darwin that modifies rax, and you can see that the code I quoted above doesn't expect that.)
Post not yet marked as solved
You can use df on a file to see the stats for the file system it's on, including device and mount point. You can also use stat -f%Sd to get the device name.
Post not yet marked as solved
It's mounted at /System/Volumes/DataThe data on it is also mapped at the old locations (e.g. /usr/local is really /System/Volumes/Data/Device/usr/local)
I managed to install it in a Parallels VM by upgrading an existing 10.14 VM. The installation eventually got stuck, but the CPU wasn't doing anything, so I reset the VM and it successfully booted 10.15. I have not been able to do a subsequent clean install from the recovery volume yet.Like the others are reporting, mouse dragging is not working.On startup, it also can't connect to the network at all. I managed to get it to work by turning the network interface off and on again a couple times and resetting the VM if that didn't help... not very reliable but allowed me to proceed with my work. There's a corresponding error in dmesg, but I didn't save it.Edit: Can also confirm Xcode crashing. Since this is due to an illegal instruction and the trace mentions Metal I'm assuming it's a VM problem and not a general problem with Xcode.
