[RFC/H] Makefile fix for FC13?

[RFC/H] Makefile fix for FC13?

[Junio C Hamano]

As k.org is migrating to FC13, I'm also adding an FC13 bochs to my
collection so that I can cut releases for 32-bit i?86 archs.  I noticed
that the compilation fails with this:

      LINK git-imap-send
  /usr/bin/ld: imap-send.o: undefined reference to symbol 'EVP_DecodeBlock'
  /usr/bin/ld: note: 'EVP_DecodeBlock' is defined in DSO
  /lib/libcrypto.so.10 so try adding it to the linker command line

I understand that this is because the linker policy changed in the release
to make things safer.  My understanding of the rationale for the change
goes like this:

  When a binary (e.g. imap-send) wants a symbol X (e.g. EVP_DecodeBlock)
  from a library A (e.g. -lcrypto), and the binary also wants a different
  symbol from another library B (e.g. -lssl), and if the library B happens
  to depend on library A, it used to be sufficient to link the binary with
  library B, without explicitly linking it with library A, as library A
  will be pulled in at the runtime because library B wants it anyway.

  This however would break if library B stops depending on library A
  (i.e. library B gets updated while remaining compatible with its own
  older version, but its implementation no longer requries library A).  It
  is therefore safer to force programs to list their dependencies
  explicitly at link time.

So, I need a patch like the following to make things compile on FC13.

Thoughts?  Ideas for doing this (specifically, "make rpm") in better ways?

On my FC11 bochs and my other Linux boxes, the linker is loose but it does
not seem to hurt (and I do not think it should, as openssl-dev package
seems to have almost always shipped with both -lssl and -lcrypto) to add
this unconditionally.

diff --git a/Makefile b/Makefile
index 1f1ce04..18c7e8e 100644
--- a/Makefile
+++ b/Makefile
@@ -776,6 +776,7 @@ ifeq ($(uname_S),Linux)
 	NO_STRLCPY = YesPlease
 	NO_MKSTEMPS = YesPlease
 	HAVE_PATHS_H = YesPlease
+	NEEDS_CRYPTO_WITH_SSL = YesPlease
 endif
 ifeq ($(uname_S),GNU/kFreeBSD)
 	NO_STRLCPY = YesPlease

Re: [RFC/H] Makefile fix for FC13?

[Andreas Ericsson]

On 11/05/2010 11:59 PM, Junio C Hamano wrote:
> As k.org is migrating to FC13, I'm also adding an FC13 bochs to my
> collection so that I can cut releases for 32-bit i?86 archs.  I noticed
> that the compilation fails with this:
> 
>        LINK git-imap-send
>    /usr/bin/ld: imap-send.o: undefined reference to symbol 'EVP_DecodeBlock'
>    /usr/bin/ld: note: 'EVP_DecodeBlock' is defined in DSO
>    /lib/libcrypto.so.10 so try adding it to the linker command line
> 
> I understand that this is because the linker policy changed in the release
> to make things safer.  My understanding of the rationale for the change
> goes like this:
> 
>    When a binary (e.g. imap-send) wants a symbol X (e.g. EVP_DecodeBlock)
>    from a library A (e.g. -lcrypto), and the binary also wants a different
>    symbol from another library B (e.g. -lssl), and if the library B happens
>    to depend on library A, it used to be sufficient to link the binary with
>    library B, without explicitly linking it with library A, as library A
>    will be pulled in at the runtime because library B wants it anyway.
> 
>    This however would break if library B stops depending on library A
>    (i.e. library B gets updated while remaining compatible with its own
>    older version, but its implementation no longer requries library A).  It
>    is therefore safer to force programs to list their dependencies
>    explicitly at link time.
> 

That's probably fairly accurate.

> So, I need a patch like the following to make things compile on FC13.
> 
> Thoughts?  Ideas for doing this (specifically, "make rpm") in better ways?
> 

Not better, no. There are macros to distinguish the release type and version
though, so if you want to enable this only for FC13 and later, you could use
one of those. I have no idea what they're named, but google might provide
insight. See my next comment first though.

