GNUPG 2.* and AIX - questions

[Michael Felt]

This is not a bug report. Short history - I have tried to package gnupg
several times, the gunpg v1.* has never been difficult - and maybe I shall
just leave it at that.

My key question is about the difference between v1.X and v2.X - are there
security elements in v2 that are missing/weaker in v1 - or are the
differences mainly that v2 supports/is always GUI while v1 is always CLI.

Background info...

The first wall I run into with gnupg-2.0.26 is that it wants gnu threads -
so, the question is: is there something inherently wrong with POSIX
threads, or even specifically with AIX pthreads that configure does not
attempt to use them (by default).

I took the hint and tried to package gnu/nth but make fails - immediately -
with this message.

root at x064:[/data/prj/gnu/pth/pth-2.0.7]make
./libtool --mode=compile --quiet cc -c -I.  pth_debug.c
"pth.h", line 93.2: 1506-205 (S) #error "FD_SETSIZE is larger than what GNU
Pth can handle."
make: *** [pth_debug.lo] Error 1
root at x064:[/data/prj/gnu/pth/pth-2.0.7]

For extra info:

root at x064:[/data/prj/gnu/pth/pth-2.0.7]grep FD_SETSIZE *.h
pth.h:    /* check if the user requests a bigger FD_SETSIZE than we can
handle */
pth.h:#if defined(FD_SETSIZE)
pth.h:#if FD_SETSIZE > 1024
pth.h:#error "FD_SETSIZE is larger than what GNU Pth can handle."
pth_p.h:#if !defined(FD_SETSIZE)
pth_p.h:#define FD_SETSIZE 1024

# AIX 5.3 so anno 2009
root at x064:[/data/prj/gnu/pth/pth-2.0.7]grep FD_SETSIZE /usr/include/*.h
/usr/include/sys/*.h
/usr/include/sys/time.h: * FD_SETSIZE may be defined by the user to the
maximum valued file
/usr/include/sys/time.h:#ifndef FD_SETSIZE
/usr/include/sys/time.h:#define FD_SETSIZE     65534
/usr/include/sys/time.h:/* Number of entries needed for FD_SETSIZE open
files */
/usr/include/sys/time.h:#define __NUM_ENTRIES  (FD_SETSIZE/__NFDBITS+1)

Again, this is NOT a bug-report. I have never seen gnupg 2.0 (so maybe it
is all GUI related, when all I am really interested in is security
abilities).

Thank your for your time.
Michael

p.s. please forgive the cross post to @devel - not sure which is the best
list for this question.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20150215/c7050528/attachment.html>