Greg Troxel wrote:
> "John R. Shannon" <john@johnrshannon.com> writes:
> 
>> I've been working on this and am encountering problems I need guidance
>> on. GnuPG 1.9.93 depends on libassuan built with pth. GnuPG 1.9.93 and
>> pinentry also depend on pth. Currently, security/gnupg-devel and
>> security/pinentry build pth locally and link statically to the pth
>> library to avoid conflicts with native pthreads on NetBSD. I can
>> eliminate the static linking to pth and make libassuan, gnupg-devel
>> and pinentry dependant on pth, however, I noticed that having pth
>> causes problems with other packages (perl won't build) on NetBSD.
>>
>> Recommendations?
> 
> I think pkgsrc should work with pth installed.  But breaking perl is
> pretty serious.
> 
> I think it's broken that GnuPG stuff needs pth instead of working
> POSIX threads.  But that seems to be the case.

It's getting steadily less portable.

> So I suppose the short-term choices are to add static pth to
> libassuan, or to depend on pth and pick up the pieces.  Longer term,
> there's also getting GnuPG fixed to just require POSIX threads.

I have it building successfully with a local copy of libassuan-pth.a 
(small) in gnupg-devel and static linking. It's not passing all its 
self-tests yet.

> I'd lean towards trying to fix pkgsrc so it's ok to have pth
> installed.

The problem with building perl is that its finding the headers in 
/usr/include in addition to those that are buildlinked.



-- 
John R. Shannon, CISSP
Chief Scientist
DSCI, Information Assurance Division
jshannon@dsci-usa.com
john.r.shannon@us.army.mil
shannonjr@NetBSD.org
(208)522-4506