> On my FC11 bochs and my other Linux boxes, the linker is loose but it does
> not seem to hurt (and I do not think it should, as openssl-dev package
> seems to have almost always shipped with both -lssl and -lcrypto) to add
> this unconditionally.
> 

This has been working since RH6, and probably earlier too. I doubt it will
break anything. It doesn't on FC12 anyways.

> diff --git a/Makefile b/Makefile
> index 1f1ce04..18c7e8e 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -776,6 +776,7 @@ ifeq ($(uname_S),Linux)
>   	NO_STRLCPY = YesPlease
>   	NO_MKSTEMPS = YesPlease
>   	HAVE_PATHS_H = YesPlease
> +	NEEDS_CRYPTO_WITH_SSL = YesPlease
>   endif
>   ifeq ($(uname_S),GNU/kFreeBSD)
>   	NO_STRLCPY = YesPlease
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html


-- 
Andreas Ericsson                   andreas.ericsson@op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231

Considering the successes of the wars on alcohol, poverty, drugs and
terror, I think we should give some serious thought to declaring war
on peace.

Re: [RFC/H] Makefile fix for FC13?

[Michael J Gruber]

Junio C Hamano venit, vidit, dixit 05.11.2010 23:59:
> As k.org is migrating to FC13, I'm also adding an FC13 bochs to my
> collection so that I can cut releases for 32-bit i?86 archs.  I noticed
> that the compilation fails with this:
> 
>       LINK git-imap-send
>   /usr/bin/ld: imap-send.o: undefined reference to symbol 'EVP_DecodeBlock'
>   /usr/bin/ld: note: 'EVP_DecodeBlock' is defined in DSO
>   /lib/libcrypto.so.10 so try adding it to the linker command line
> 
> I understand that this is because the linker policy changed in the release
> to make things safer.  My understanding of the rationale for the change
> goes like this:
> 
>   When a binary (e.g. imap-send) wants a symbol X (e.g. EVP_DecodeBlock)
>   from a library A (e.g. -lcrypto), and the binary also wants a different
>   symbol from another library B (e.g. -lssl), and if the library B happens
>   to depend on library A, it used to be sufficient to link the binary with
>   library B, without explicitly linking it with library A, as library A
>   will be pulled in at the runtime because library B wants it anyway.
> 
>   This however would break if library B stops depending on library A
>   (i.e. library B gets updated while remaining compatible with its own
>   older version, but its implementation no longer requries library A).  It
>   is therefore safer to force programs to list their dependencies
>   explicitly at link time.
> 
> So, I need a patch like the following to make things compile on FC13.
> 
> Thoughts?  Ideas for doing this (specifically, "make rpm") in better ways?

I was wondering why I never ran into this on F13 (nor F14). Must have
something to do with "NO_OPENSSL=y" in my config.mak... But I realize
that even with BLK_SHA1 we need openssl for imap+ssl.

I guess this goes to show that a statement like "tested on F13" depends
quite a bit on the config.

The official Fedora packages are built with:

BLK_SHA1 = 1
NEEDS_CRYPTO_WITH_SSL = 1
NO_PYTHON = 1


> On my FC11 bochs and my other Linux boxes, the linker is loose but it does
> not seem to hurt (and I do not think it should, as openssl-dev package
> seems to have almost always shipped with both -lssl and -lcrypto) to add
> this unconditionally.
> 
> diff --git a/Makefile b/Makefile
> index 1f1ce04..18c7e8e 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -776,6 +776,7 @@ ifeq ($(uname_S),Linux)
>  	NO_STRLCPY = YesPlease
>  	NO_MKSTEMPS = YesPlease
>  	HAVE_PATHS_H = YesPlease
> +	NEEDS_CRYPTO_WITH_SSL = YesPlease
>  endif
>  ifeq ($(uname_S),GNU/kFreeBSD)
>  	NO_STRLCPY = YesPlease