At Fri, 01 Dec 2006 11:32:35 +0900, "djh" <[EMAIL PROTECTED]> 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 (libgpgme-real.la), 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 libgpgme-real.la 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. Thanks, Marcus > # > # GPGME Make problem (November 30, 2006): (see below) > # > (cd .libs && rm -f libgpgme.la && ln -s ../libgpgme.la libgpgme.la) > 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 libgpgme-pthread.la -rpath /usr/local/lib > -version-info 15:0:4 ath-pthread.lo libgpgme-real.la 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/libgpgme.la > 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 > [EMAIL PROTECTED] > http://lists.gnupg.org/mailman/listinfo/gnupg-devel > -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
