You can use external linking and specify it as a flag to the linker.

Thank you, this got me further and you are correct that

go build -ldflags="-linkmode=external -extldflags=-mmacosx-version-min=12.0" example.go

works if I'm compiling from macOS. However I didn't do a great job of describing my use case. I would like to be able to cross-compile a Go binary for macOS (from a Linux host) while also being able to set the target minimum macOS SDK. In this case I need to be able to use the internal linker. Would it be possible to reopen this bug as a feature request to add a flag to the internal linker so that the target minimum macOS version could be specified during cross-compilation?

The context for this is that we were building a Go binary that read /System/Library/CoreServices/SystemVersion.plist on macOS. There is code in the kernel that changes how the contents of this file are read depending on what the target minimum macOS SDK is of the running binary. Our current build process makes compiling this code natively somewhat difficult, whereas cross-compiling is relatively easy. But this leads to having an x86_64 slice that reads the incorrect OS version from this file.

Reopening.

CC @cherrymui @thanm

This seems doable in principle, although I worry a bit about adding this sort of flag/knob, since each flag increases the number of scenarios/permutations that we have to test (and if we have N flags, then potentially we have to test all possible combinations).

Sorry, I'm not sure I really understand the purpose of increasing the SDK version, or what exactly does that kernel code do. Could you add more information? Are you trying to enable new feature? Or is that some macOS feature is not compatible with older version of SDK? Thanks.

You can do this as a postprocess on your binary. This little program will change the version from the default of 10.13 to 10.14:

package main

import (
	"debug/macho"
	"encoding/binary"
	"os"
	"unsafe"
)

func main() {
	// Open file.
	f, err := os.OpenFile(os.Args[1], os.O_RDWR, 0)
	if err != nil {
		panic(err)
	}

	// Read and check magic number.
	var ident [4]byte
	if _, err := f.ReadAt(ident[:], 0); err != nil {
		panic(err)
	}
	magic := binary.LittleEndian.Uint32(ident[:])
	if magic != macho.Magic32 && magic != macho.Magic64 {
		panic("not a macho file")
	}

	// Read file header.
	var header macho.FileHeader
	if err := binary.Read(f, binary.LittleEndian, &header); err != nil {
		panic(err)
	}

	// Read load commands.
	offset := int64(unsafe.Sizeof(header))
	if magic == macho.Magic64 {
		offset += 4
	}
	cmds := make([]byte, header.Cmdsz)
	_, err = f.ReadAt(cmds, offset)
	if err != nil {
		panic(err)
	}

	// Iterate through load commands.
	for len(cmds) > 0 {
		cmd := binary.LittleEndian.Uint32(cmds[0:4])
		cmdSize := binary.LittleEndian.Uint32(cmds[4:8])
		if cmd == LC_BUILD_VERSION {
			version := []byte{14} // aka 10.14
			_, err = f.WriteAt(version, offset+13)
			if err != nil {
				panic(err)
			}
			_, err = f.WriteAt(version, offset+17)
			if err != nil {
				panic(err)
			}
			break
		}
		cmds = cmds[cmdSize:]
		offset += int64(cmdSize)
	}
}

const LC_BUILD_VERSION = 50

Sorry, I'm not sure I really understand the purpose of increasing the SDK version, or what exactly does that kernel code do. Could you add more information? Are you trying to enable new feature? Or is that some macOS feature is not compatible with older version of SDK?

The kernel code changes the contents of /System/Library/CoreServices/SystemVersion.plist based on the sdk specified in the LC_BUILD_VERSION of the running binary. When sdk predates 11.0, this file changes to display a ProductVersion of 10.16. When sdk is 11.0 or greater, then the true contents of the file are returned. See also https://eclecticlight.co/2020/08/13/macos-version-numbering-isnt-so-simple/. Repro code looks like

// example.go
package main

import (
	"fmt"
	"log"
	"os"
)

func main() {
	b, err := os.ReadFile("/System/Library/CoreServices/SystemVersion.plist")
	if err != nil {
		log.Fatalf("%v", err)
	}
	fmt.Println(string(b))
}

if you compile this with GOOS=darwin GOARCH=amd64 go build example.go, then since

% vtool -show-build example
example:
Load command 5
      cmd LC_BUILD_VERSION
  cmdsize 24
 platform MACOS
    minos 10.13
      sdk 10.13
   ntools 0

running the program on any macOS from 11.1 up to 13.3 will print

        ...
	<key>ProductUserVisibleVersion</key>
	<string>10.16</string>
	<key>ProductVersion</key>
	<string>10.16</string>
       ...

instead of the true contents. Taking the same code and compiling it with GOOS=darwin GOARCH=arm64 go build example.go for Apple Silicon instead gives

% vtool -show-build example
example:
Load command 6
      cmd LC_BUILD_VERSION
  cmdsize 24
 platform MACOS
    minos 11.0
      sdk 11.0
   ntools 0

and running it on, say macOS 13.2.1:

        ...
	<key>ProductUserVisibleVersion</key>
	<string>13.2.1</string>
	<key>ProductVersion</key>
	<string>13.2.1</string>
        ...

In our case we ended up lipo-ing the amd64 and arm64 binaries together to get a universal binary where each slice specified a different sdk target version, and so the resulting binary behaved differently on different arches and even behaved differently on arm64 depending on whether or not it was running under Rosetta.

We found an acceptable workaround for this particular example, but all of this is mostly to say that things are kind of weird and it would be nice to be able to easily set the sdk of all macOS builds to the same version >= 11.0 from the Go linker itself to avoid any unexpected future Apple weirdness.

Looking at https://eclecticlight.co/2020/08/13/macos-version-numbering-isnt-so-simple, it sounds as though you can just change your program to exec the equivalent of

SYSTEM_VERSION_COMPAT=0 cat /System/Library/CoreServices/SystemVersion.plist

then read and interpret the result. Seems like that would solve your problem without needing any changes to the Go linker.

We have a workaround for the specific example provided; I'm more interested in having a general solution. It makes a bit more sense to me to be able to enforce that our binaries target a recent SDK as Apple seems to expect, rather than finding new workarounds for each thing that might break because of this. I tried to find some other instances of where this might have been an issue, but the only thing that's come up is #30488, where the hardcoded value was breaking notarization.

If the recommended solution is to make a second pass over the binary with an external tool, I suppose that is fine, though not ideal from my perspective. I understand the reluctance to have an exploding list of platform-specific linker options.