Post not yet marked as solved
I can verify that upgrading to 11.1 beta 2 addresses this same issue I had as well.
Post not yet marked as solved
@meaton - for that workaround you mention, is there a way to specify a wildcard for the port (instead of port 443)?
Post not yet marked as solved
@granada29 - I don't think it's an artifact of VirtualBox, because I'm seeing it in Parallels as well. It might be an artifact of virtualization, however.
I am seeing a crash in the WindowServer process. I can get it to happen every time when I click on the menubar (which is empty for me...i.e. no clock or any other icons). I have logged it as a feedback issue (FB7760353). If anyone is having problems where they keep getting thrown back to the login screen, you may want to check in /Library/Logs/DiagnosticReports and see if you have any WindowServer crashes.
Thank you for the guidance!
I’m getting occasional WindowServer crashes - perhaps that is what is taking you back to the login prompt?
Thank you! This is excellent information and gives me a great place to start.
We are currently able to notarize apps signed with Company A’s certificate using Company B’s developer account. Is that changing?
There are two separate xcode downloads currently - one labelled "Xcode 12 beta" and one labelled "Xcode 12 for macOS Universal Apps beta". Make sure you grabbed the second one.
Post not yet marked as solved
Actually - there is another thread on it over at https://developer.apple.com/forums/thread/649774
Post not yet marked as solved
Also getting this (installing into Parallels as well) - interested in any solution.
Thank you for the guidance - I actually was able to take this information and set up something that (I think) is a better solution all around.Basically, I created an "External Build System" target in my Xcode 11 project that is set up to build my kext target (driver.kext) as follows:Build Tool: /Applications/Xcode-9.4.1.app/Contents/Developer/usr/bin/xcodebuildArguments: -project "${PROJECT_FILE_PATH}" -target driver.kext -configuration ${CONFIGURATION} -quiet $(ACTION)This allows me to have all my files in a single project, but build the kext using Xcode-9.4.1 (the latest to support 10.13).
I am currently building a kext that needs to load on 10.13-10.15. Previously, we were able to achieve this by adding: -isysroot/Applications/Xcode-9.4.1.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.13.sdkto my cflags and and ldflags.This worked when building with Xcode 10.3 - however, when upgrading to Xcode 11, it appears that the isysroot is not taking effect - instead, ONLY the one added by Xcode (pointing to MacOSX10.15.sdk) is taking effect. I think that’s where the error I’m getting is coming from. The error is shown whenever I try to load the kext on 10.14.6 (and possibly on 10.13…I haven’t tried that one yet).I am able to work around this by creating a symlink from /Applications/Xcode-9.4.1.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.13.sdk into /Applications/Xcode-11.0.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.13.sdk and then building with the “MacOSX 10.13” SDK. That is an acceptable workaround for me, but I am wondering if there is a different approach I should take to build a legacy kernel driver that will load on 10.13-10.15 (realizing it is deprecated on 10.15…we are actually working on updating to use DriverKit for 10.15). However, we support the latest version of the OS minus 2 versions…meaning we’re going to need to support the kext on 10.14 for a couple years still. 😟If there are any suggestions you could give me that would simplify our process, I would appreciate it.
Trying to load the kext on 10.14.6.
