Sencha Animator OS X 10.5.8 login failed

[peterjjohnson]

I am having the same problem on Linux. Is this a Windows versus *NIX issue?

[jarrednicholls]

Hi Peter,

The issue on OS X Leopard (10.5.8) was OpenSSL recognition. On Linux and Windows, OpenSSL binaries are deployed with the application and should be picked up and recognized.

Are you behind a proxy server? The other issue that might cause a failed connection is a proxy server that cannot be automatically "understood" by the application. Windows and OS X provide automatic proxy solutions, but there is no such capability for Linux. We'll be adding manual proxy configuration support before the 1.0 release.

If you aren't behind a proxy server, what distribution of Linux (and its version) are you running?

[peterjjohnson]

I'm not behind a proxy server. I am using a home router for a wireless network, but I haven't had any other problems like this. I'm using Slackware 12.0; I'm not having problems with any other (https) sites.

[jarrednicholls]

Wow, I haven't used Slackware in like 5 years! :-)

Well we definitely don't build against Slackware, so it's entirely possible that our packaged OpenSSL binaries are not compatible with Slackware's libc/libz. Do you have OpenSSL installed on your system from Slackware's package manager? We require version 0.9.8...if Slackware has a 0.9.8 build of OpenSSL available in its package manager, perhaps installing that will resolve the issue.

Side Note: we build on Ubuntu Hardy Heron (8.04), which was released in April 2008. Slackware 12 was released in January 2008. Some of the software dependencies might be too "new" for Slackware 12 to handle. The fact that the application is launching for you is a very good sign, and I think we're just at the point of getting OpenSSL to work.

[peterjjohnson]

As near as I can tell, I have 9.8 installed.

[jarrednicholls]

Where are your OpenSSL libraries installed? /usr/lib? /usr/local/lib?

[peterjjohnson]

They seem to be present in a number of places under /usr/lib: /usr/lib, /usr/lib/seamonkey, /usr/lib/thunderbird, /usr/lib/firefox. In /usr/lib, the main library is /usr/lib/libssl.so.0.9.8; that's where the link /usr/lib/libssl.so points. In the mozilla directories, it's named libssl3.so.

[jarrednicholls]

You can try making a backup of libcrypto.so.0.9.8 and libssl.so.0.9.8 under /usr/lib and create symbolic links to the libs in your animator installation directory. For example, if you installed at /home/peter/SenchaAnimator, you can run these commands (as root or using sudo):

$: mv /usr/lib/libcrypto.so.0.9.8 /usr/lib/libcrypto.so.0.9.8.bak && ln -s /home/peter/SenchaAnimator/libcrypto.so.0.9.8 /usr/lib/libcrypto.so.0.9.8
$: mv /usr/lib/libssl.so.0.9.8 /usr/lib/libssl.so.0.9.8.bak && ln -s /home/peter/SenchaAnimator/libssl.so.0.9.8 /usr/lib/libssl.so.0.9.8

The application is finding your OpenSSL lib before it finds the one located in the animator's install dir, and your version may not be (for some reason) binary compatible. Creating a symbolic link in /usr/lib that points to the animator directory might solve the issue. If it does not, then I have another solution to getting you up and running that doesn't involve fixing OpenSSL.

We'll be sure to hard link the OpenSSL libs to the application rather than dynamically resolve the OpenSSL symbols, before the 1.0 release. Then we won't have this type of issue.