Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

release: avoid setting __MAC_OS_X_VERSION_MAX_ALLOWED? #2767

Closed
AkihiroSuda opened this issue Oct 19, 2024 · 4 comments · Fixed by #2773
Closed

release: avoid setting __MAC_OS_X_VERSION_MAX_ALLOWED? #2767

AkihiroSuda opened this issue Oct 19, 2024 · 4 comments · Fixed by #2773
Labels

Comments

@AkihiroSuda
Copy link
Member

It seems like a bug to me, that the binaries are setting the max versions - and that it would be better to fix it?

I can see how it would at runtime require a min version, but that can probably be handled inside the application.

i.e. when I build I get /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk and -target-sdk-version=15.0

The documentation is a bit outdated, it stops at 18 (10.14) while the latest is 24 (15.0): https://go.dev/wiki/Darwin

Originally posted by @afbjorklund in #2753 (comment)

@afbjorklund
Copy link
Member

afbjorklund commented Oct 19, 2024

Availability.h says:

For these macros to function properly, a program must specify the OS version range
it is targeting. The min OS version is specified as an option to the compiler:
-mmacosx-version-min=10.x when building for Mac OS X, and -miphoneos-version-min=y.z
when building for the iPhone. The upper bound for the OS version is rarely needed,
but it can be set on the command line via: -D__MAC_OS_X_VERSION_MAX_ALLOWED=10x0 for
Mac OS X and __IPHONE_OS_VERSION_MAX_ALLOWED = y0z00 for iOS.

But I don't know who is setting 13.1? (__MAC_15_0 is 150000)

__MAC_OS_X_VERSION_MAX_ALLOWED=130100

@afbjorklund
Copy link
Member

afbjorklund commented Oct 19, 2024

This should have been the release job: "Merge pull request #2566 from AkihiroSuda/dev #3207":

https://github.com/lima-vm/lima/actions/runs/10610486369/job/29408056766

It sets up the runner like:

 # Xcode version
  xcodebuild -version
  # macOS SDK version
  xcrun --show-sdk-version

Xcode 14.2
Build version 14C18
13.1

And there are a lot of warnings in the build logs:

../../../go/pkg/mod/github.com/!code-!hex/vz/[email protected]/virtualization_helper.h:39:9: warning: macOS 14 API has been disabled [-W#pragma-messages]

Is the problem here that the Lima rosetta cache needs to be invalidated when macOS/Xcode is updated?

Or that Vz is somehow hard-coding the version it was built with as the max, when setting up the sharing?

unsupported build target macOS version for 14.0 (the binary was built with __MAC_OS_X_VERSION_MAX_ALLOWED=130100; needs recompilation)

https://github.com/Code-Hex/vz/blob/main/osversion.go

// for macOS 14 API
#if __MAC_OS_X_VERSION_MAX_ALLOWED >= 140000
#define INCLUDE_TARGET_OSX_14 1
#else
#pragma message("macOS 14 API has been disabled")
#endif

https://github.com/Code-Hex/vz/blob/main/virtualization_helper.h

@afbjorklund
Copy link
Member

afbjorklund commented Oct 19, 2024

So we are supposed to get some reasonable default like: -mmacosx-version-min=11

But for some reason, the build sets the max version to the same as the current sdk.


EDIT: Apparently that is the default behaviour, as dictated by the Availability headers.

So need to build on a newer SDK (for the new API), but with a lower minimum version (for the old OS).

i.e. use the MacOSX15.sdk, but with MACOSX_DEPLOYMENT_TARGET=11 (same thing as min)

CGO_CFLAGS="-mmacosx-version-min=11" CGO_LDFLAGS="-mmacosx-version-min=11"
MACOSX_DEPLOYMENT_TARGET=11

@afbjorklund
Copy link
Member

afbjorklund commented Oct 19, 2024

The end goal here is to be able to use the same binary, for all the macOS versions.

Verify by testing the "Darwin_macOS15" binaries on macOS 13, and they should work.

Then revert:

Note: Virtualization.framework requires macOS 11, Rosetta(Linux) requires macOS 13

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants