Mailing List Archive: GnuPG: gpa

[patch] Don't add PTH include path to gpgme's CFLAGS globally

Index | Next | Previous | View Threaded

lofi at freebsd

Feb 9, 2007, 4:11 PM

Post #1 of 9 (6208 views)
Permalink

[patch] Don't add PTH include path to gpgme's CFLAGS globally

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
(/^ ^\) | FreeBSD - The Power to Serve | http://www.freebsd.org
\u/ | K Desktop Environment on FreeBSD | http://freebsd.kde.org

Attachments:

gpgme.diff (0.72 KB)

wk at gnupg

Feb 12, 2007, 6:21 AM

Post #2 of 9 (5927 views)
Permalink

Re: [patch] Don't add PTH include path to gpgme's CFLAGS globally [In reply to]

On Sat, 10 Feb 2007 01:11, lofi [at] freebsd 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

_______________________________________________
Gpa-dev mailing list
Gpa-dev [at] gnupg
http://lists.gnupg.org/mailman/listinfo/gpa-dev

bernhard at intevation

Feb 12, 2007, 9:04 AM

Post #3 of 9 (5898 views)
Permalink

Re: [patch] Don't add PTH include path to gpgme's CFLAGS globally [In reply to]

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

Attachments:

smime.p7s (1.28 KB)

marcus.brinkmann at ruhr-uni-bochum

Feb 12, 2007, 2:09 PM

Post #4 of 9 (5910 views)
Permalink

Re: [patch] Don't add PTH include path to gpgme's CFLAGS globally [In reply to]

At Mon, 12 Feb 2007 18:04:06 +0100,
Bernhard Reiter wrote:
>
> [1 <multipart/signed (7bit)>]
> [1.1 <text/plain; iso-8859-1 (quoted-printable)>]
> 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

_______________________________________________
Gpa-dev mailing list
Gpa-dev [at] gnupg
http://lists.gnupg.org/mailman/listinfo/gpa-dev

lofi at freebsd

Feb 12, 2007, 10:25 PM

Post #5 of 9 (5894 views)
Permalink

Re: [patch] Don't add PTH include path to gpgme's CFLAGS globally [In reply to]

Werner Koch schrieb:
> On Sat, 10 Feb 2007 01:11, lofi [at] freebsd 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
(/^ ^\) | FreeBSD - The Power to Serve | http://www.freebsd.org
\u/ | K Desktop Environment on FreeBSD | http://freebsd.kde.org

Attachments:

signature.asc (0.24 KB)

lofi at freebsd

Feb 12, 2007, 10:33 PM

Post #6 of 9 (5908 views)
Permalink

Re: [patch] Don't add PTH include path to gpgme's CFLAGS globally [In reply to]

Marcus Brinkmann schrieb:
> At Mon, 12 Feb 2007 18:04:06 +0100,
> Bernhard Reiter wrote:
>
>> [1 <multipart/signed (7bit)>]
>> [1.1 <text/plain; iso-8859-1 (quoted-printable)>]
>> 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
(/^ ^\) | FreeBSD - The Power to Serve | http://www.freebsd.org
\u/ | K Desktop Environment on FreeBSD | http://freebsd.kde.org

Attachments:

signature.asc (0.24 KB)

marcus.brinkmann at ruhr-uni-bochum

Feb 14, 2007, 6:06 AM

Post #7 of 9 (5901 views)
Permalink

Re: [patch] Don't add PTH include path to gpgme's CFLAGS globally [In reply to]

At Tue, 13 Feb 2007 07:33:07 +0100,
Michael Nottebrock <lofi [at] freebsd> wrote:
>
> Marcus Brinkmann schrieb:
> > At Mon, 12 Feb 2007 18:04:06 +0100,
> > Bernhard Reiter wrote:
> >
> >> [1 <multipart/signed (7bit)>]
> >> [1.1 <text/plain; iso-8859-1 (quoted-printable)>]
> >> 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

_______________________________________________
Gpa-dev mailing list
Gpa-dev [at] gnupg
http://lists.gnupg.org/mailman/listinfo/gpa-dev

lofi at freebsd

Feb 15, 2007, 2:09 AM

Post #8 of 9 (5923 views)
Permalink

Re: [patch] Don't add PTH include path to gpgme's CFLAGS globally [In reply to]

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 <sys/socket.h>

--
,_, | Michael Nottebrock | lofi [at] freebsd
(/^ ^\) | FreeBSD - The Power to Serve | http://www.freebsd.org
\u/ | K Desktop Environment on FreeBSD | http://freebsd.kde.org

Marcus.Brinkmann at ruhr-uni-bochum

Feb 15, 2007, 2:53 PM

Post #9 of 9 (5898 views)
Permalink

Re: [patch] Don't add PTH include path to gpgme's CFLAGS globally [In reply to]

Michael Nottebrock <lofi [at] freebsd> 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

_______________________________________________
Gpa-dev mailing list
Gpa-dev [at] gnupg
http://lists.gnupg.org/mailman/listinfo/gpa-dev

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads