gen-posix-lock-obj for iOS

[Werner Koch]

On Mon, 22 Sep 2014 22:00, chris at chatsecure.org said:

> The problem with that method, is I can't do that when integrating with
> Xcode. I have to choose a single set of headers to use for all of the
> architectures (i386, x86_64, armv7, armv7s, arm64 / aarch64). Apple does a
> lot of #ifdef magic for their own system headers to workaround this issue.

I do not understand why it is a problem to install external libraries
(e.g. libgpg-error, libgcrypt, gpgme) into system specific directories.
You can always use -I and -L to tell the compiler where to look for
header and libraries first.  In fact the gpg-error-config script as well
as other config scripts and pkg-config templates help to keep track of
those options.

If you really don't like it, you hack around it by writing your own
ligpg-error.h wrapper like

  #if defined(__x64_64__)
  # include "/usr/local/foo/x64_64/libgpg-error.h"
  #elif ...

and make sure that /usr/local/foo/x64_64/ is never passed as -I options.
But for libs you would need to adjust the linker scripts (in case the
OSX ld(1) uses such a thing).

> If possible I'd like to avoid anything actually using these
> architecture-specific options because I cannot guarantee that the correct

Actually this has been used for years.  For example gcrypt.h has a
system specific socklen_t and sys/select header.  gpgme.h uses system
specifics types for ssize_t and off_t.  The system specific parts in
gpg-error.h are just more noticeable.

Merging them all into one header is something Apple can do because they
control the environment and do not need to be portable to anything else.
However, we have already seen how fragile this is if you look at the
stdint.h problem.

With the dozens of different architectures and OSes we support, the
header files won't be maintainable.  We do the configure runtime testing
to figure out the parameters of unknown operating systems and thus are
able to build and run software on systems we have never seen before.
Doing all that configure magic in an installed header file is simply not
possible.

> headers will be used, no matter how much I massage the toolchain. Is this
> new API used heavily by libgcrypt or is it unused when compiling with
> pthreads support?

It is currently being used by GnuPG 2.1 but the next libgcrypt version
will also take advantage of it.  Some more shared code will be moved to
libgpg-error in the future.


Shalom-Salam,

   Werner


-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.