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

Diego Elio Pettenò [off-list ref] writes:

Il giorno lun, 06/12/2010 alle 00.28 -0500, Anders Kaseorg ha scritto:

quoted

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.

quoted

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

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?

Could we get this fixup patch into master? Leaving the original patch
in without it doesn't seem like a good idea when it breaks the build.

On Sun, 5 Dec 2010, Junio C Hamano wrote:

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

It works for me.  I agree it isn’t beautiful but I don’t think I have a 
better idea at this time.

(It’s worth pointing out that $(OPENSSL_LINK) is duplicated in the 
git-imap-send build command, once directly and once indirectly via 
$(LIB_4_CRYPTO), but I assume this is intentional for clarity.)

Anders