GPGME 1.0.3 Build Problem

Yaakov S (Cygwin Ports) yselkowitz at
Fri Dec 1 05:17:23 CET 2006

Hash: SHA1

Marcus Brinkmann wrote:
> I gave it another look, and it seems to me that the problem could be
> the following: GPGME tries to build versions of GPGME linking against
> pthread and pth.  These versions are built from a version of the
> library without any thread support (, which is not
> installed.  This non-installed library has undefined symbols, btw, but
> it seems that libtool does not hickup over those (possibly because
> it's not installed), or you didn't give us the warning message for
> that case.
> Then, GPGME builds the final library from the thread module, adding
> the non-installed to the bundle via LIBADD.
> Ok, that's not really clean.  The problem is that now the order is
> messed up: The thread module's symbols get first on the linker command
> line, then comes the non-installed library using those symbols, then
> comes the rest.  However, this setup avoids building every file three
> times, cutting compile time to a third, and it seems to work OK on our
> main targets (and then some).

That's not a problem because libtool encloses the noinst libs with
- -Wl,--{,no-}whole-archive, allowing for just this situation.

> Well, considering that it is not totally clean, I don't have a
> fundamental object to remove the libgpgme-real hack and build each
> file three times, if you test and submit a patch to that effect.  I am
> also open to other suggestions.

That should not be necessary.  The following patch fixes the build of
gpgme-1.1.2 on cygwin:*checkout*/cygwin-ports/ports/libs/gpgme/gpgme-1.1.2-1.src.patch

A similar patch may be necessary for libgpgme_pth_la_LDFLAGS; pth isn't
part of the distro however, so I haven't tried it.

(If the above is true, you can just remove the $(no_undefined)
conditional and use '-no-undefined' throughout.)

Cygwin Ports
Version: GnuPG v1.4.5 (Cygwin)
Comment: Using GnuPG with Mozilla -


More information about the Gnupg-devel mailing list