>Number:         17476
>Category:       pkg
>Synopsis:       USE_PTHREAD/pthread.buildlink.mk need to be re-thought.
>Confidential:   no
>Severity:       non-critical
>Priority:       medium
>Responsible:    pkg-manager
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Thu Jul 04 00:24:00 PDT 2002
>Closed-Date:
>Last-Modified:
>Originator:     Nick Hudson
>Release:        NetBSD 1.6B
>Organization:
	Not much.
>Environment:
System: NetBSD btcl045611 1.6B NetBSD 1.6B (TECRA8100) #1: Tue Jul 2 22:21:39 BST 2002 nick@btcl045611:/dsk/home/nick/work/netbsd-current/src/sys/arch/i386/compile/TECRA8100 i386
Architecture: i386
Machine: i386
>Description:
	The main problem is that USE_PTHREAD/pthread.buildlink.mk can't be used within
	buildlink.mk files.

 	I played around with a patch (see below) from Chris Gilbert that
	introduces a BUILDLINK_USE_PTHREAD variable that can be checked
	against USE_PTHREAD, but this doesn't work if two pthreads enabled
	libraries are linked into a pkg.

Index: pthread.buildlink.mk
===================================================================
RCS file: /cvsroot/pkgsrc/mk/pthread.buildlink.mk,v
retrieving revision 1.5
diff -u -p -r1.5 pthread.buildlink.mk
--- pthread.buildlink.mk	2002/05/29 08:19:55	1.5
+++ pthread.buildlink.mk	2002/06/15 23:27:42
@@ -33,6 +33,12 @@
 # _PKG_PTHREADS is the list of package pthread implementations recognized by
 #	pthread.buildlink.mk
 #
+# BUILDLINK_USE_PTHREAD is a list of pthread implementations that may have
+#	been used to create the package, this is used in buildlink.mk.  Note
+#	that it is assumed that BUILDLINK_USE_PTHREAD will give the same
+#	result as USE_PTHREAD did for the initial package.  The value 
+#	derived from BUILDLINK_USE_PTHREAD is compared against PTHREAD_TYPE.
+#
 .if defined(USE_PTHREAD)
 _PKG_PTHREADS?=		pth pth-syscall ptl2 mit-pthreads unproven-pthreads
 
@@ -102,3 +108,35 @@ DEPENDS+=		mit-pthreads-1.60b6:../../dev
 
 .endif	# PTHREAD_BUILDLINK_MK
 .endif	# BSD_PREFS_MK
+
+#
+# This is a bit of sanity checking that BUILDLINK Files that pass in threads
+# all match up.
+
+.if defined(BUILDLINK_USE_PTHREAD)
+
+.for __valid_buildlink_pthread__ in ${BUILDLINK_USE_PTHREAD}
+.  if !empty(_PKG_PTHREADS:M${__valid_buildlink_pthread__})
+_BUILDLINK_PTHREAD_TYPE?=	${__valid_buildlink_pthread__}
+.  endif
+.endfor
+_BUILDLINK_PTHREAD_TYPE?=	none
+
+# We check for a native pthread implementation by checking for the presence
+# of /usr/include/pthread.h (we might want to make this check stricter).
+#
+.if !empty(BUILDLINK_USE_PTHREAD:Mnative)
+.  if exists(/usr/include/pthread.h)
+BUILDLINK_PTHREAD_TYPE?= native
+.  else
+BUILDLINK_PTHREAD_TYPE?= ${_BUILDLINK_PTHREAD_TYPE}
+.  endif
+.endif
+
+.if ${PTHREAD_TYPE} != ${BUILDLINK_PTHREAD_TYPE}
+# buildlink and main package thread packages don't match
+.BEGIN:
+	@${ECHO} "Mismatch in required pthreads, main package uses ${PTHREAD_TYPE}, buildlink package uses ${BUILDLINK_PTHREAD_TYPE}";
+	@${FALSE};
+.endif
+.endif # BUILDLINK_USE_PTHREAD

>How-To-Repeat:
	See pkg/17177, pkg/17272, pkg/17273, and pkg/17437
>Fix:
	Dunno. I think, though, that we should pick a userland pthreads
	package (pth - with hard syscalls?) as the non-nathanw_sa
	replacement. The pthread.buildlink.mk logic can then be similar
	to how the MesaLib handling is done.
>Release-Note:
>Audit-Trail:
>Unformatted: