[Xquartz-dev] XQuartz 2.8.0 status

Mon Feb 22 23:21:37 PST 2021

Unfortunately, you cannot use an older SDK with the newer Xcode, and even if you do, then you won't be able to produce Universal binaries, as those require the latest SDK.

Or maybe that will work, at least for the x86_64 part of the code. You'll still need to use the latest SDK to produce the arm64 parts, and the new Xcode's lipo binary to produce the fat binaries from the resulting builds. The fat binaries include any Mach-O output you link, which means the main binary in the Contents/MacOS folder, and any dylibs that happen to be bundled with it.

> On Feb 22, 2021, at 10:35 PM, nicolas bats <sl1200mk2 at gmail.com> wrote:
> 
> 
> Christopher,
> thank you for your input !
> with XCode12 installed on M1 can I :
> export CC=/usr/bin/clang
> export SDKROOT=/path/to/MacOSX10.9.sdk
> 
> and produce binaries that will run on 10.9?
> 
> thanks,
> ++
> 
>> Le mar. 23 févr. 2021 à 07:28, Christopher Snowhill <chris at kode54.net> a écrit :
>> The SDK with Xcode 12 can't target anything older than 10.13. If you want to target your x86_64 parts at anything older, you'll need to build just the x86_64 part with Xcode 11 or older, then assemble the binaries using the lipo tool from Xcode 12.
>> 
>> 
>> 
>> ---- On Mon, 22 Feb 2021 21:55:05 -0800 nicolas bats <sl1200mk2 at gmail.com> wrote ----
>> 
>> Hi Jeremy, 
>> thank you for your answer.
>> I'm doing this way because my project embed Tk which is linked against some X11 libs and the easiest way to build everything is to let cmake make Tk happy :)
>> 
>> I've access to a M1 machine, I'll install XQuartz on it and rebuild everything targeting 10.9.
>> will tell you how it goes.
>> 
>> best regards,
>> nicolas
>> 
>> Le mar. 23 févr. 2021 à 06:43, Jeremy Huddleston Sequoia <jeremyhu at apple.com> a écrit :
>> 
>> 
>> On Feb 22, 2021, at 13:38, nicolas bats <sl1200mk2 at gmail.com> wrote:
>> 
>> Hi Jeremy,
>> sorry for my late reply I only got access to macOS10.9 today...
>> using 2.8.0_rc1, installation is fine, well done :)
>> 
>> now when linking my app I got this error:
>> -- 35/64: fixing up '/Users/nico/build/myApp.app/Contents/Frameworks/libX11.6.dylib'
>> /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/install_name_tool: for architecture arm64 object: /Users/nico/build/myApp.app/Contents/Frameworks/libX11.6.dylib malformed object (unknown load command 9)
>> CMake Error at /usr/local/share/cmake-3.19/Modules/BundleUtilities.cmake:905 (message):
>>   Command failed:
>> 
>>    '/usr/bin/install_name_tool' '-change' '/opt/X11/lib/libxcb.1.dylib' '@executable_path/../Frameworks/libxcb.1.dylib' '-id' '@executable_path/../Frameworks/libX11.6.dylib' '/Users/nico/build/myApp.app/Contents/Frameworks/libX11.6.dylib'
>> Call Stack (most recent call first):
>>   /usr/local/share/cmake-3.19/Modules/BundleUtilities.cmake:980 (fixup_bundle_item)
>>   cmake_install.cmake:209 (fixup_bundle)
>> 
>> 
>> make: *** [install] Error 1
>> 
>> it seems that install_name_tool does not like arm64.
>> 
>> It's not that install_name_tool doesn't like arm64, it's that this old install_name_tool does not understand the new LC_BUILD_VERSION load command in that slice:
>> 
>> Load command 9
>>       cmd LC_BUILD_VERSION
>>   cmdsize 32
>>  platform 1
>>     minos 11.0
>>       sdk 11.3
>>    ntools 1
>>      tool 3
>>   version 609.8
>> 
>> The arm64 slices are encoded with a minimum version of macOS 11.0 (since that's the first version to support macOS 11.0), which means we can use the newer / more-agile LC_BUILD_VERSION load command instead of the platform-specific one (LC_VERSION_MIN_MACOSX).
>> 
>> is it something I need to deal with or something that you can deal with?
>> 
>> Why are you embedding these libraries into your project?
>> Can you instead build them from source for your project?
>> 
>> You'll need to do this on a newer version of macOS that has a toolchain that understand how to handle the LC_BUILD_VERSION  load command.  I *think* that was Xcode 10 on macOS 10.13, but I could be wrong.
>> 
>> best regards,
>> nicolas
>> 
>> Le lun. 22 févr. 2021 à 21:17, Jeremy Huddleston Sequoia <jeremyhu at apple.com> a écrit :
>> 
>> 
>> On Feb 22, 2021, at 06:06, Peter Dyballa <Peter_Dyballa at Freenet.DE> wrote:
>> 
>> 
>> Am 17.2.2021 um 22:34 schrieb Jeremy Huddleston Sequoia <jeremyhu at apple.com>:
>> 
>> Hey Peter, can you explain what you mean by this?  There are quite a number of default client apps in /opt/X11/bin
>> 
>> I just missed to see this! (And I should put this directory into search path.)
>> 
>> PATH should be setup correctly by the default shell initialization scripts. XQuartz installs /etc/paths.d/40-XQuartz which is used by /etc/profile and /etc/zprofile:
>> 
>> if [ -x /usr/libexec/path_helper ]; then
>>  eval `/usr/libexec/path_helper -s`
>> fi
>> 
>> 
>> 
>> --
>> Greetings
>> 
>>  Pete
>> 
>> "Debugging? Klingons do not debug. Our software does not coddle the weak."
>> 
>> 
>> 
>> 
>> _______________________________________________
>> Xquartz-dev mailing list
>> Xquartz-dev at lists.macosforge.org
>> https://lists.macosforge.org/mailman/listinfo/xquartz-dev
>> 
>> 
>> 
>> _______________________________________________
>> Xquartz-dev mailing list
>> Xquartz-dev at lists.macosforge.org
>> https://lists.macosforge.org/mailman/listinfo/xquartz-dev
>> 
>> _______________________________________________
>> Xquartz-dev mailing list
>> Xquartz-dev at lists.macosforge.org
>> https://lists.macosforge.org/mailman/listinfo/xquartz-dev
>> 
>> 
>> _______________________________________________
>> Xquartz-dev mailing list
>> Xquartz-dev at lists.macosforge.org
>> https://lists.macosforge.org/mailman/listinfo/xquartz-dev
>> 
>> _______________________________________________ 
>> Xquartz-dev mailing list 
>> Xquartz-dev at lists.macosforge.org 
>> https://lists.macosforge.org/mailman/listinfo/xquartz-dev 
>> 
>> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macosforge.org/pipermail/xquartz-dev/attachments/20210222/8feb4cb0/attachment-0001.htm>