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: ""

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)