GPGME 1.0.3 Build Problem

Marcus Brinkmann marcus.brinkmann at
Fri Dec 1 04:24:08 CET 2006

At Fri, 01 Dec 2006 11:32:35 +0900,
"djh" <henman at> wrote:
> libtool has been cygwin aware for several years and I've had no problems with it building many shared libraries.  (Except for example, GMP in which they assumed possibly too much in libtool and was forced to explicity use CPPFLAGS="-DDLL_EXPORT"

Shared library support various dramatically across platforms.  Libtool
tries its best to patch it up and give a consistent picture, but it
can not always provide.

GPGME does some funny things with libraries to support multiple thread
libraries.  Read on.

> I can envision where something like that can be cause of
> non-portability in the gpgme building code.

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).

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.


> #
> # GPGME Make problem (November 30, 2006):  (see below)
> #
> (cd .libs && rm -f && ln -s ../
> if /bin/sh ../libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. -I. -I..      -g -O2 -Wall -Wcast-align -Wshadow -Wstrict-prototypes -MT ath-pthread.lo -MD -MP -MF ".deps/ath-pthread.Tpo" -c -o ath-pthread.lo ath-pthread.c; \
>         then mv -f ".deps/ath-pthread.Tpo" ".deps/ath-pthread.Plo"; else rm -f ".deps/ath-pthread.Tpo"; exit 1; fi
>  gcc -DHAVE_CONFIG_H -I. -I. -I.. -g -O2 -Wall -Wcast-align -Wshadow -Wstrict-prototypes -MT ath-pthread.lo -MD -MP -MF .deps/ath-pthread.Tpo -c ath-pthread.c  -DPIC -o .libs/ath-pthread.o
> /bin/sh ../libtool --tag=CC --mode=link gcc  -g -O2 -Wall -Wcast-align -Wshadow -Wstrict-prototypes   -o -rpath /usr/local/lib  -version-info 15:0:4 ath-pthread.lo   stpcpy.lo memrchr.lo -lpthread -lgpg-error
> libtool: link: warning: undefined symbols not allowed in i686-pc-cygwin shared libraries
> .....
> make[2]: Entering directory `/usr/src/gpgme/gpgme-1.0.3/tests'
> Making all in gpg
> make[3]: Entering directory `/usr/src/gpgme/gpgme-1.0.3/tests/gpg'
> if gcc -DHAVE_CONFIG_H -I. -I. -I../.. -I../../gpgme    -g -O2 -Wall -Wcast-align -Wshadow -Wstrict-prototypes -MT t-encrypt.o -MD -MP -MF ".deps/t-encrypt.Tpo" -c -o t-encrypt.o t-encrypt.c; \
>         then mv -f ".deps/t-encrypt.Tpo" ".deps/t-encrypt.Po"; else rm -f ".deps/t-encrypt.Tpo"; exit 1; fi
> /bin/sh ../../libtool --tag=CC --mode=link gcc  -g -O2 -Wall -Wcast-align -Wshadow -Wstrict-prototypes   -o t-encrypt.exe  t-encrypt.o ../../gpgme/
> mkdir .libs
> gcc -g -O2 -Wall -Wcast-align -Wshadow -Wstrict-prototypes -o t-encrypt.exe t-encrypt.o  ../../gpgme/.libs/libgpgme.a /usr/lib/libgpg-error.dll.a -L/usr/lib /usr/lib/libintl.dll.a /usr/lib/libiconv.dll.a
> ../../gpgme/.libs/libgpgme.a(posix-sema.o): In posix-sema.c
> 			- undefined reference to `__gpgme_ath_mutex_destroy'
> 			- undefined reference to `__gpgme_ath_init'
> 			- undefined reference to `__gpgme_ath_mutex_lock'
> 			- undefined reference to `__gpgme_ath_mutex_unlock'
> 			- undefined reference to `__gpgme_ath_read'
> > We are using the mingw32 architecture, not cygwin, for our native Windows builds.
> I am using cygwin, a (unix) posix compliant system. GPGME should be able to be build without any problems.
> The problem should be looked into.  I will do what I can, but need you experts help.
> Please look into the build code regarding building for "cygwin" ...
> Cygwin Group:
>    Do any of you in the cygwin group know what the problem is?
> Regards,
>   Henman
> _______________________________________________
> Gnupg-devel mailing list
> Gnupg-devel at

More information about the Gnupg-devel mailing list