ARM/x64 macOS universal binary triplet

[Be-ing]

---

Is your feature request related to a problem? Please describe.
Apple has switched CPU architectures again, this time to ARM.

Proposed solution
Add a new triplet arm64-x64-osx (or some similar name) for ARM/x64 universal binaries

Describe alternatives you've considered
Make separate builds for x64-osx and arm64-osx

Additional context
https://cmake.org/cmake/help/latest/variable/CMAKE_OSX_ARCHITECTURES.html

[JackBoosY]

Yes, we are planing to do that.

[JackBoosY]

cc @strega-nil-ms

[strega-nil-ms]

We've talked about how to do this, but haven't had the chance to design a good system for this yet. We really need to spend some serious time on OSX in this.

[Be-ing]

Has there been any progress towards this?

[kenr]

Do you have a triplet name in mind for fat binaries?

[kelteseth]

Is there any workaround for this until we get a new triplet? @strega-nil-ms

[Nazgul37]

@kelteseth Have you been able to find a way to do this?

[kelteseth]

I have not. I create two separate executables for now...

[Be-ing]

You can make two separate builds and then combine them with lipo.

[Nazgul37]

Has there been any update on the best way to do this at current? @JackBoosY

[photex]

I've started advocating for vcpkg over Conan at work, part of the reason is because the triplet model is a lot more promising than Conans flat out refusal to support or acknowledge universal binaries.

Has anyone attempted their own triplet while waiting for the official solution?

Any updates from Microsoft would be really helpful.

[kelteseth]

@photex Incompile the vcpkg dependencies twice and then combine them with lipo, see my python script https://gitlab.com/kelteseth/ScreenPlay/-/blob/master/Tools/macos_lipo.py

[photex]

I just tested a custom triplet 'universal-osx.cmake' which was a copy of arm64-osx.cmake from the community triplets.

I changed the architectures line to:
set(VCPKG_OSX_ARCHITECTURES "arm64;x86_64")

I built a universal binary of SDL2 and linked with it.

[BillyONeal]

Any updates from Microsoft would be really helpful.

arm64-osx may be in the cards if we can finally get a way to get the machines we have into CI. I don't expect a universal triplet anytime soon because there are too many build systems that themselves don't understand this. As a result I suspect we and Conan are in the same place in recommending separate builds and lipo afterwards.

Note that several of vcpkg's triplet knobs like VCPKG_CXX_FLAGS do not make sense when there are literally two separate compiles happening, so even if we add such a thing it's going to be very much it's own snowflake.

[photex]

How does or would the lisp method work with manifest mode? It’s just not part of the build then I guess.

[faaxm]

Is there some work that has already been started in that direction and that could be picked up by the OSS community?

I have been using the process outlined in the blog-post below, but would be nice to have official support.
https://www.f-ax.de/dev/2022/11/09/how-to-use-vcpkg-with-universal-binaries-on-macos/

[asad26]

Hi @JackBoosY, @BillyONeal

Is there any update on supporting universal macOS triplet? Thanks.

[kelteseth]

From what I've gathered, and personal experience is that it is a build system issue. When all of your dependencies are using CMake, you would be fine using a osx-unversal triplet and set the CMake config to:

set(VCPKG_TARGET_ARCHITECTURE arm64)
set(VCPKG_CRT_LINKAGE dynamic)
set(VCPKG_LIBRARY_LINKAGE static)

set(VCPKG_CMAKE_SYSTEM_NAME Darwin)

# THIS WILL _NOT_ WORK FOR NONE CMAKE LIBS:
set(VCPKG_OSX_ARCHITECTURES "arm64;x86_64")

This will not for work any lib that does not use CMake, aka most libraries. This means you must compile it twice and use the script from #19454 (comment)

[BardGysler]

Hi, any update about this?

[autoantwort]

No

[sharadhr]

Some experiments: AppleClang clang and clang++ support the -arch flag, which is (partially) how CMake implements CMAKE_OSX_ARCHITECTURES.

Additionally, the -isysroot flag is set with CMAKE_OSX_SYSROOT and used in the compiler invocation as well.

Of course, vcpkg straightforwardly supports universal CMake dependencies by forwarding VCPKG_OSX_ARCHITECTURES to CMAKE_OSX_ARCHITECTURES. For other build systems, I believe the best way forward would be to use CMake's built-in infrastructure under script mode (like vcpkg already does with GNU Autotools, for instance) to prepare CFLAGS, CPPFLAGS, CXXFLAGS, LDFLAGS, and LIBS in the configure-make invocations; the end result should have, at least, -arch x86_64 -arch arm64 in C[XX]FLAGS and LDFLAGS.

Some vcpkg portfile function implementations will have to be modified to properly support a universal-osx triplet.

[VioletGiraffe]

Is there an open issue for universal binary support? Clearly there has to be, but I can't find it.