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.
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
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
--
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