Hi guys,
I can succesfully build the DMG on my MacBook (OSX 10.8). I have gone with MacPorts instead of Homebrew, since installing nxcomp/nxproxy with Homebrew isn't straightforward currently. The macbuild.sh script creates a nice dmg for me, and it works fine on my system. However, when I try it on a different system, which doesn't have XCode and MacPorts, it won't start at all. It gives an error report which boils down to it not being able to load the dependent libraries. Specifically it tries to load /opt/local/lib/libcrypto-1.0.0.dylib which doesn't exist on this other system. It is x2goclient.app/Contents/Frameworks/libssl-1.0.0.dylib which references it. The official dmg released by Clemens works fine, it is only my build of it, which has problems. Why does in try to load libcrypto-1.0.0.dylib from /opt instead of the on included in Contents/Frameworks? (I have checked, libcrypto-1.0.0.dylib IS in there).
I am on a completely clean install of newest MacPorts and have nothing except x2goclient+deps installed there.
And no, just using the official DMG isn't currently an option as we want to provide a simple way for our users to access our new x2gobroker setup. If we don't customize the startup script, they would have to start it from a cmd-line with --broker-url args. This first build however hasn't been customized at all. It is just the official 4.0.0.4 source tarball with no changes.
-- Anders Bruun Olsen It-ansvarlig Det Danske Sprog- og Litteraturselskab (Society for Danish Language and Literature)
On Tue, Mar 05, 2013 at 11:16:01AM +0100, Anders Bruun Olsen wrote:
Specifically it tries to load /opt/local/lib/libcrypto-1.0.0.dylib which doesn't exist on this other system. It is x2goclient.app/Contents/Frameworks/libssl-1.0.0.dylib which references it.
Please provide the output of $> otool -L x2goclient.app/Contents/MacOS/x2goclient $> otool -L x2goclient.app/Contents/Resources/exe/nxproxy $> otool -L x2goclient.app/Contents/Frameworks/libssl-1.0.0.dylib
Also pay attention to any dylibbundler error messages printed during packaging -- openssl has the habit to install their libraries ugo-w, which causes dylibbundler to choke when it tries to modify the library paths using install_name_tool(1). My fix for this currently is changing the modes manually.
-- Clemens Lang MacPorts Developer
Right on the money!
The problem was that libssl-1.0.0.dylib was linked to the wrong lib in the DMG. Adding +w rights to libssl and libcrypto in /opt/local/lib fixed that. Looking at output from dylibbundler reveals another problem though:
Log: Deploying Qt frameworks found inside: ("./x2goclient.app/Contents/PlugIns/imageformats/libqtiff.dylib") Log: copied: "/opt/local/lib/libtiff.5.dylib" Log: to "./x2goclient.app/Contents/Frameworks//libtiff.5.dylib" ERROR: "install_name_tool: changing install names or rpaths can't be redone for: ./x2goclient.app/Contents/Frameworks//libtiff.5.dylib (for architecture x86_64) because larger updated load commands do not fit (the program must be relinked, and you may need to use -headerpad or -headerpad_max_install_names) " ERROR: "" ERROR: "install_name_tool: changing install names or rpaths can't be redone for: ./x2goclient.app/Contents/Frameworks//libtiff.5.dylib (for architecture x86_64) because larger updated load commands do not fit (the program must be relinked, and you may need to use -headerpad or -headerpad_max_install_names) " ERROR: ""
I have added +w to libtiff.5.dylib. Any idea what could be the problem there?
2013/3/5 Clemens Lang <neverpanic@gmail.com>
On Tue, Mar 05, 2013 at 11:16:01AM +0100, Anders Bruun Olsen wrote:
Specifically it tries to load /opt/local/lib/libcrypto-1.0.0.dylib which doesn't exist on this other system. It is x2goclient.app/Contents/Frameworks/libssl-1.0.0.dylib which references it.
Please provide the output of $> otool -L x2goclient.app/Contents/MacOS/x2goclient $> otool -L x2goclient.app/Contents/Resources/exe/nxproxy $> otool -L x2goclient.app/Contents/Frameworks/libssl-1.0.0.dylib
Also pay attention to any dylibbundler error messages printed during packaging -- openssl has the habit to install their libraries ugo-w, which causes dylibbundler to choke when it tries to modify the library paths using install_name_tool(1). My fix for this currently is changing the modes manually.
-- Clemens Lang MacPorts Developer
-- Anders Bruun Olsen It-ansvarlig Det Danske Sprog- og Litteraturselskab (Society for Danish Language and Literature)
2013/3/5 Anders Bruun Olsen <abo@dsl.dk>
ERROR: "install_name_tool: changing install names or rpaths can't be redone for: ./x2goclient.app/Contents/Frameworks//libtiff.5.dylib (for architecture x86_64) because larger updated load commands do not fit (the program must be relinked, and you may need to use -headerpad or -headerpad_max_install_names) " I have added +w to libtiff.5.dylib. Any idea what could be the problem there?
I should add that the resulting DMG and .app does seem to work, but I don't usually ignore error messages like that unless told that they are harmless :)
-- Anders Bruun Olsen It-ansvarlig Det Danske Sprog- og Litteraturselskab (Society for Danish Language and Literature)
On Tue, Mar 05, 2013 at 12:03:33PM +0100, Anders Bruun Olsen wrote:
Log: Deploying Qt frameworks found inside: ("./x2goclient.app/Contents/PlugIns/imageformats/libqtiff.dylib") Log: copied: "/opt/local/lib/libtiff.5.dylib" Log: to "./x2goclient.app/Contents/Frameworks//libtiff.5.dylib" ERROR: "install_name_tool: changing install names or rpaths can't be redone for: ./x2goclient.app/Contents/Frameworks//libtiff.5.dylib (for architecture x86_64) because larger updated load commands do not fit (the program must be relinked, and you may need to use -headerpad or -headerpad_max_install_names) " ERROR: "" ERROR: "install_name_tool: changing install names or rpaths can't be redone for: ./x2goclient.app/Contents/Frameworks//libtiff.5.dylib (for architecture x86_64) because larger updated load commands do not fit (the program must be relinked, and you may need to use -headerpad or -headerpad_max_install_names) " ERROR: ""
I have added +w to libtiff.5.dylib. Any idea what could be the problem there?
liftiff needs to be built with -headerpad_max_install_named. See http://trac.macports.org/changeset/103701 where I fixed this in MacPorts. Since I didn't increase the revision, if you were using MacPorts to install your copy of libtiff, you need to run sudo port selfupdate sudo port -s -n upgrade --force tiff to get the change.
-- Clemens Lang MacPorts Developer
2013/3/5 Clemens Lang <neverpanic@gmail.com>
liftiff needs to be built with -headerpad_max_install_named. See http://trac.macports.org/changeset/103701 where I fixed this in MacPorts. Since I didn't increase the revision, if you were using MacPorts to install your copy of libtiff, you need to run sudo port selfupdate sudo port -s -n upgrade --force tiff to get the change.
Excellent. That fixed all of the build problems. Thank you! :)
Next question: How would I go about getting the .app to start x2goclient with --broker-url added? It seems that just changing Info.plist isn't an option, since Apple apparently hates cmd-line arguments and doesn't provide a way to include these here. Would I need to patch the source code to just pretend --broker-url is set, or perhaps provide a seperate script to start the client with the right arguments?
Just to make it absolutely clear what I am trying to accomplish: I want to be able to distribute a .dmg to my users, that they install in the standard Mac-way of dragging a .app to their /Applications folder. This .app will just connect to our x2gobroker and ask the user to authenticate when it is started.
-- Anders Bruun Olsen It-ansvarlig Det Danske Sprog- og Litteraturselskab (Society for Danish Language and Literature)
On Tue, Mar 05, 2013 at 01:08:38PM +0100, Anders Bruun Olsen wrote:
Next question: How would I go about getting the .app to start x2goclient with --broker-url added? It seems that just changing Info.plist isn't an option, since Apple apparently hates cmd-line arguments and doesn't provide a way to include these here. Would I need to patch the source code to just pretend --broker-url is set, or perhaps provide a seperate script to start the client with the right arguments?
You could rename x2goclient.app/Contents/MacOS/x2goclient to x2goclient.bin and create a small script named x2goclient into the directory that will run the binary with the required arguments.
-- Clemens Lang MacPorts Developer
2013/3/5 Clemens Lang <neverpanic@gmail.com>
Next question: How would I go about getting the .app to start x2goclient with --broker-url added? It seems that just changing Info.plist isn't an option, since Apple apparently hates cmd-line arguments and doesn't provide a way to include these here. Would I need to patch the source code to just pretend --broker-url is set, or perhaps provide a seperate script to start the client with the right arguments? You could rename x2goclient.app/Contents/MacOS/x2goclient to x2goclient.bin and create a small script named x2goclient into the
On Tue, Mar 05, 2013 at 01:08:38PM +0100, Anders Bruun Olsen wrote: directory that will run the binary with the required arguments.
Not a bad idea. Would it be relatively simple to modify the build script to include this new script and thus have it in the dmg? If not, I will just make the changes in the .app and distribute a zipped version of that, but I think distributing a dmg is nicer.
-- Anders Bruun Olsen It-ansvarlig Det Danske Sprog- og Litteraturselskab (Society for Danish Language and Literature)
On Tue, Mar 05, 2013 at 02:31:54PM +0100, Anders Bruun Olsen wrote:
Would it be relatively simple to modify the build script to include this new script and thus have it in the dmg?
It should be relatively straightforward to add this between building and preparing the app bundle for distribution and actually packaging it into the .dmg. The phases are marked in the script, so it should be hard to find.
-- Clemens Lang MacPorts Developer
2013/3/5 Clemens Lang <neverpanic@gmail.com>
On Tue, Mar 05, 2013 at 03:07:35PM +0100, Clemens Lang wrote:
[...] The phases are marked in the script, so it should be hard to find. Obviously I meant it should *not* be hard to find.
And it wasn't. I have successfully built a dmg with our custom start-script. Thank you for your help :)
Now we just need the bug in x2goclient on OSX, where you can't login when using the broker, fixed (as well as a few things in the broker itself) and we're very close to being in business :)
-- Anders Bruun Olsen It-ansvarlig Det Danske Sprog- og Litteraturselskab (Society for Danish Language and Literature)
On 2013-03-06 10:41, Anders Bruun Olsen wrote:
And it wasn't. I have successfully built a dmg with our custom start-script. Thank you for your help :)
Is it reasonable to feed your adjustments back upstream?
Morty
-- Dipl.-Ing. Moritz 'Morty' Struebe (Wissenschaftlicher Mitarbeiter) Lehrstuhl für Informatik 4 (Verteilte Systeme und Betriebssysteme) Friedrich-Alexander-Universität Erlangen-Nürnberg Martensstr. 1 91058 Erlangen
Tel : +49 9131 85-25419 Fax : +49 9131 85-28732 eMail : struebe@informatik.uni-erlangen.de WWW : http://www4.informatik.uni-erlangen.de/~morty
2013/3/6 Moritz Struebe <Moritz.Struebe@informatik.uni-erlangen.de>
On 2013-03-06 10:41, Anders Bruun Olsen wrote:
And it wasn't. I have successfully built a dmg with our custom start-script. Thank you for your help :) Is it reasonable to feed your adjustments back upstream?
Probably not. But a guide could be written so others who wants to do a custom build that will automatically initiate a logon to your terminal server(s) can learn how to do that. I'm going to do a quick write-up and post to the list. Perhaps somebody will add it to the wiki (once it is moved) if anybody finds it useful.
-- Anders Bruun Olsen It-ansvarlig Det Danske Sprog- og Litteraturselskab (Society for Danish Language and Literature)
-
Anders Bruun Olsen -
Clemens Lang -
Moritz Struebe