{"thread":{"id":"25653","subject":"[RFC/H] Makefile fix for FC13?","startedAt":"2010-11-05T22:59:38Z","lastAt":"2010-11-06T11:26:10Z","messageCount":3,"participants":["Junio C Hamano","Andreas Ericsson","Michael J Gruber"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"155275","messageId":"7vr5ezqsv9.fsf@alter.siamese.dyndns.org","threadId":"25653","inReplyTo":null,"subject":"[RFC/H] Makefile fix for FC13?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2010-11-05T22:59:38Z","receivedAt":"2010-11-05T22:59:38Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"As k.org is migrating to FC13, I'm also adding an FC13 bochs to my\ncollection so that I can cut releases for 32-bit i?86 archs.  I noticed\nthat the compilation fails with this:\n\n      LINK git-imap-send\n  /usr/bin/ld: imap-send.o: undefined reference to symbol 'EVP_DecodeBlock'\n  /usr/bin/ld: note: 'EVP_DecodeBlock' is defined in DSO\n  /lib/libcrypto.so.10 so try adding it to the linker command line\n\nI understand that this is because the linker policy changed in the release\nto make things safer.  My understanding of the rationale for the change\ngoes like this:\n\n  When a binary (e.g. imap-send) wants a symbol X (e.g. EVP_DecodeBlock)\n  from a library A (e.g. -lcrypto), and the binary also wants a different\n  symbol from another library B (e.g. -lssl), and if the library B happens\n  to depend on library A, it used to be sufficient to link the binary with\n  library B, without explicitly linking it with library A, as library A\n  will be pulled in at the runtime because library B wants it anyway.\n\n  This however would break if library B stops depending on library A\n  (i.e. library B gets updated while remaining compatible with its own\n  older version, but its implementation no longer requries library A).  It\n  is therefore safer to force programs to list their dependencies\n  explicitly at link time.\n\nSo, I need a patch like the following to make things compile on FC13.\n\nThoughts?  Ideas for doing this (specifically, \"make rpm\") in better ways?\n\nOn my FC11 bochs and my other Linux boxes, the linker is loose but it does\nnot seem to hurt (and I do not think it should, as openssl-dev package\nseems to have almost always shipped with both -lssl and -lcrypto) to add\nthis unconditionally.\n\ndiff --git a/Makefile b/Makefile\nindex 1f1ce04..18c7e8e 100644\n--- a/Makefile\n+++ b/Makefile\n@@ -776,6 +776,7 @@ ifeq ($(uname_S),Linux)\n \tNO_STRLCPY = YesPlease\n \tNO_MKSTEMPS = YesPlease\n \tHAVE_PATHS_H = YesPlease\n+\tNEEDS_CRYPTO_WITH_SSL = YesPlease\n endif\n ifeq ($(uname_S),GNU/kFreeBSD)\n \tNO_STRLCPY = YesPlease\n"},{"id":"155276","messageId":"4CD49686.3070800@op5.se","threadId":"25653","inReplyTo":"7vr5ezqsv9.fsf@alter.siamese.dyndns.org","subject":"Re: [RFC/H] Makefile fix for FC13?","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2010-11-05T23:43:02Z","receivedAt":"2010-11-05T23:43:02Z","isPatch":false,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"On 11/05/2010 11:59 PM, Junio C Hamano wrote:\n> As k.org is migrating to FC13, I'm also adding an FC13 bochs to my\n> collection so that I can cut releases for 32-bit i?86 archs.  I noticed\n> that the compilation fails with this:\n> \n>        LINK git-imap-send\n>    /usr/bin/ld: imap-send.o: undefined reference to symbol 'EVP_DecodeBlock'\n>    /usr/bin/ld: note: 'EVP_DecodeBlock' is defined in DSO\n>    /lib/libcrypto.so.10 so try adding it to the linker command line\n> \n> I understand that this is because the linker policy changed in the release\n> to make things safer.  My understanding of the rationale for the change\n> goes like this:\n> \n>    When a binary (e.g. imap-send) wants a symbol X (e.g. EVP_DecodeBlock)\n>    from a library A (e.g. -lcrypto), and the binary also wants a different\n>    symbol from another library B (e.g. -lssl), and if the library B happens\n>    to depend on library A, it used to be sufficient to link the binary with\n>    library B, without explicitly linking it with library A, as library A\n>    will be pulled in at the runtime because library B wants it anyway.\n> \n>    This however would break if library B stops depending on library A\n>    (i.e. library B gets updated while remaining compatible with its own\n>    older version, but its implementation no longer requries library A).  It\n>    is therefore safer to force programs to list their dependencies\n>    explicitly at link time.\n> \n\nThat's probably fairly accurate.\n\n> So, I need a patch like the following to make things compile on FC13.\n> \n> Thoughts?  Ideas for doing this (specifically, \"make rpm\") in better ways?\n> \n\nNot better, no. There are macros to distinguish the release type and version\nthough, so if you want to enable this only for FC13 and later, you could use\none of those. I have no idea what they're named, but google might provide\ninsight. See my next comment first though.\n\n> On my FC11 bochs and my other Linux boxes, the linker is loose but it does\n> not seem to hurt (and I do not think it should, as openssl-dev package\n> seems to have almost always shipped with both -lssl and -lcrypto) to add\n> this unconditionally.\n> \n\nThis has been working since RH6, and probably earlier too. I doubt it will\nbreak anything. It doesn't on FC12 anyways.\n\n> diff --git a/Makefile b/Makefile\n> index 1f1ce04..18c7e8e 100644\n> --- a/Makefile\n> +++ b/Makefile\n> @@ -776,6 +776,7 @@ ifeq ($(uname_S),Linux)\n>   \tNO_STRLCPY = YesPlease\n>   \tNO_MKSTEMPS = YesPlease\n>   \tHAVE_PATHS_H = YesPlease\n> +\tNEEDS_CRYPTO_WITH_SSL = YesPlease\n>   endif\n>   ifeq ($(uname_S),GNU/kFreeBSD)\n>   \tNO_STRLCPY = YesPlease\n> --\n> To unsubscribe from this list: send the line \"unsubscribe git\" in\n> the body of a message to majordomo@vger.kernel.org\n> More majordomo info at  http://vger.kernel.org/majordomo-info.html\n\n\n-- \nAndreas Ericsson                   andreas.ericsson@op5.se\nOP5 AB                             www.op5.se\nTel: +46 8-230225                  Fax: +46 8-230231\n\nConsidering the successes of the wars on alcohol, poverty, drugs and\nterror, I think we should give some serious thought to declaring war\non peace.\n"},{"id":"155286","messageId":"4CD53B52.8050805@drmicha.warpmail.net","threadId":"25653","inReplyTo":"7vr5ezqsv9.fsf@alter.siamese.dyndns.org","subject":"Re: [RFC/H] Makefile fix for FC13?","fromName":"Michael J Gruber","fromEmail":"git@drmicha.warpmail.net","sentAt":"2010-11-06T11:26:10Z","receivedAt":"2010-11-06T11:26:10Z","isPatch":false,"sender":{"key":"git@grubix.eu","avatar":"https://avatars.githubusercontent.com/u/233215?v=4"},"body":"Junio C Hamano venit, vidit, dixit 05.11.2010 23:59:\n> As k.org is migrating to FC13, I'm also adding an FC13 bochs to my\n> collection so that I can cut releases for 32-bit i?86 archs.  I noticed\n> that the compilation fails with this:\n> \n>       LINK git-imap-send\n>   /usr/bin/ld: imap-send.o: undefined reference to symbol 'EVP_DecodeBlock'\n>   /usr/bin/ld: note: 'EVP_DecodeBlock' is defined in DSO\n>   /lib/libcrypto.so.10 so try adding it to the linker command line\n> \n> I understand that this is because the linker policy changed in the release\n> to make things safer.  My understanding of the rationale for the change\n> goes like this:\n> \n>   When a binary (e.g. imap-send) wants a symbol X (e.g. EVP_DecodeBlock)\n>   from a library A (e.g. -lcrypto), and the binary also wants a different\n>   symbol from another library B (e.g. -lssl), and if the library B happens\n>   to depend on library A, it used to be sufficient to link the binary with\n>   library B, without explicitly linking it with library A, as library A\n>   will be pulled in at the runtime because library B wants it anyway.\n> \n>   This however would break if library B stops depending on library A\n>   (i.e. library B gets updated while remaining compatible with its own\n>   older version, but its implementation no longer requries library A).  It\n>   is therefore safer to force programs to list their dependencies\n>   explicitly at link time.\n> \n> So, I need a patch like the following to make things compile on FC13.\n> \n> Thoughts?  Ideas for doing this (specifically, \"make rpm\") in better ways?\n\nI was wondering why I never ran into this on F13 (nor F14). Must have\nsomething to do with \"NO_OPENSSL=y\" in my config.mak... But I realize\nthat even with BLK_SHA1 we need openssl for imap+ssl.\n\nI guess this goes to show that a statement like \"tested on F13\" depends\nquite a bit on the config.\n\nThe official Fedora packages are built with:\n\nBLK_SHA1 = 1\nNEEDS_CRYPTO_WITH_SSL = 1\nNO_PYTHON = 1\n\n\n> On my FC11 bochs and my other Linux boxes, the linker is loose but it does\n> not seem to hurt (and I do not think it should, as openssl-dev package\n> seems to have almost always shipped with both -lssl and -lcrypto) to add\n> this unconditionally.\n> \n> diff --git a/Makefile b/Makefile\n> index 1f1ce04..18c7e8e 100644\n> --- a/Makefile\n> +++ b/Makefile\n> @@ -776,6 +776,7 @@ ifeq ($(uname_S),Linux)\n>  \tNO_STRLCPY = YesPlease\n>  \tNO_MKSTEMPS = YesPlease\n>  \tHAVE_PATHS_H = YesPlease\n> +\tNEEDS_CRYPTO_WITH_SSL = YesPlease\n>  endif\n>  ifeq ($(uname_S),GNU/kFreeBSD)\n>  \tNO_STRLCPY = YesPlease\n"}]}