Worked around bug/weirdness on OS X. It's reporting that a

non-blocking connect is available for writing (i.e. the connection
was successful) when the connection has actually failed.  This
caused synergy to rapidly retry connecting.  This change makes
synergy check for a connection error whether one was reported or
not.  Thankfully, OS X does correctly set the socket error state
when it bogusly reports a successful connection so we can tell the
connection failed.

lib/net/CTCPSocket.cpp

@@ -442,7 +442,7 @@ CTCPSocket::serviceConnecting(ISocketMultiplexerJob* job,
 	// connection refused.  when that happens it at least doesn't
 	// report the socket as being writable so synergy is able to time
 	// out the attempt.)
-	if (true || error) {
+	if (error || true) {
 		try {
 			// connection may have failed or succeeded
 			ARCH->throwErrorOnSocket(m_socket);