From lofi at freebsd.org Sat Feb 10 01:11:02 2007 From: lofi at freebsd.org (Michael Nottebrock) Date: Sat, 10 Feb 2007 01:11:02 +0100 Subject: [patch] Don't add PTH include path to gpgme's CFLAGS globally Message-ID: <200702100111.05822.lofi@freebsd.org> In FreeBSD 6 and later, sys/types.h now also defines the basic pthread types in order to comply with IEEE Std 1003.1-2004. This causes a compile error in gpgme due to conflicting types for pthread_* if pth-support is enabled, since the pth include directory is globally added to CFLAGS and ath-pthread.c picks up the pth-supplied pthread.h header instead of the system include: cc -DHAVE_CONFIG_H -I. -I. -I.. -I../assuan -I/usr/local/include -I/usr/local/include/pth -I/usr/local/include/pth -I/usr/local/include/glib-2.0 -I/usr/local/lib/glib-2.0/include -O2 -pipe -O2 -fno-strict-aliasing -Wall -Wcast-align -Wshadow -Wstrict-prototypes -MT ath-pthread.lo -MD -MP -MF .deps/ath-pthread.Tpo -c ath-pthread.c ?-fPIC -DPIC -o .libs/ath-pthread.o In file included from ath-pthread.c:36: /usr/local/include/pth/pthread.h:285: error: conflicting types for 'pthread_t' /usr/include/sys/_pthreadtypes.h:64: error: previous declaration of 'pthread_t' was here /usr/local/include/pth/pthread.h:286: error: conflicting types for 'pthread_attr_t' /usr/include/sys/_pthreadtypes.h:65: error: previous declaration of 'pthread_attr_t' was here /usr/local/include/pth/pthread.h:288: error: conflicting types for 'pthread_once_t' /usr/include/sys/_pthreadtypes.h:71: error: previous declaration of 'pthread_once_t' was here /usr/local/include/pth/pthread.h:289: error: conflicting types for 'pthread_mutexattr_t' /usr/include/sys/_pthreadtypes.h:67: error: previous declaration of 'pthread_mutexattr_t' was here /usr/local/include/pth/pthread.h:290: error: conflicting types for 'pthread_mutex_t' /usr/include/sys/_pthreadtypes.h:66: error: previous declaration of 'pthread_mutex_t' was here /usr/local/include/pth/pthread.h:291: error: conflicting types for 'pthread_condattr_t' /usr/include/sys/_pthreadtypes.h:69: error: previous declaration of 'pthread_condattr_t' was here /usr/local/include/pth/pthread.h:292: error: conflicting types for 'pthread_cond_t' /usr/include/sys/_pthreadtypes.h:68: error: previous declaration of 'pthread_cond_t' was here /usr/local/include/pth/pthread.h:293: error: conflicting types for 'pthread_rwlockattr_t' /usr/include/sys/_pthreadtypes.h:73: error: previous declaration of 'pthread_rwlockattr_t' was here /usr/local/include/pth/pthread.h:294: error: conflicting types for 'pthread_rwlock_t' /usr/include/sys/_pthreadtypes.h:72: error: previous declaration of 'pthread_rwlock_t' was here The attached patch changes the Makefile template in the gpgme subdir so that PTH_CFLAGS are only added to the include path where needed. Cheers, -- ,_, | Michael Nottebrock | lofi at freebsd.org (/^ ^\) | FreeBSD - The Power to Serve | http://www.freebsd.org \u/ | K Desktop Environment on FreeBSD | http://freebsd.kde.org -------------- next part -------------- A non-text attachment was scrubbed... Name: gpgme.diff Type: text/x-diff Size: 737 bytes Desc: not available Url : /pipermail/attachments/20070210/06a7f60b/attachment.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available Url : /pipermail/attachments/20070210/06a7f60b/attachment.pgp From wk at gnupg.org Mon Feb 12 15:21:18 2007 From: wk at gnupg.org (Werner Koch) Date: Mon, 12 Feb 2007 15:21:18 +0100 Subject: [patch] Don't add PTH include path to gpgme's CFLAGS globally In-Reply-To: <200702100111.05822.lofi@freebsd.org> (Michael Nottebrock's message of "Sat\, 10 Feb 2007 01\:11\:02 +0100") References: <200702100111.05822.lofi@freebsd.org> Message-ID: <87sldb5ue9.fsf@wheatstone.g10code.de> On Sat, 10 Feb 2007 01:11, lofi at freebsd.org said: > pth-support is enabled, since the pth include directory is globally added to > CFLAGS and ath-pthread.c picks up the pth-supplied pthread.h header instead It is a relly strange decision by Debian (and obviously then also of FreeBSD) to install a pthread.h while at the same time having native pthread support. The pthread.h from Pth may simply not be installed if the system already provides pthread support. If an application really needs the pthread.h emulation it should take its own precautions not to introduce a conflict. Frankly, I doubt that there is a valid reason to use the phread emulation of Pth if pthread native support is available. Applications which are designed to work with Pth should include pth.h and never ever pthread.h. There is also the strange change in Pth to make soft mapping of system calls the default. This requires many applications to explicitly disable the soft mapping. In fact, I consider this an API change. The default Pth m4 tests are not able to grok such a change. That is why some libs have the "foo-config --api-version" feature to allow checking for an such API changes. Salam-Shalom, Werner From bernhard at intevation.de Mon Feb 12 18:04:06 2007 From: bernhard at intevation.de (Bernhard Reiter) Date: Mon, 12 Feb 2007 18:04:06 +0100 Subject: [patch] Don't add PTH include path to gpgme's CFLAGS globally In-Reply-To: <87sldb5ue9.fsf@wheatstone.g10code.de> References: <200702100111.05822.lofi@freebsd.org> <87sldb5ue9.fsf@wheatstone.g10code.de> Message-ID: <200702121804.11271.bernhard@intevation.de> Werner, On Monday 12 February 2007 15:21, Werner Koch wrote: > There is also the strange change in Pth to make soft mapping of system > calls the default. ?This requires many applications to explicitly > disable the soft mapping. ?In fact, I consider this an API change. > The default Pth m4 tests are not able to grok such a change. ?That is > why some libs have the "foo-config --api-version" feature to allow > checking for an such API changes. thanks for the explanations. Can you add something what this means for this patch? What is the conclusion? Bernhard -- Managing Director - Owner: www.intevation.net (Free Software Company); Germany Coordinator: fsfeurope.org. Coordinator: www.Kolab-Konsortium.com. Intevation GmbH, Amtsgericht Osnabr?ck, HRB 18998, USt-Id DE204854484 Gesch?ftsf?hrer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 1310 bytes Desc: not available Url : /pipermail/attachments/20070212/f59b590d/attachment.bin From marcus.brinkmann at ruhr-uni-bochum.de Mon Feb 12 23:09:38 2007 From: marcus.brinkmann at ruhr-uni-bochum.de (Marcus Brinkmann) Date: Mon, 12 Feb 2007 23:09:38 +0100 Subject: [patch] Don't add PTH include path to gpgme's CFLAGS globally In-Reply-To: <200702121804.11271.bernhard@intevation.de> References: <200702100111.05822.lofi@freebsd.org> <87sldb5ue9.fsf@wheatstone.g10code.de> <200702121804.11271.bernhard@intevation.de> Message-ID: <87ps8fjae5.wl%marcus.brinkmann@ruhr-uni-bochum.de> At Mon, 12 Feb 2007 18:04:06 +0100, Bernhard Reiter wrote: > > [1 ] > [1.1 ] > Werner, > > On Monday 12 February 2007 15:21, Werner Koch wrote: > > There is also the strange change in Pth to make soft mapping of system > > calls the default. ?This requires many applications to explicitly > > disable the soft mapping. ?In fact, I consider this an API change. > > The default Pth m4 tests are not able to grok such a change. ?That is > > why some libs have the "foo-config --api-version" feature to allow > > checking for an such API changes. > > thanks for the explanations. Can you add something > what this means for this patch? What is the conclusion? Won't fix, bug is in the distribution, at least for now, until either someone convinces us that making Pth's pthread.h available was a good decision to make, or the world charges ahead and drags us with it kicking and screaming. Thanks, Marcus From lofi at freebsd.org Tue Feb 13 07:25:37 2007 From: lofi at freebsd.org (Michael Nottebrock) Date: Tue, 13 Feb 2007 07:25:37 +0100 Subject: [patch] Don't add PTH include path to gpgme's CFLAGS globally In-Reply-To: <87sldb5ue9.fsf@wheatstone.g10code.de> References: <200702100111.05822.lofi@freebsd.org> <87sldb5ue9.fsf@wheatstone.g10code.de> Message-ID: <45D159E1.6080800@freebsd.org> Werner Koch schrieb: > On Sat, 10 Feb 2007 01:11, lofi at freebsd.org said: > > >> pth-support is enabled, since the pth include directory is globally added to >> CFLAGS and ath-pthread.c picks up the pth-supplied pthread.h header instead >> > > It is a relly strange decision by Debian (and obviously then also of > FreeBSD) to install a pthread.h while at the same time having native > pthread support. It's really the decision of the pth developers, their make install target installs that header and their configure check doesn't check for an existing pthreads implementation. > There is also the strange change in Pth to make soft mapping of system > calls the default. In FreeBSD, we will soon have a pth and a pth-hard port/package as a consequence. Cheers, -- ,_, | Michael Nottebrock | lofi at freebsd.org (/^ ^\) | FreeBSD - The Power to Serve | http://www.freebsd.org \u/ | K Desktop Environment on FreeBSD | http://freebsd.kde.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 250 bytes Desc: OpenPGP digital signature Url : /pipermail/attachments/20070213/5c3fcdf8/attachment-0001.pgp From lofi at freebsd.org Tue Feb 13 07:33:07 2007 From: lofi at freebsd.org (Michael Nottebrock) Date: Tue, 13 Feb 2007 07:33:07 +0100 Subject: [patch] Don't add PTH include path to gpgme's CFLAGS globally In-Reply-To: <87ps8fjae5.wl%marcus.brinkmann@ruhr-uni-bochum.de> References: <200702100111.05822.lofi@freebsd.org> <87sldb5ue9.fsf@wheatstone.g10code.de> <200702121804.11271.bernhard@intevation.de> <87ps8fjae5.wl%marcus.brinkmann@ruhr-uni-bochum.de> Message-ID: <45D15BA3.9020904@freebsd.org> Marcus Brinkmann schrieb: > At Mon, 12 Feb 2007 18:04:06 +0100, > Bernhard Reiter wrote: > >> [1 ] >> [1.1 ] >> Werner, >> >> On Monday 12 February 2007 15:21, Werner Koch wrote: >> >>> There is also the strange change in Pth to make soft mapping of system >>> calls the default. This requires many applications to explicitly >>> disable the soft mapping. In fact, I consider this an API change. >>> The default Pth m4 tests are not able to grok such a change. That is >>> why some libs have the "foo-config --api-version" feature to allow >>> checking for an such API changes. >>> >> thanks for the explanations. Can you add something >> what this means for this patch? What is the conclusion? >> > > Won't fix, bug is in the distribution, at least for now, until either > someone convinces us that making Pth's pthread.h available was a good > decision to make, or the world charges ahead and drags us with it > kicking and screaming. > See my other reply, Pth will install its compatibility header no matter what. Surely it's easier to add my trivial patch to gpgme than adding a not entirely trivial additional configure check to Pth? While at it, you could also update the ancient assuan subdir from early gnupg-devel days that is still included with gpgme and which requires several patches to build on FreeBSD. Cheers, -- ,_, | Michael Nottebrock | lofi at freebsd.org (/^ ^\) | FreeBSD - The Power to Serve | http://www.freebsd.org \u/ | K Desktop Environment on FreeBSD | http://freebsd.kde.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 250 bytes Desc: OpenPGP digital signature Url : /pipermail/attachments/20070213/e35973c3/attachment.pgp From marcus.brinkmann at ruhr-uni-bochum.de Wed Feb 14 15:06:58 2007 From: marcus.brinkmann at ruhr-uni-bochum.de (Marcus Brinkmann) Date: Wed, 14 Feb 2007 15:06:58 +0100 Subject: [patch] Don't add PTH include path to gpgme's CFLAGS globally In-Reply-To: <45D15BA3.9020904@freebsd.org> References: <200702100111.05822.lofi@freebsd.org> <87sldb5ue9.fsf@wheatstone.g10code.de> <200702121804.11271.bernhard@intevation.de> <87ps8fjae5.wl%marcus.brinkmann@ruhr-uni-bochum.de> <45D15BA3.9020904@freebsd.org> Message-ID: <87odnwvnnh.wl%marcus.brinkmann@ruhr-uni-bochum.de> At Tue, 13 Feb 2007 07:33:07 +0100, Michael Nottebrock wrote: > > Marcus Brinkmann schrieb: > > At Mon, 12 Feb 2007 18:04:06 +0100, > > Bernhard Reiter wrote: > > > >> [1 ] > >> [1.1 ] > >> Werner, > >> > >> On Monday 12 February 2007 15:21, Werner Koch wrote: > >> > >>> There is also the strange change in Pth to make soft mapping of system > >>> calls the default. This requires many applications to explicitly > >>> disable the soft mapping. In fact, I consider this an API change. > >>> The default Pth m4 tests are not able to grok such a change. That is > >>> why some libs have the "foo-config --api-version" feature to allow > >>> checking for an such API changes. > >>> > >> thanks for the explanations. Can you add something > >> what this means for this patch? What is the conclusion? > >> > > > > Won't fix, bug is in the distribution, at least for now, until either > > someone convinces us that making Pth's pthread.h available was a good > > decision to make, or the world charges ahead and drags us with it > > kicking and screaming. > > > See my other reply, Pth will install its compatibility header no matter > what. Surely it's easier to add my trivial patch to gpgme than adding a > not entirely trivial additional configure check to Pth? While at it, you > could also update the ancient assuan subdir from early gnupg-devel days > that is still included with gpgme and which requires several patches to > build on FreeBSD. Let's go through this one by one: 1) If Pth installs pthread.h even if --disable-pthread is given on the configure command line, I think that's a bug. 2) If you build Pth with --enable-pthread on a system with native pthread support, I think that's a bug. 3) In general: If there is a pthread.h in the include path that doesn't work as it should, I think that's a bug. With which of these three statements (if any) do you disagree? The assuan directory in GPGME is current as of december 2006 (released in GPGME 1.1.3). Since then, only two small changes have been done in libassuan, which should not affect current usage. Thanks, Marcus From lofi at freebsd.org Thu Feb 15 11:09:58 2007 From: lofi at freebsd.org (Michael Nottebrock) Date: Thu, 15 Feb 2007 11:09:58 +0100 Subject: [patch] Don't add PTH include path to gpgme's CFLAGS globally In-Reply-To: <87odnwvnnh.wl%marcus.brinkmann@ruhr-uni-bochum.de> References: <200702100111.05822.lofi@freebsd.org> <45D15BA3.9020904@freebsd.org> <87odnwvnnh.wl%marcus.brinkmann@ruhr-uni-bochum.de> Message-ID: <200702151110.02693.lofi@freebsd.org> On Wednesday, 14. February 2007 15:06, Marcus Brinkmann wrote: > Let's go through this one by one: > > 1) If Pth installs pthread.h even if --disable-pthread is given on the > configure command line, I think that's a bug. Agreed, that would be a bug (but doesn't happen). > > 2) If you build Pth with --enable-pthread on a system with native > pthread support, I think that's a bug. I don't. The FreeBSD port used to set --enable-pthread and --enable-syscall-soft or --enable-syscall-hard --disable-syscall-soft, with the former being the default (since a few days, these two configurations are separate ports). > With which of these three statements (if any) do you disagree? In my book you're declaring a feature a bug in order to avoid fixing one. Rather than uselessly waste time arguing, I'd like to know what problem there is with committing my trivial patch. gpgme is the only software in the whole ports collection that even needs to be patched to work around this issue. > The assuan directory in GPGME is current as of december 2006 (released > in GPGME 1.1.3). Since then, only two small changes have been done in > libassuan, which should not affect current usage. if /bin/sh /usr/local/bin/libtool --tag=CC --mode=compile cc -DHAVE_CONFIG_H -I. -I. -I.. -I.. -I../include -D_ASSUAN_IN_GPGME_BUILD_ASSUAN -O -pipe -Wall -Wcast-align -Wshadow -Wstrict-prototypes -MT funopen.lo -MD -MP -MF ".deps/funopen.Tpo" -c -o funopen.lo funopen.c; \ then mv -f ".deps/funopen.Tpo" ".deps/funopen.Plo"; else rm -f ".deps/funopen.Tpo"; exit 1; fi cc -DHAVE_CONFIG_H -I. -I. -I.. -I.. -I../include -D_ASSUAN_IN_GPGME_BUILD_ASSUAN -O -pipe -Wall -Wcast-align -Wshadow -Wstrict-prototypes -MT funopen.lo -MD -MP -MF .deps/funopen.Tpo -c funopen.c -fPIC -DPIC -o .libs/funopen.o funopen.c:63:2: #error No known way to implement funopen. This is because gpgme's assuan still attempts to use the reimplementation of funopen that requires fopencookie (in libassuan, funopen.c is still shipped, but not used). I cannot find libassuan in gnupg's svn to check when funopen.c was removed from Makefile.am, but at least the 1.0.1 release of libassuan doesn't have it and Makefile.am has a timestamp from november 2006. There's another issue with a gpgme addition to assuan.h: cc -DHAVE_CONFIG_H -I. -I. -I.. -I.. -I../include -D_ASSUAN_IN_GPGME_BUILD_ASSUAN -O -pipe -Wall -Wcast-align -Wshadow -Wstrict-prototypes -MT assuan-errors.lo -MD -MP -MF .deps/assuan-errors.Tpo -c assuan-errors.c -fPIC -DPIC -o .libs/assuan-errors.o In file included from assuan-errors.c:13: assuan.h:74: error: syntax error before "socklen_t" assuan.h:74: warning: function declaration isn't a prototype assuan.h:75: error: syntax error before "socklen_t" assuan.h:75: warning: function declaration isn't a prototype This error is due to a missing #include -- ,_, | Michael Nottebrock | lofi at freebsd.org (/^ ^\) | FreeBSD - The Power to Serve | http://www.freebsd.org \u/ | K Desktop Environment on FreeBSD | http://freebsd.kde.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available Url : /pipermail/attachments/20070215/061eb25d/attachment.pgp From Marcus.Brinkmann at ruhr-uni-bochum.de Thu Feb 15 23:53:58 2007 From: Marcus.Brinkmann at ruhr-uni-bochum.de (Marcus Brinkmann) Date: Thu, 15 Feb 2007 23:53:58 +0100 (CET) Subject: [patch] Don't add PTH include path to gpgme's CFLAGS globally In-Reply-To: <200702151110.02693.lofi@freebsd.org> Message-ID: Michael Nottebrock schrieb: > On Wednesday, 14. February 2007 15:06, Marcus Brinkmann wrote: > > Let's go through this one by one: > > 1) If Pth installs pthread.h even if --disable-pthread is given on > > the > > configure command line, I think that's a bug. > Agreed, that would be a bug (but doesn't happen). Ok, thanks for letting me know about that. > > 2) If you build Pth with --enable-pthread on a system with native > > pthread support, I think that's a bug. > I don't. > The FreeBSD port used to set --enable-pthread and > --enable-syscall-soft > or --enable-syscall-hard --disable-syscall-soft, with the former > being the > default (since a few days, these two configurations are separate > ports). I am really interested in learning why you build Pth with --enable-pthread. > > With which of these three statements (if any) do you disagree? > In my book you're declaring a feature a bug in order to avoid fixing > one. I understand that this is your opinion, but I have insufficient information to come to the same conclusion. In particular, I have yet not heard about any reason why one would want to build Pth with pthread support on a system that has native pthread.h support. You omitted item (3) from your reply. I am curious what your opinion is on that one. Basically, you install a header file pthread.h in the include path that simply doesn't work as a pthread implementation header file. Doesn't that seem wrong to you? > Rather than uselessly waste time arguing, I'd like to know what > problem there is with committing my trivial patch. gpgme is the only > software in the whole ports collection that even needs to be patched to work > around this issue. I do not believe it is useless to spend some time on learning the technical issues involved in making the technically correct decision. If we were only leaving this at a level of opinion, then yes, it would be wasted time. But if we can use the discussion to learn about what issues are involved and what the technically right thing to do is, or what trade-offs are involved, I think it is time well spent. In particular, I do not know why you would want --enable-pthread on your platform. This is likely ignorance on my part, please help me out. I think it is good engineering to not make changes to a source code base without having a valid rational for it, even if the change is apparently trivial. That is why I want to be convinced (by technical arguments) that the change you propose is the right thing to go about it, before applying the change. I will address the assuan issues separately. Thanks, Marcus