libgcrypt fails to compile with Xcode 9 against iOS 11 SDK

[Chris Ballinger]

@Ben I can't use MacPorts because I am cross-compiling for iOS with my
custom build scripts here:
https://github.com/ChatSecure/OTRKit/tree/master/scripts

Removing the system() calls (or tests entirely) is required for compilation
for iOS to succeed, but I can work around this with a simple patch.
However, the arm64 mach-o assembly issue is beyond my capabilities. From
what I understand using non-asm versions of AES-GCM is not recommended, and
we also (beyond libotr) use libgcrypt for AES-GCM functionality for OMEMO,
so I'd appreciate assistance in fixing this issue from someone more
knowledgable than me.

Thanks!

On Mon, Oct 9, 2017 at 1:12 AM, Werner Koch <wk at gnupg.org> wrote:

> On Sat,  7 Oct 2017 16:24, ben at adversary.org said:
>
> > (including gcrypt, gnutls, gmime and all of the gnupg libs), but with
> > clang still hanging around for almost everything else.
>
> All GnuPG components aim to be portable over all Unices and thus the
> compiler should never matter.  The system(3) call in the test suite is
> actually a shortcut to avoid adding a lot of other code and is not a
> security problem because we don't use setuid and we control all
> parameters.
>
> I am also sure that there is a way to keep on using system(3) because
> this API is part of ISO C.
>
>
> Salam-Shalom,
>
>    Werner
>
> --
> Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.
>
> _______________________________________________
> Gcrypt-devel mailing list
> Gcrypt-devel at gnupg.org
> http://lists.gnupg.org/mailman/listinfo/gcrypt-devel
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gcrypt-devel/attachments/20171026/8b5134fa/attachment-0001.html>