On Sep 8, 2009, at 4:19 PM, Junio C Hamano wrote:
The patch makes sense to me, but as the result, depending on platforms
and configuration, we would use three variations when linking imap-
send
with no NO_OPENSSL defined:
* Both -lcrypto -lssl
* Only -lssl
* Only -lcrypto
I wonder if we can simplify this in some way (not a 1.6.5 topic).
I am suspecting that the reason we do not say "always both" is because
depending on the vintage of OpenSSL one or the other is missing?
It just occurred to me that I have a Debian machine to test this on.
I generally don't use my web server for testing, but testing a compile
should be safe enough.
Sure enough, it compiles without this patch. It may be a difference
between the linkers. It appears that ERR_error_string() is in
libcrypto for both OS X and Debian and that libssl.{so,dylib} both
have load commands for libcrypto.{so,dylib}, but OS X ld is pickier
than Debian ld. Odd.
I don't see a scenario where only -lcrypto would be used for imap-
send, actually. That would imply that we're using OpenSSL's SHA-1
algorithm but not using it for IMAPS access. SSL_WITH_CRYPTO is about
needing -lssl when using -lcrypto for SHA-1 while CRYPTO_WITH_SSL is
about needing -lcrypto when using -lssl for SSL.
The only simplification I can think of is to make
NEEDS_CRYPTO_WITH_SSL and NEEDS_SSL_WITH_CRYPTO be the same, so that
it will include both any time it includes either one.
NEEDS_SSL_WITH_CRYPTO is set for UnixWare, SCO_SV, and OS X. I only
have the latter to test with so I don't know if the symmetry is true
for the other two.
~~ Brian
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html