Typo above, libssl.sl should be libssl.so

also, after making a symlink for libssl.so.10 to libssl.so.1.0.0 synergy threw another error because libcrypto.so.10 was not found

final working workaround:
cd /usr/lib
sudo ln -s libssl.so.1.0.0 libssl.so.10
sudo ln -s libcrypto.so.1.0.0 libcrypto.so.10

I have the same error and did the same ugly workaround :)

Levente, you had an interest in this. Please fix. :P

Also got this bug. Didn´t try this workaround yet because I´m at work, but as soon as I get home I´ll try it.

The hacky workaround will work as the downloaded libns.so links against that, but it is a no-go for a distribution level fix.
I could only compile libns.so myself and don't have the proprietary libns.so version to test a sane workaround. Can anyone provide a copy of that libns.so that is downloaded from their servers?

Do you have any way that i can send you the file without making it publicly available? I'm not sure about whether or not i'm allowed to make it public since you need a subscription to get the file itself... I called synergy support and left a message, i'm waiting to hear back from them.

The source code is publicly available at github, I can compile the plugin myself as its available and licensed under GPL2. They still have routines available that it will only get loaded by synergy and work if you login to the form at startup so there shouldn't be any problem. I just need the proprietary (binary) version so i can look at it and check how they build it so i can think about a sane patch/fix for this package without creating such stupid symlinks in /usr/lib just to satisfy synergy plugin insanity. You can drop it to anthraxx@archlinux.org.

file sent, let me know if you need more

Great to see you take interest in this Levente, I'm also availible if you should require assistance.

Just saw on https://www.archlinux.org/packages/community/x86_64/synergy/ that we had an update to the new version. I´m not at home right now (so, without my arch). This update is already including the patch for this bug we were talking about?

its known upstream but nope: it does not fix the issue.
I already have an idea how to patch that without the need to binary patch upstream libns.so. Will make some tests with it at the weekend.

Great, thanks for that. ;]

Just used the workaround and worked just fine.

I just got a call from Wes at synergy and He would be more than happy to fix the issue upstream but he needs to speak with someone who knows cmake who can help with the fix.

I passed his contact info to Levente.

Any status on this?

did you try 1.7.3? They claim to have fixed issues.
As a sane workaround you can try to replace your libns.so somewhere your ~/.synergy directory with the one shipped in /usr/lib/synergy/libns.so.
Please give feedback which of both ways actually worked (without the symlink hack).
The patch will require quite more work as its not that easy to replace their stupidity without destroying their remote dl functionality. But maybe it should simple be patched out as its dangerous anyway to pull in remote code via HTTP.

Using the new version, and for me is not working. Funny is, it was working before after creating those two links, but now, after upgrading synergy, it stopped working. Before you ask, already tried to remove the links: sudo rm libssl.so.10 and sudo rm libcrypto.so.10.

i'll upgrade and see if i can figure out a workaround when i get to my synergy system tomorrow

you have to replace your libns.so in your home directory with the one from /usr/lib/synergy/libns.so

fixed the ridiculous upstream incompetence by adding a patch for the plugin detection

Should I hang on for 1.7.3-2 or is the fix out in 1.7.3-1?

1.7.3-2 contains the fix for the plugin loading mechanics as upstream broke their whole plugin system with 1.7.3 stock. If you updated to 1.7.3-2 please remove the libns.so somewhere in your ~/.synergy and either let it download or put the one under /usr/lib/synergy/libns.so there.
Please give feedback if the new downloaded libns.so, the one from /usr/lib/synergy or both work.

So we just need to wait until the 1.7.3-2 comes up in the repositories. So far, can only see the 1.7.3-1. As far as it appears, I´ll check it and let you know if it works. https://www.archlinux.org/packages/community/x86_64/synergy/

It seems fine for me. Just installed your patched version and everything is fine again. Just had to run the assistent again. Thanks and congrats.

Upgraded to 1.7.3-2 and deleted the links libssl.so.10 and libcrypto.so.10 on synergy server. Ran wizard to let it download the "ns" plugin to ~/.synergy/plugins/libns.so, but the synergy client failed to connect with error:

ERROR: ssl error occurred (generic failure)
ERROR: error:140770FC:SSL routines:SSL23_GET_SERVER_HELLO:unknown protocol
ERROR: failed to connect secure socket
NOTE: disconnected from server
NOTE: stopped client

Noticed different hashes: md5sum /usr/lib/synergy/libns.so ~/.synergy/plugins/libns.so
9768f7e16d667beca1e42c312a6fe6fc /usr/lib/synergy/libns.so
ea6e5780ac06e24a78db17bf1e9bb18d ~/.synergy/plugins/libns.so

Fixed it by deleting ~/.synergy/plugins/libns.so and copying /usr/lib/synergy/libns.so to ~/.synergy/plugins.

I had no issue installing 1.7.3-2 worked right out of the box, but I had not installed 1.7.3-1.

Sooo is this solved then?

This is not solved yet. Fresh install of Arch Linux (as of 2015-05-13) and then fresh install of Synergy 1.7.3-2 (as of 2015-06-10) did not work OOTB. I had to use Adam's work around.

Saw this same bug with a fresh install of 1.7.3-2 today. Adam's symlink fix solved it though.

yes the thread is long but dont just follow the first post -,-
I will release an update next week but im highly busy this weekend.
If you want to solve it properly, use the /usr/lib/synergy library and do not symlink openssl

using a wrapper to setup libns.so automagically, will leave this some days open but 1.7.3-3 should resolve all issues.
feedback is welcome.