X-Spam-Check-By: sourceware.org Date: Fri, 01 Dec 2006 04:24:08 +0100 Message-ID: <87slg0wb6v.wl%marcus.brinkmann@ruhr-uni-bochum.de> From: Marcus Brinkmann To: "djh" Cc: , cygwin AT cygwin DOT com Subject: Re: GPGME 1.0.3 Build Problem In-Reply-To: <20061201113235.3912@henman-np.b-eng.it.to-be.co.jp> References: <20061130141425 DOT 2692 AT henman-np DOT b-eng DOT it DOT to-be DOT co DOT jp> <87wt5cx6t6.wl%marcus DOT brinkmann AT ruhr-uni-bochum DOT de> User-Agent: Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.7 (=?ISO-8859-4?Q?Sanj=F2?=) APEL/10.6 Emacs/21.4 (i486-pc-linux-gnu) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com At Fri, 01 Dec 2006 11:32:35 +0900, "djh" 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 > Gnupg-devel AT gnupg DOT org > 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/