gen-posix-lock-obj for iOS

[Chris Ballinger]

>
> I don't like that.  The whole cpp based detection is not as robust as
> the configure based one.  Right, it may happen that you use a wrong
> header file but then something is wrong with your toolchain setup
> anyway.  The autoconf macros we use actually detect a wrong use and
> print a warning if you use a header for a different cpu-vendor-os.  We
> can only do a warning because there are many aliases for the same
> system.


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.

If possible I'd like to avoid anything actually using these
architecture-specific options because I cannot guarantee that the correct
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?


On Fri, Sep 19, 2014 at 8:04 AM, Werner Koch <wk at gnupg.org> wrote:

> On Thu, 18 Sep 2014 20:01, chris at chatsecure.org said:
> > Great! Could you briefly explain why these are needed in the first place?
> > All I can gather is that it's needed for some very low level threading
>
> This is for the portable mutex API.  To avoid extra dependencies for
> single threaded applications it is useful to avoid build time
> dependencies to pthread.h and, if possible, runtime dependencies on
> libpthread.  This information hiding method will also enable us to
> change the concrete mutex implementation while keeping a stable API and
> ABI.
>
> > Another note, when compiling for all of these architectures I "lipo" the
> > libraries together, but choose only one of the header files, so usually I
>
> This is about these fat binaries, right?  I have no experience myself
> withit but I know that you need to use some build tricks.
>
> > am building other code against the i386 version of the header. Perhaps it
> > would be best to concatenate the architecture-specific code into the
> single
> > header file with #ifdefs based on architecture?
>
> I don't like that.  The whole cpp based detection is not as robust as
> the configure based one.  Right, it may happen that you use a wrong
> header file but then something is wrong with your toolchain setup
> anyway.  The autoconf macros we use actually detect a wrong use and
> print a warning if you use a header for a different cpu-vendor-os.  We
> can only do a warning because there are many aliases for the same
> system.
>
>
> Salam-Shalom,
>
>    Werner
>
> --
> Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20140922/831611cb/attachment.html>