The Makefile comment for NEEDS_SSL_WITH_CRYPTO says to define it "if
you need -lcrypto with -lssl (Darwin)." However, what it actually
does is add -lssl when you use -lcrypto and not the other way around.
However, libcrypto contains a majority of the ERR_* functions from
OpenSSL (at least on OS X) so we need it both ways.
So, add NEEDS_CRYPTO_WITH_SSL which adds -lcrypto to the OpenSSL link
flags and clarify the difference between it and NEEDS_SSL_WITH_CRYPTO.
Signed-off-by: Brian Gernhardt <redacted>
---
Compilation using BLK_SHA1 on OS X 10.5 and 10.6 (at least) is still
broken without this patch.
Alex Riesen [off-list ref] pointed out that just adding LIB_4_CRYPTO
to git-imap-send is simpler, but judging from the fact that nobody else
has complained about this issue, I'm guessing that the need for -lcrypto
when using -lssl is not widespread. (Or BLK_SHA1 isn't getting used much
or those who do don't compile git-imap-send with SSL.)
Makefile | 8 +++++++-
1 files changed, 7 insertions(+), 1 deletions(-)
diff --git a/Makefile b/Makefile
index ce882d0..121be04 100644
--- a/Makefile
+++ b/Makefile
@@ -91,7 +91,9 @@ all::
# Define PPC_SHA1 environment variable when running make to make use of
# a bundled SHA1 routine optimized for PowerPC.
#
-# Define NEEDS_SSL_WITH_CRYPTO if you need -lcrypto with -lssl (Darwin).
+# Define NEEDS_CRYPTO_WITH_SSL if you need -lcrypto when using -lssl (Darwin).
+#
+# Define NEEDS_SSL_WITH_CRYPTO if you need -lssl when using -lcrypto (Darwin).
#
# Define NEEDS_LIBICONV if linking with libc is not enough (Darwin).
#
@@ -707,6 +709,7 @@ ifeq ($(uname_S),SCO_SV)
TAR = gtar
endif
ifeq ($(uname_S),Darwin)
+ NEEDS_CRYPTO_WITH_SSL = YesPlease
NEEDS_SSL_WITH_CRYPTO = YesPlease
NEEDS_LIBICONV = YesPlease
ifeq ($(shell expr "$(uname_R)" : '[15678]\.'),2)
@@ -1009,6 +1012,9 @@ ifndef NO_OPENSSL
else
OPENSSL_LINK =
endif
+ ifdef NEEDS_CRYPTO_WITH_SSL
+ OPENSSL_LINK += -lcrypto
+ endif
else
BASIC_CFLAGS += -DNO_OPENSSL
BLK_SHA1 = 1
--
1.6.4.2.420.g30ecf
Brian Gernhardt [off-list ref] writes:
The Makefile comment for NEEDS_SSL_WITH_CRYPTO says to define it "if
you need -lcrypto with -lssl (Darwin)." However, what it actually
does is add -lssl when you use -lcrypto and not the other way around.
Correct. That is worth fixing.
However, libcrypto contains a majority of the ERR_* functions from
OpenSSL (at least on OS X) so we need it both ways.
I see. We need to be able to see ERR_err_string(), whose caller happens
to be only imap-send.c for now, and that function is in -lcrypto together
with other ERR_* functions.
Compilation using BLK_SHA1 on OS X 10.5 and 10.6 (at least) is still
broken without this patch.
Alex Riesen [off-list ref] pointed out that just adding LIB_4_CRYPTO
to git-imap-send is simpler, but judging from the fact that nobody else
has complained about this issue, I'm guessing that the need for -lcrypto
when using -lssl is not widespread. (Or BLK_SHA1 isn't getting used much
or those who do don't compile git-imap-send with SSL.)
BLK_SHA1 is fairly new on 'master', so lack of breakage report is
expected.
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?
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