Building bundle'able Xquartz
Hi, I'm making mac os x application bundle for one of my applications and would like to embed the XQuartz release into it. The reason herefore is that the default X11 on 10.6.x has a flaw that Apple has not been fixing and I would like to follow the typical bundle way where you simply need to drag the bundle onto your Applications folder to run it. My first question is, is can this be reasonably realized? So far I've thought of two approaches: 1. Get the XQuartz release, install it, then copy the /opt/X11 content to my My.app/Contents/Libraries/X11 and fix it up. I can modify all the install_names and even edit all the /opt/X11 paths that appear in scripts (e.g., startx), but I don't know what is all just hardcoded into some of the other executables. 2. Get the source and build a relocatable XQuartz to embed in the app bundle. I've been trying to follow the instructions here: http://xquartz.macosforge.org/trac/wiki/1.4-apple-git-10.5.5 but when I run autogen.sh for the xorg-macros it complains that I can't use a relative path as --prefix=../Libraries/X11. I'm not sure how the prefix gets used internally, i.e., does it contribute to producing paths that get injected into some of the code at compile time or not. I would greatly welcome any advice on creating an embedable X11 release, such that I could run startx from my app bundle's start-up script and have it use only resources that are contained in the app bundle. Thanks, -- Tony Bernardin, Postdoctoral Researcher, W.M. Keck Center for Active Visualization in the Earth Sciences (KeckCAVES) University of California, Davis
I already do this for Wineskin... it works decently enough You need a unique location to build XQuartz to, as some of the stuff in it (namely xkb) has to have a hard coded set path, and its not easy to edit after building, so you need to build it yourself. I suggest building it as installed in /tmp as it works great for me since all users have full read/write to /tmp. I build WineskinX11 (My slightly modified XQuartz build) as installed to /tmp/Wineskin. While I fix all my libraries with install_name_tool to run relative to the executable location, for things like xkb, I have it start up by making a symlink at /tmp/Wineskin to the current x11 location inside the app at the time. It only really needs it for xkb initialization and not later for running, so if that symlink is only important for starting up X, just rm one if there and create a new one on every run... just choose a good name in /tmp that will be unique for sure to build it to run from, not /opt since it would require a password to make a symlink there, and not in /tmp... so non-Admin users can still run the app ok with no special installation. You can edit XQuartz itself to do certain things at startup when you do your own build to start up certain other programs in X, and then your application would in actuality just be the same as being XQuartz.app named what you want, customized to start up certain things, but with the libraries inside... I really think this is how XQuartz should always be, but they like it in /opt :-) Oh I'd recommend probably editing the source to read the xmodmap from somewhere in through /tmp/whatever too, since by default it only uses ~/.Xmodmap, and you never know what some user might have that messes thing up. -doh123 On Jun 23, 2011, at 5:47 PM, Tony Bernardin wrote:
Hi,
I'm making mac os x application bundle for one of my applications and would like to embed the XQuartz release into it. The reason herefore is that the default X11 on 10.6.x has a flaw that Apple has not been fixing and I would like to follow the typical bundle way where you simply need to drag the bundle onto your Applications folder to run it. My first question is, is can this be reasonably realized? So far I've thought of two approaches:
1. Get the XQuartz release, install it, then copy the /opt/X11 content to my My.app/Contents/Libraries/X11 and fix it up. I can modify all the install_names and even edit all the /opt/X11 paths that appear in scripts (e.g., startx), but I don't know what is all just hardcoded into some of the other executables.
2. Get the source and build a relocatable XQuartz to embed in the app bundle. I've been trying to follow the instructions here: http://xquartz.macosforge.org/trac/wiki/1.4-apple-git-10.5.5 but when I run autogen.sh for the xorg-macros it complains that I can't use a relative path as --prefix=../Libraries/X11. I'm not sure how the prefix gets used internally, i.e., does it contribute to producing paths that get injected into some of the code at compile time or not.
I would greatly welcome any advice on creating an embedable X11 release, such that I could run startx from my app bundle's start-up script and have it use only resources that are contained in the app bundle.
Thanks,
-- Tony Bernardin, Postdoctoral Researcher, W.M. Keck Center for Active Visualization in the Earth Sciences (KeckCAVES) University of California, Davis
_______________________________________________ Xquartz-dev mailing list Xquartz-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/xquartz-dev
thanks for the reply doh123. I'll consider it, although I'm still holding out for someone to suggest a way it could be done "more cleanly". Still I understand changing all the install_names after the fact, but what about all the other references to paths, e.g., in startx, they'd all point the /tmp/Whatever/... Do you also change these retroactively? On Thu, Jun 23, 2011 at 4:19 PM, doh123 <doh123@doh123.com> wrote:
I already do this for Wineskin... it works decently enough
You need a unique location to build XQuartz to, as some of the stuff in it (namely xkb) has to have a hard coded set path, and its not easy to edit after building, so you need to build it yourself.
I suggest building it as installed in /tmp as it works great for me since all users have full read/write to /tmp. I build WineskinX11 (My slightly modified XQuartz build) as installed to /tmp/Wineskin. While I fix all my libraries with install_name_tool to run relative to the executable location, for things like xkb, I have it start up by making a symlink at /tmp/Wineskin to the current x11 location inside the app at the time. It only really needs it for xkb initialization and not later for running, so if that symlink is only important for starting up X, just rm one if there and create a new one on every run... just choose a good name in /tmp that will be unique for sure to build it to run from, not /opt since it would require a password to make a symlink there, and not in /tmp... so non-Admin users can still run the app ok with no special installation.
You can edit XQuartz itself to do certain things at startup when you do your own build to start up certain other programs in X, and then your application would in actuality just be the same as being XQuartz.app named what you want, customized to start up certain things, but with the libraries inside... I really think this is how XQuartz should always be, but they like it in /opt :-)
Oh I'd recommend probably editing the source to read the xmodmap from somewhere in through /tmp/whatever too, since by default it only uses ~/.Xmodmap, and you never know what some user might have that messes thing up.
-doh123
On Jun 23, 2011, at 5:47 PM, Tony Bernardin wrote:
Hi,
I'm making mac os x application bundle for one of my applications and would like to embed the XQuartz release into it. The reason herefore is that the default X11 on 10.6.x has a flaw that Apple has not been fixing and I would like to follow the typical bundle way where you simply need to drag the bundle onto your Applications folder to run it. My first question is, is can this be reasonably realized? So far I've thought of two approaches:
1. Get the XQuartz release, install it, then copy the /opt/X11 content to my My.app/Contents/Libraries/X11 and fix it up. I can modify all the install_names and even edit all the /opt/X11 paths that appear in scripts (e.g., startx), but I don't know what is all just hardcoded into some of the other executables.
2. Get the source and build a relocatable XQuartz to embed in the app bundle. I've been trying to follow the instructions here: http://xquartz.macosforge.org/trac/wiki/1.4-apple-git-10.5.5 but when I run autogen.sh for the xorg-macros it complains that I can't use a relative path as --prefix=../Libraries/X11. I'm not sure how the prefix gets used internally, i.e., does it contribute to producing paths that get injected into some of the code at compile time or not.
I would greatly welcome any advice on creating an embedable X11 release, such that I could run startx from my app bundle's start-up script and have it use only resources that are contained in the app bundle.
Thanks,
-- Tony Bernardin, Postdoctoral Researcher, W.M. Keck Center for Active Visualization in the Earth Sciences (KeckCAVES) University of California, Davis
_______________________________________________ Xquartz-dev mailing list Xquartz-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/xquartz-dev
_______________________________________________ Xquartz-dev mailing list Xquartz-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/xquartz-dev
-- Tony Bernardin, Postdoctoral Researcher, W.M. Keck Center for Active Visualization in the Earth Sciences (KeckCAVES) University of California, Davis
I don't use startx... just run the main xserver executable directly (the X11.bin file in XQuartz.app). You only need the main xserver executable, and xkbcomp... maybe quartz-wm, but most people should already have that on their machine, and you have to start it manually (you can add code to start it in the xorg server itself after initialization is done). Other than that, the xkb files needed in the share folder, and then just tons of dylibs in the lib folder. trust me, the whole thing isn't easy to get working, but the symlink is really only needed for xkb initialization. If you want to modify the xkb code to work another way, feel free, but there is no other clean way with the current code... it MUST have a hard set compiled in path for itself and where it finds the files it needs. /tmp is the best solution, and it only needs the symlink for a few seconds. /tmp is a temp folder for use by programs... its full read/write there to be used in ways such as this. If you find another way to get xkb to initialize properly with a dynamic path, be sure to let me know :-) On Jun 23, 2011, at 7:54 PM, Tony Bernardin wrote:
thanks for the reply doh123. I'll consider it, although I'm still holding out for someone to suggest a way it could be done "more cleanly". Still I understand changing all the install_names after the fact, but what about all the other references to paths, e.g., in startx, they'd all point the /tmp/Whatever/... Do you also change these retroactively?
On Thu, Jun 23, 2011 at 4:19 PM, doh123 <doh123@doh123.com> wrote: I already do this for Wineskin... it works decently enough
You need a unique location to build XQuartz to, as some of the stuff in it (namely xkb) has to have a hard coded set path, and its not easy to edit after building, so you need to build it yourself.
I suggest building it as installed in /tmp as it works great for me since all users have full read/write to /tmp. I build WineskinX11 (My slightly modified XQuartz build) as installed to /tmp/Wineskin. While I fix all my libraries with install_name_tool to run relative to the executable location, for things like xkb, I have it start up by making a symlink at /tmp/Wineskin to the current x11 location inside the app at the time. It only really needs it for xkb initialization and not later for running, so if that symlink is only important for starting up X, just rm one if there and create a new one on every run... just choose a good name in /tmp that will be unique for sure to build it to run from, not /opt since it would require a password to make a symlink there, and not in /tmp... so non-Admin users can still run the app ok with no special installation.
You can edit XQuartz itself to do certain things at startup when you do your own build to start up certain other programs in X, and then your application would in actuality just be the same as being XQuartz.app named what you want, customized to start up certain things, but with the libraries inside... I really think this is how XQuartz should always be, but they like it in /opt :-)
Oh I'd recommend probably editing the source to read the xmodmap from somewhere in through /tmp/whatever too, since by default it only uses ~/.Xmodmap, and you never know what some user might have that messes thing up.
-doh123
On Jun 23, 2011, at 5:47 PM, Tony Bernardin wrote:
Hi,
I'm making mac os x application bundle for one of my applications and would like to embed the XQuartz release into it. The reason herefore is that the default X11 on 10.6.x has a flaw that Apple has not been fixing and I would like to follow the typical bundle way where you simply need to drag the bundle onto your Applications folder to run it. My first question is, is can this be reasonably realized? So far I've thought of two approaches:
1. Get the XQuartz release, install it, then copy the /opt/X11 content to my My.app/Contents/Libraries/X11 and fix it up. I can modify all the install_names and even edit all the /opt/X11 paths that appear in scripts (e.g., startx), but I don't know what is all just hardcoded into some of the other executables.
2. Get the source and build a relocatable XQuartz to embed in the app bundle. I've been trying to follow the instructions here: http://xquartz.macosforge.org/trac/wiki/1.4-apple-git-10.5.5 but when I run autogen.sh for the xorg-macros it complains that I can't use a relative path as --prefix=../Libraries/X11. I'm not sure how the prefix gets used internally, i.e., does it contribute to producing paths that get injected into some of the code at compile time or not.
I would greatly welcome any advice on creating an embedable X11 release, such that I could run startx from my app bundle's start-up script and have it use only resources that are contained in the app bundle.
Thanks,
-- Tony Bernardin, Postdoctoral Researcher, W.M. Keck Center for Active Visualization in the Earth Sciences (KeckCAVES) University of California, Davis
_______________________________________________ Xquartz-dev mailing list Xquartz-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/xquartz-dev
_______________________________________________ Xquartz-dev mailing list Xquartz-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/xquartz-dev
-- Tony Bernardin, Postdoctoral Researcher, W.M. Keck Center for Active Visualization in the Earth Sciences (KeckCAVES) University of California, Davis
_______________________________________________ Xquartz-dev mailing list Xquartz-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/xquartz-dev
well it sure runs fine even on a machine without X11 of any type installed and with no startx that I know of on the machine... cannot say I'm an expert on how XQuartz works inside and out, but the method works fine for me. On Jun 24, 2011, at 12:34 AM, Jeremy Huddleston wrote:
On Jun 23, 2011, at 20:19, doh123 wrote:
I don't use startx... just run the main xserver executable directly (the X11.bin file in XQuartz.app).
Well, that actually executes startx (or triggers launchd to execute startx) ...
_______________________________________________ Xquartz-dev mailing list Xquartz-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/xquartz-dev
On Jun 23, 2011, at 17:54, Tony Bernardin wrote:
thanks for the reply doh123. I'll consider it, although I'm still holding out for someone to suggest a way it could be done "more cleanly".
Not really... there are going to be ugly hacks and tradeoffs to any approach you take to try this, and what you decide depends on what you want out of it.
Still I understand changing all the install_names after the fact, but what about all the other references to paths, e.g., in startx, they'd all point the /tmp/Whatever/... Do you also change these retroactively?
Yes, you'll need to make all that dynamic. It's a PITA and not something I'd ever be interested in doing. I'm still curious why you can't just install the .pkg and what you think is so terribly broken about XCode 2.3.6 --Jeremy
On Jun 23, 2011, at 15:47, Tony Bernardin wrote:
Hi,
I'm making mac os x application bundle for one of my applications and would like to embed the XQuartz release into it. The reason herefore is that the default X11 on 10.6.x has a flaw that Apple has not been fixing
What flaw? There are no known major issues in 10.6.5. If you were having problems (esp regressions), you should've said something months ago.
and I would like to follow the typical bundle way where you simply need to drag the bundle onto your Applications folder to run it. My first question is, is can this be reasonably realized?
Not without a TON of headaches and breaking other applications.
participants (3)
-
doh123
-
Jeremy Huddleston
-
Tony Bernardin