libgcrypt fails to compile with Xcode 9 against iOS 11 SDK
chrisballinger at gmail.com
Thu Oct 26 19:24:01 CEST 2017
@Ben I can't use MacPorts because I am cross-compiling for iOS with my
custom build scripts here:
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.
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
> I am also sure that there is a way to keep on using system(3) because
> this API is part of ISO C.
> Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.
> Gcrypt-devel mailing list
> Gcrypt-devel at gnupg.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Gcrypt-devel