On Wed, Dec 03, 2014 at 01:54:51PM +0100, Torsten Bögershausen wrote: > On 12/03/2014 11:04 AM, David Aguilar wrote: > >On Tue, Dec 02, 2014 at 10:09:35PM -0500, Eric Sunshine wrote: > >>On Tue, Dec 2, 2014 at 8:12 PM, Michael Blume <blume.mike@xxxxxxxxx> wrote: > >>>On Tue, Dec 2, 2014 at 4:37 PM, Eric Sunshine <sunshine@xxxxxxxxxxxxxx> wrote: > >>>>On Mon, Dec 1, 2014 at 1:04 PM, Junio C Hamano <gitster@xxxxxxxxx> wrote: > >>>>>I am not a Mac person, but is this about APPLE_COMMON_CRYPTO support > >>>>>added in 4dcd7732 (Makefile: add support for Apple CommonCrypto > >>>>>facility, 2013-05-19) and be4c828b (imap-send: eliminate HMAC > >>>>>deprecation warnings on Mac OS X, 2013-05-19)? [...] > >>>>>In the Makefile we seem to have this: > >>>>> > >>>>> # Define NO_APPLE_COMMON_CRYPTO if you are building on Darwin/Mac OS X > >>>>> # and do not want to use Apple's CommonCrypto library. This allows you > >>>>> # to provide your own OpenSSL library, for example from MacPorts. > >>>>> > >>>>>which makes it sound like using APPLE_COMMON_CRYPTO is the default > >>>>>for Mac. Perhaps those who do want to use CommonCrypto to avoid > >>>>>warnings should not define that macro? > >>>>It's been a long time [1] since I looked at it, but I believe that > >>>>David's CommonCrypto patch series only replaced OpenSSL calls for > >>>>which Apple had provided CommonCrypto replacements. If my memory is > >>>>correct, there were still plenty of OpenSSL deprecations warnings > >>>>remaining after his patches (the warnings which started this thread) > >>>>even without defining NO_APPLE_COMMON_CRYPTO. Thus, David's patches > >>>>reduced the number of warnings but did not fully eliminate them. > >>>> > >>>>Checking again, it still seems to be the case that Apple neglects to > >>>>provide CommonCrypto replacements for these OpenSSL functions which > >>>>Apple itself deprecated. > >>>> > >>>>[1]: http://thread.gmane.org/gmane.comp.version-control.git/224833 > >>>If there's actually no way to address this, is there a simple way to > >>>silence deprecation warnings only in this file? I only ask because > >>>overall the git build seems to be extremely quiet, and it seems > >>>valuable to preserve that, so that warnings we want to act on stick > >>>out. > >>An individual developer can add '-Wno-deprecated-declarations' to > >>CFLAGS to suppress these warnings, however, that's pretty much a > >>sledge hammer which would impact deprecations from all included > >>headers, not just Apple's. For this reason, we probably wouldn't want > >>to make this the default. > >> > >>The potentially lesser evil would be this small patch (minus Gmail > >>whitespace damage) which disables the deprecation warnings only for > >>Apple's headers: > >> > >>----- >8 ----- > >>diff --git a/git-compat-util.h b/git-compat-util.h > >>index 400e921..709e84f 100644 > >>--- a/git-compat-util.h > >>+++ b/git-compat-util.h > >>@@ -211,6 +211,8 @@ extern char *gitbasename(char *); > >> #endif > >> > >> #ifndef NO_OPENSSL > >>+#define __AVAILABILITY_MACROS_USES_AVAILABILITY 0 > >>+#define MAC_OS_X_VERSION_MIN_REQUIRED MAC_OS_X_VERSION_10_6 > >> #include <openssl/ssl.h> > >> #include <openssl/err.h> > >> #endif > >>----- >8 ----- > >> > >>It's still mildly heavy-handed, in that it could silence legitimate > >>Apple deprecations, but it does give us a clean build with little > >>fuss. An alternative would be to relegate these #defines to the Darwin > >>section of the Makefile if placing them in git-compat-util.h seems too > >>invasive. > >> > >>Considering that Mac OS X is now at 10.10 and these deprecations > >>commenced with Mac OS X 10.7 in July 2011 (3.5 years ago), and Apple > >>still has not provided drop-in CommonCrypto equivalents, it seems > >>unlikely that they will do so any time soon. Consequently, suppressing > >>these otherwise unavoidable warnings may be the best we can do. > >> > >>I'm willing to formalize and submit this as a proper patch if it's not > >>considered too disgusting by the powers-that-be. > > > >Tweaking those internal #defines can only come back to bite us > >in the future when the functions are finally ripped out. > > > >[1] http://thread.gmane.org/gmane.comp.version-control.git/255171 > Yes, but this patch needs 7.34 :-( > 7.30 (as shipped with Mac OS X 10.9) is missing the CURLOPT_LOGIN_OPTIONS > > Try > rm imap-send.o > NO_GETTEXT=yes NO_DARWIN_PORTS=Yes USE_CURL_FOR_IMAP_SEND=yes make > imap-send.o It looks like 10.10 Yosemite has curl 7.37.1 [1], so maybe it's better there (I can't verify myself). Silencing the warnings is a sensible thing to do for older versions since it looks like there's a smooth upgrade path via the curl patches. My original caution was that not having the warnings would make us forget that the issue existed, but (warning) silence is golden. [1] http://curl.haxx.se/mail/archive-2014-10/0053.html -- David -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html