Re: [PATCH] imap-send: link against libcrypto for HMAC and others

From: Junio C Hamano <gitster@pobox.com>
Date: Dec 6, 2010, 06:11 UTC
Message-ID: <7v39qbtoq9.fsf@alter.siamese.dyndns.org>
In-Reply-To: <1291613978.4756.157.camel@yamato.local>

Diego Elio Pettenò <flameeyes@gmail.com> writes:

Show 17 quoted lines

> Il giorno lun, 06/12/2010 alle 00.28 -0500, Anders Kaseorg ha scritto:
>> This broke the build with NO_OPENSSL=1, so Debian will need to revert
>> it:
>
> I'll try a NO_OPENSSL build later on today and see to get it fixed.
>
>> Also, the Makefile already has a NEEDS_CRYPTO_WITH_SSL flag that’s
>> automatically set on Darwin, Windows, and MinGW.  We shouldn’t have two
>> mechanisms for addressing the same problem; maybe we just need to enable
>> the existing flag on more (or all) platforms?
>
> No, these should be different issues; you may have a libssl (which uses
> libcrypto) requiring libcrypto to be linked in, even if you only use
> interfaces from libssl (and that's what NEEDS_CRYPTO_WITH_SSL seem to be
> designed to deal with), but in this case what you have is rather
> imap-send using the libcrypto interfaces _as well as_ the libssl
> interfaces.

You are both correct; the point of NO_OPENSSL is not to link with anything from openssl suite, so we need a separate mechanism to address this.

Anders, wouldn't this be a better fix for NO_OPENSSL build, than reverting a fix for an incorrect ld invocation?

 Makefile |    4 ++++
 1 files changed, 4 insertions(+), 0 deletions(-)

diff --git a/Makefile b/Makefile
index 7a5fb69..b20ae1a 100644
--- a/Makefile
+++ b/Makefile
@@ -1296,11 +1296,15 @@ else
 	BLK_SHA1 = 1
 	OPENSSL_LIBSSL =
 endif
+ifdef NO_OPENSSL
+	LIB_4_CRYPTO =
+else
 ifdef NEEDS_SSL_WITH_CRYPTO
 	LIB_4_CRYPTO = $(OPENSSL_LINK) -lcrypto -lssl
 else
 	LIB_4_CRYPTO = $(OPENSSL_LINK) -lcrypto
 endif
+endif
 ifdef NEEDS_LIBICONV
 	ifdef ICONVDIR
 		BASIC_CFLAGS += -I$(ICONVDIR)/include