Hi Jeremy, may I ask you what's the status of XQuartz 2.8.0? the problem is that almost every user has received an announcement about the 2.8.0 release and most of them have made the update. But as I cannot start 2.8.0 on macOS 10.9 I cannot compile my app against it, and so many users complain about my app that does not work anymore. If downgrading to 2.7.11 was simple it wouldn't be an issue, but it isn't... So can you (or others) teach me the right way to downgrade to 2.7.11? Also, do you plan to update 2.8.0 soon? best regards, nicolas
nicolas bats <sl1200mk2@gmail.com> writes:
If downgrading to 2.7.11 was simple it wouldn't be an issue, but it isn't...
FWIW, I successfully went back to 2.7.11 from the beta3 just by running the 2.7.11 installer. (I think I might have re-logged-in afterwards, don't recall for sure.) The business about not auto-launching an xterm when XQuartz is started seems to have now infected 2.7.11 too, but I can live with that until 2.8.0 is more solid. regards, tom lane
Am 11.2.2021 um 21:22 schrieb Tom Lane <tgl@sss.pgh.pa.us>:
The business about not auto-launching an xterm when XQuartz is started seems to have now infected 2.7.11 too
XQuartz 2.8.0 comes without any X client. And when you want to launch Xterm from MacPorts or any other source via ~/.xinitrc then it seems to be necessary to either set PATH in that shell script or use at least the complete path name of the X client. I've put echo "$X11_PREFS_DOMAIN" > ~/X11-prefs-domain echo "$PATH" >> ~/X11-prefs-domain into my .xinitrc to check… -- Greetings Pete Math illiteracy affects 7 out of every 5 Americans.
On Feb 11, 2021, at 14:59, Peter Dyballa <Peter_Dyballa@web.de> wrote:
Am 11.2.2021 um 21:22 schrieb Tom Lane <tgl@sss.pgh.pa.us>:
The business about not auto-launching an xterm when XQuartz is started seems to have now infected 2.7.11 too
XQuartz 2.8.0 comes without any X client.
Hey Peter, can you explain what you mean by this? There are quite a number of default client apps in /opt/X11/bin
And when you want to launch Xterm from MacPorts or any other source via ~/.xinitrc then it seems to be necessary to either set PATH in that shell script or use at least the complete path name of the X client.
Yes. That is expected. .xinitrc is not run from a login shell.
I've put
echo "$X11_PREFS_DOMAIN" > ~/X11-prefs-domain echo "$PATH" >> ~/X11-prefs-domain
into my .xinitrc to check…
-- Greetings
Pete
Math illiteracy affects 7 out of every 5 Americans.
_______________________________________________ Xquartz-dev mailing list Xquartz-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/xquartz-dev
Am 17.2.2021 um 22:34 schrieb Jeremy Huddleston Sequoia <jeremyhu@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.) -- Greetings Pete "Debugging? Klingons do not debug. Our software does not coddle the weak."
On Feb 22, 2021, at 06:06, Peter Dyballa <Peter_Dyballa@Freenet.DE> wrote:
Am 17.2.2021 um 22:34 schrieb Jeremy Huddleston Sequoia <jeremyhu@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@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/xquartz-dev
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. is it something I need to deal with or something that you can deal with? best regards, nicolas Le lun. 22 févr. 2021 à 21:17, Jeremy Huddleston Sequoia <jeremyhu@apple.com> a écrit :
On Feb 22, 2021, at 06:06, Peter Dyballa <Peter_Dyballa@Freenet.DE> wrote:
Am 17.2.2021 um 22:34 schrieb Jeremy Huddleston Sequoia < jeremyhu@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@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/xquartz-dev
_______________________________________________ Xquartz-dev mailing list Xquartz-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/xquartz-dev
On Feb 22, 2021, at 13:38, nicolas bats <sl1200mk2@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@apple.com <mailto:jeremyhu@apple.com>> a écrit :
On Feb 22, 2021, at 06:06, Peter Dyballa <Peter_Dyballa@Freenet.DE <mailto:Peter_Dyballa@Freenet.DE>> wrote:
Am 17.2.2021 um 22:34 schrieb Jeremy Huddleston Sequoia <jeremyhu@apple.com <mailto:jeremyhu@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@lists.macosforge.org <mailto:Xquartz-dev@lists.macosforge.org> https://lists.macosforge.org/mailman/listinfo/xquartz-dev <https://lists.macosforge.org/mailman/listinfo/xquartz-dev>
_______________________________________________ Xquartz-dev mailing list Xquartz-dev@lists.macosforge.org <mailto:Xquartz-dev@lists.macosforge.org> https://lists.macosforge.org/mailman/listinfo/xquartz-dev <https://lists.macosforge.org/mailman/listinfo/xquartz-dev>
_______________________________________________ Xquartz-dev mailing list Xquartz-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/xquartz-dev
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@apple.com> a écrit :
On Feb 22, 2021, at 13:38, nicolas bats <sl1200mk2@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@apple.com> a écrit :
On Feb 22, 2021, at 06:06, Peter Dyballa <Peter_Dyballa@Freenet.DE> wrote:
Am 17.2.2021 um 22:34 schrieb Jeremy Huddleston Sequoia < jeremyhu@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@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/xquartz-dev
_______________________________________________ Xquartz-dev mailing list Xquartz-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/xquartz-dev
_______________________________________________ Xquartz-dev mailing list Xquartz-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/xquartz-dev
_______________________________________________ Xquartz-dev mailing list Xquartz-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/xquartz-dev
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@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 <mailto:jeremyhu@apple.com> a écrit : On Feb 22, 2021, at 13:38, nicolas bats <mailto:sl1200mk2@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 <mailto:jeremyhu@apple.com> a écrit : On Feb 22, 2021, at 06:06, Peter Dyballa <mailto:Peter_Dyballa@Freenet.DE> wrote: Am 17.2.2021 um 22:34 schrieb Jeremy Huddleston Sequoia <mailto:jeremyhu@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 mailto:Xquartz-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/xquartz-dev _______________________________________________ Xquartz-dev mailing list mailto:Xquartz-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/xquartz-dev _______________________________________________ Xquartz-dev mailing list mailto:Xquartz-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/xquartz-dev _______________________________________________ Xquartz-dev mailing list mailto:Xquartz-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/xquartz-dev _______________________________________________ Xquartz-dev mailing list mailto:Xquartz-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/xquartz-dev
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@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@gmail.com <sl1200mk2@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@apple.com> a écrit :
On Feb 22, 2021, at 13:38, nicolas bats <sl1200mk2@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@apple.com> a écrit :
On Feb 22, 2021, at 06:06, Peter Dyballa <Peter_Dyballa@Freenet.DE> wrote:
Am 17.2.2021 um 22:34 schrieb Jeremy Huddleston Sequoia < jeremyhu@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@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/xquartz-dev
_______________________________________________ Xquartz-dev mailing list Xquartz-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/xquartz-dev
_______________________________________________ Xquartz-dev mailing list Xquartz-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/xquartz-dev
_______________________________________________ Xquartz-dev mailing list Xquartz-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/xquartz-dev
_______________________________________________ Xquartz-dev mailing list Xquartz-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/xquartz-dev
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@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@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@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@apple.com> a écrit :
On Feb 22, 2021, at 13:38, nicolas bats <sl1200mk2@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@apple.com> a écrit :
On Feb 22, 2021, at 06:06, Peter Dyballa <Peter_Dyballa@Freenet.DE> wrote:
Am 17.2.2021 um 22:34 schrieb Jeremy Huddleston Sequoia <jeremyhu@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@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/xquartz-dev
_______________________________________________ Xquartz-dev mailing list Xquartz-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/xquartz-dev
_______________________________________________ Xquartz-dev mailing list Xquartz-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/xquartz-dev
_______________________________________________ Xquartz-dev mailing list Xquartz-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/xquartz-dev
_______________________________________________ Xquartz-dev mailing list Xquartz-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/xquartz-dev
On Feb 11, 2021, at 11:33, nicolas bats <sl1200mk2@gmail.com> wrote:
Hi Jeremy, may I ask you what's the status of XQuartz 2.8.0?
I'm not aware of anything major preventing release, but I put out 2.8.0_beta4 to allow a wider audience on older operating systems to look at it.
the problem is that almost every user has received an announcement about the 2.8.0 release and most of them have made the update.
Yeah, it's really unfortunate that 2.7.11 was configured to use the beta sparkle feed, but at least the current release is pretty much complete.
But as I cannot start 2.8.0 on macOS 10.9 I cannot compile my app against it
I'm not sure what you mean by this. You should be able to compile your app just fine using 2.7.11, and it should work just fine on systems with newer XQuartz.
, and so many users complain about my app that does not work anymore.
If there is a bincompat issue that is causing your app to not work for users that have upgraded from 2.7.11 to 2.8.0, that is definitely worthy of a bug report. What's the specific issue?
If downgrading to 2.7.11 was simple it wouldn't be an issue, but it isn't... So can you (or others) teach me the right way to downgrade to 2.7.11?
It should be fairly straight forward. First, follow the instructions for uninstalling 2.8 at https://www.xquartz.org/FAQs.html and then re-install 2.7.11.
Also, do you plan to update 2.8.0 soon?
I'd like to have a few weeks with it out as beta then a few weeks as release candidate before declaring it done. This is a fairly large change from 2.7.11, so I'd like to get some bake time in.
best regards, nicolas
_______________________________________________ Xquartz-dev mailing list Xquartz-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/xquartz-dev
participants (6)
-
Christopher Snowhill
-
Jeremy Huddleston Sequoia
-
nicolas bats
-
Peter Dyballa
-
Peter Dyballa
-
Tom Lane