Re: GPGME 1.0.3 Build Problem
Marcus, > That can't work. Makefile.am is the basis for the generated files > Makefile.in and Makefile, the latter of which is actually used. These > files are only automatically generated when in maintainer mode. Yes, your right. I just read about the GNU build system last night and realized that. Sorry about my ignorance of the gnu autotools workflow. I see where the distribution was not in an "autoconfiscated" state when I changed the .am file. > If you have the development tools installed, you can easily recreate > these files by running ./autogen.sh in the toplevel directory. > Otherwise, please let me know and I will send you a patch against > 1.0.3 or a complete tar ball. > > Thanks, > Marcus I could find no no ./autogen.sh in the toplevel directory. But, I did try the below: gpgme-1.0.3 $ aclocal # aclocal (GNU automake) 1.9.6 --- result: /usr/share/aclocal/libmcrypt.m4:17: warning: underquoted definition of AM_PATH_LIBMCRYPT run info '(automake)Extending aclocal' or see http://sources.redhat.com/automake/automake.html#Extending-aclocal gpgme-1.0.3 $ automake # automake (GNU automake) 1.9.6 --- result Makefile.am:42: BUILD_W32_GLIB does not appear in AM_CONDITIONAL Makefile.am:106: BUILD_W32_GLIB does not appear in AM_CONDITIONAL Makefile.am:115: HAVE_W32_SYSTEM does not appear in AM_CONDITIONAL Makefile.am:172: BUILD_W32_GLIB does not appear in AM_CONDITIONAL Makefile.am:178: required file `./stpcpy.c' not found Makefile.am:178: required file `./vasprintf.c' not found Makefile.am:178: required file `./isascii.c' not found Makefile.am:178: required file `./funopen.c' not found Makefile.am:178: required file `./putc_unlocked.c' not found Makefile.am:178: required file `./memrchr.c' not found Makefile.am:178: required file `./ttyname_r.c' not found Fails with $? = 1 --- Consequently, a new Makefile.in does not get created. Thanks, Darel Henman -- 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/
Re: GPGME 1.0.3 Build Problem
Marcus, thanks for your efforts. > Anyway, I have changed GPGME in SVN HEAD to not use a non-installed > library at all. This should fix the problem as well. It would be > good if someone tested out if that is indeed the case. > > Thanks, > Marcus here are the results I get from using everthing in: * gpgme-1.0.3.tar.gz with the exceptipn of Makefile.am, which I used the new 1192 revision Makefile.am which was mv'd to Makefile.am for the following: Regards, Darel Henman Results $ ./configure # configured as: (December 4, 2006) #GPGME v1.0.3 has been configured as follows: #GnuPG path:/usr/local/bin/gpg #GnuPG version: 1.4.5, min. 1.2.2 # #GpgSM path:no #GpgSM version: unknown, min. 1.9.6 # #GPGME Pthread: yes #GPGME Pth: $ make -k make all-recursive make[1]: Entering directory `/usr/src/gpgme/gpgme-1.0.3' Making all in gpgme make[2]: Entering directory `/usr/src/gpgme/gpgme-1.0.3/gpgme' make all-am make[3]: Entering directory `/usr/src/gpgme/gpgme-1.0.3/gpgme' make[3]: Nothing to be done for `all-am'. make[3]: Leaving directory `/usr/src/gpgme/gpgme-1.0.3/gpgme' make[2]: Leaving directory `/usr/src/gpgme/gpgme-1.0.3/gpgme' Making all in tests 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' /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 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 function `_gpgme_sema_cs_destroy': /usr/src/gpgme/gpgme-1.0.3/gpgme/posix-sema.c:62: undefined reference to `__gpgme_ath_mutex_destroy' ../../gpgme/.libs/libgpgme.a(posix-sema.o): In function `_gpgme_sema_subsystem_init': /usr/src/gpgme/gpgme-1.0.3/gpgme/posix-sema.c:44: undefined reference to `__gpgme_ath_init' ../../gpgme/.libs/libgpgme.a(posix-sema.o): In function `_gpgme_sema_cs_enter': /usr/src/gpgme/gpgme-1.0.3/gpgme/posix-sema.c:50: undefined reference to `__gpgme_ath_mutex_lock' ../../gpgme/.libs/libgpgme.a(posix-sema.o): In function `_gpgme_sema_cs_leave': /usr/src/gpgme/gpgme-1.0.3/gpgme/posix-sema.c:56: undefined reference to `__gpgme_ath_mutex_unlock' ../../gpgme/.libs/libgpgme.a(posix-io.o): In function `_gpgme_io_read': /usr/src/gpgme/gpgme-1.0.3/gpgme/posix-io.c:75: undefined reference to `__gpgme_ath_read' ../../gpgme/.libs/libgpgme.a(posix-io.o): In function `_gpgme_io_write': /usr/src/gpgme/gpgme-1.0.3/gpgme/posix-io.c:97: undefined reference to `__gpgme_ath_write' ../../gpgme/.libs/libgpgme.a(posix-io.o): In function `_gpgme_io_waitpid': /usr/src/gpgme/gpgme-1.0.3/gpgme/posix-io.c:283: undefined reference to `__gpgme_ath_waitpid' ../../gpgme/.libs/libgpgme.a(posix-io.o): In function `_gpgme_io_select': /usr/src/gpgme/gpgme-1.0.3/gpgme/posix-io.c:363: undefined reference to `__gpgme_ath_select' collect2: ld returned 1 exit status make[3]: *** [t-encrypt.exe] Error 1 /bin/sh ../../libtool --tag=CC --mode=link gcc -g -O2 -Wall -Wcast-align -Wshadow -Wstrict-prototypes -o t-encrypt-sym.exe t-encrypt-sym.o ../../gpgme/libgpgme.la gcc -g -O2 -Wall -Wcast-align -Wshadow -Wstrict-prototypes -o t-encrypt-sym.exe t-encrypt-sym.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 function `_gpgme_sema_cs_destroy': /usr/src/gpgme/gpgme-1.0.3/gpgme/posix-sema.c:62: undefined reference to `__gpgme_ath_mutex_destroy' ../../gpgme/.libs/libgpgme.a(posix-sema.o): In function `_gpgme_sema_subsystem_init': /usr/src/gpgme/gpgme-1.0.3/gpgme/posix-sema.c:44: undefined reference to `__gpgme_ath_init' ../../gpgme/.libs/libgpgme.a(posix-sema.o): In function `_gpgme_sema_cs_enter': /usr/src/gpgme/gpgme-1.0.3/gpgme/posix-sema.c:50: undefined reference to `__gpgme_ath_mutex_lock' ../../gpgme/.libs/libgpgme.a(posix-sema.o): In function `_gpgme_sema_cs_leave': /usr/src/gpgme/gpgme-1.0.3/gpgme/posix-sema.c:56: undefined reference to `__gpgme_ath_mutex_unlock' ../../gpgme/.libs/libgpgme.a(posix-io.o): In function `_gpgme_io_read': /usr/src/gpgme/gpgme-1.0.3/gpgme/posix-io.c:75: undefined reference to `__gpgme_ath_read' ../../gpgme/.libs/libgpgme.a(posix-io.o): In function `_gpgme_io_write': /usr/src/gpgme/gpgme-1.0.3/gpgme/posix-io.c:97: undefined reference to `__gpgme_ath_writ e' ../../gpgme/.libs/libgpgme.a(posix-io.o): In function `_gpgme_io_waitpid': /usr/src/gpgme/gpgme-1.0.3/gpgme/posix-io.c:283: undefined reference to `__gpgme_ath_waitpid' ../../gpgme/.libs/libgpgme.a(posix-io.o): In function `_gpgme_io_select': /usr/src/gpgme/gpg
Re: GPGME 1.0.3 Build Problem
Thanks again for your response. > From: Marcus Brinkmann <[EMAIL PROTECTED]> > ...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. > > > 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. I did receive the below "warning" message prior to the undefined symbol errors as follow: ( This does contain the "libgpgme-real.la" that you mentioned. Is this what you meant? Regards, Henman RE: libgpgme-real.la 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 > Then, GPGME builds the final library from the thread module, adding > the non-installed libgpgme-real.la to the bundle via LIBADD. > > > # > > # 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' > > > > - end - -- 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/
Re: GPGME 1.0.3 Build Problem
Thanks for your repsonse Marcus. > From: Marcus Brinkmann (GPGME member) > From: Henman: I have run into a build problem on cygwin system. > > > > > > I am not an expert in the utilities used to build gpgme. But, wonder why a > > library seems to be missing. Could this be a command line argument > > ordering problem?? > > It seems libtool doesn't support your target architecture well enough > for GPGME to build. 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" I can envision where something like that can be cause of non-portability in the gpgme building code. # # 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 -- 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/
cvs emacs
Has anyone out there been successfull in finding out how to build the latest cvs emacs with the cygwin 5.19.4? I was building emacs with cygwin's x-windows with the following configuration: ./configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --exec-prefix= --with-jpeg --with-png --with-gtk --with-gif --without-toolkit-scroll-bars --with-xpm --with-tiff --x-includes=/usr/X11R6/include/X11 --x-libraries=/usr/X11R6/ lib I have tried it but ran into problems, such as: Compiling /cygdrive/c/emacs/cvs/emacs/lisp/emacs-lisp/byte-opt.el Fatal error (6)/bin/sh: line 1: 1712 Aborted (core dumped) EMACSLOADPATH=/cygdrive/c/emacs/cvs/emacs/lisp ../src/bootstrap-emacs.exe -batch --no-site-file --multibyte -f batch-byte-compile-if-not-done $el make[2]: *** [compile] Error 1 make[2]: Leaving directory `/cygdrive/c/emacs/cvs/emacs/lisp' make[1]: *** [bootstrap-build] Error 2 make[1]: Leaving directory `/cygdrive/c/emacs/cvs/emacs' make: *** [bootstrap] Error 2 I was able to build April 28ths cvs emacs on cygwin 5.18..., but not yet with 5.19. Wonder if the problem could be something in cygwin?? Have any of you out there ran into and solved this? Regards, Darel Henman -- 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/
getline
I tried to back down to cygwin 5.18 from 5.19, but after I had done so and tried to remove a file with "rm", I get the following error message: Can't find getline in cygwin1.dll Can anyone help me find out why this is and get back to cygwin 5.18? -- 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/
instructions on how to build core file.
I am working to the the latest cvs emacs to build with the latest cygwin that was release 1.5.19(0.150/4/2) 2006-01-20 13:28. The buid proccess dies and leaves me with a stackdump , "temacs.exe.stackdump" . Does cygwin have a way to produce a core file that would be useful as a portmortem, using gdb? Thanks, Darel Henmann -- 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/
Re: GCC compiler
Thanks for the informative and helpful response. Darel --- Tim Prince wrote: djh wrote: My current version of gcc that setup.exe downloaded for me is: gcc (GCC) 3.4.4 (cygming special) (gdc 0.12, using dmd 0.125) The other day I downloaded gcc 4.0.2 filename: gcc-4.0.2.tar.bz2 did a configure, make, and makeinstall and the build was successfull. I compiled a program with it and it seems to work. My question is, am I fooling myself? Was there a lot of tweaking involved in getting the setup.exe downloaded version of gcc to work with cygwin? You could run make -k check and compare your results with those posted by others at gcc-testsuite. This would show how well the standard tested functions of gcc itself are working. If you don't care to use additional features of the cygming special, such as -mno-cygwin, you may be set up to do what matters to you. -- 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/
GCC compiler
My current version of gcc that setup.exe downloaded for me is: gcc (GCC) 3.4.4 (cygming special) (gdc 0.12, using dmd 0.125) The other day I downloaded gcc 4.0.2 filename: gcc-4.0.2.tar.bz2 did a configure, make, and makeinstall and the build was successfull. I compiled a program with it and it seems to work. My question is, am I fooling myself? Was there a lot of tweaking involved in getting the setup.exe downloaded version of gcc to work with cygwin? Regards, Darel -- 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/
new cygwin dlls
Has a fix been found for building emacs on the new cygwin versions 5.19 and up yet? There is at least one problem with d_ino as you know. An possibly another, since temacs crashes with a stack dump, during bootstrap. cygwin distribution has an early emacs in it. Will it still run on the newer 5.19 versions? Has any regression testing been carryied out? Has anyone been assigned to look into these problems? Darel Henman -- 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/
bug in: pthread_mutexattr_init ?
Any idea on what is the problem here? (gyginw CYGWIN Vers.: CYGWIN_NT-5.1 1.5.19(0.150/4/2) 2006-01-20 13:28 While buiding emacs (n.b. had to use a tacky dos trick for dirent since d_ino was deprecated, in order to break backward compatibilty) it crashes during executing temacs in a stack dump. The following information was gained from gdb ouptut In the appropriate directory: To debug: (after successfull config and filed main boostrap at temacs.exe) $ gdb temacs (gdb) r -batch -l loadup. (gdb) to continue Result: Program received signal SIGSEGV, Segmentation fault. 0x610ad945 in pthread_mutexattr_init () from /usr/bin/cygwin1.dll (gdb) Quit (gdb) backtrace #0 0x610ad945 in pthread_mutexattr_init () from /usr/bin/cygwin1.dll #1 0x6108dd7f in _sigfe () from /usr/bin/cygwin1.dll #2 0x0003 in ?? () #3 0x0022ee58 in ?? () #4 0x006a in ?? () #5 0x0022ee58 in ?? () #6 0x0022ee78 in ?? () #7 0x200a0210 in main (argc=539770848, argv=0x4) at emacs.c:1053 (gdb) Quit Any ideas of what is creating this? Regards, D.J. Henman -- 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/
