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. CommonCrypto seemed like a viable option at the time, but the remaining deprecated functions don't have any replacements and I wouldn't hold my breath waiting for CC to provide them. It seems like a better approach might be something like [1]. I'd even suggest ripping out all of the commoncrypto stuff if it makes the final curl-ified code easier to read. libcurl 7.30.0 ships with OS X 10.9 (maybe even father back?) so making imap-send default to using openssl for <= 10.8 and curl for newer OS X seems like a good long-term solution. [1] http://thread.gmane.org/gmane.comp.version-control.git/255171 -- 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