NetBSD Problem Report #59725

From www@netbsd.org  Sun Oct 26 01:54:31 2025
Return-Path: <www@netbsd.org>
Received: from mail.netbsd.org (mail.netbsd.org [199.233.217.200])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256
	 client-signature RSA-PSS (2048 bits) client-digest SHA256)
	(Client CN "mail.NetBSD.org", Issuer "mail.NetBSD.org CA" (not verified))
	by mollari.NetBSD.org (Postfix) with ESMTPS id 044811A9239
	for <gnats-bugs@gnats.NetBSD.org>; Sun, 26 Oct 2025 01:54:31 +0000 (UTC)
Message-Id: <20251026015429.7D74C1A923A@mollari.NetBSD.org>
Date: Sun, 26 Oct 2025 01:54:29 +0000 (UTC)
From: campbell+netbsd@mumble.net
Reply-To: campbell+netbsd@mumble.net
To: gnats-bugs@NetBSD.org
Subject: buildlink3.mk BDB_ACCEPTED settings don't work
X-Send-Pr-Version: www-1.0

>Number:         59725
>Category:       pkg
>Synopsis:       buildlink3.mk BDB_ACCEPTED settings don't work
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    pkg-manager
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Sun Oct 26 01:55:00 +0000 2025
>Originator:     Taylor R Campbell
>Release:        current
>Organization:
The NetBDB Foundaversion
>Environment:
>Description:

	www/apr-util uses the Berkeley DB interface, but specifically
	requires db4 or db5.  This carries through to downstream
	users, so its buildlink3.mk has the following fragment:

pkgbase := apr-util
.include "../../mk/pkg-build-options.mk"

.if ${PKG_BUILD_OPTIONS.apr-util:Mdb4}
BDB_ACCEPTED?=		db4 db5
.  include "../../mk/bdb.buildlink3.mk"
.endif

	Unfortunately, this doesn't work, and I think there are two
	reasons it doesn't work:

	1. If any _previous_ buildlink3.mk had already included
	   bdb.buildlink3.mk, it would be too late to set BDB_ACCEPTED
	   to a smaller set of options.

	   For example, www/serf/Makefile includes krb5.buildlink3.mk
	   (via options.mk) first, which (if KRB5_TYPE=heimdal) brings
	   in security/heimdal/buildlink3.mk, which brings in
	   bdb.buildlink3.mk, which sets BDB_ACCEPTED to

		db1 db2 db3 db4 db5 db6 db18

	   and also chooses BDB_TYPE and includes the relevant
	   builtin.mk or buildlink3.mk for the chosen BDB_TYPE.

	   Next, www/serf/Makefile includes apr-util/buildlink3.mk,
	   which tries

BDB_ACCEPTED?=	db4 db5

	   but it's too late because BDB_ACCEPTED is already defined
	   (and BDB_TYPE already determined).

	   If we want buildlink3.mk to be able to narrow the set of
	   available bdb versions, we have to compute the intersection
	   of BDB_ACCEPTEDs first, and defer BDB_TYPE determination
	   until much later.  But:

	2. It is too late at buildlink3-time to decide db4 vs db5,
	   because apr-util was _already built_ against one or the
	   other, and its buildlink3.mk really needs to reflect that
	   one -- the one that was already chosen when apr-util was
	   built.

	   Maybe we can do this by adding a db4 vs db5 option group to
	   devel/apr-util/options.mk and fishing that out of
	   PKG_BUILD_OPTIONS.  Or maybe we can do this by making a
	   variant of pkg-build-options.mk that reads different
	   `pkg_info -Q BDB_TYPE ...' out of the package.

>How-To-Repeat:

	Set KRB5_DEFAULT=heimdal and build www/serf on a platform (like
	NetBSD) that has built-in db1.  This ends in sadness:

Creating 'serf-1.pc'
cc -o libserf-1.so.1.3.0 ... -ldb4-4.8 ...
/usr/bin/ld: cannot find -ldb4-4.8
collect2: error: ld returned 1 exit status
scons: *** [libserf-1.so.1.3.0] Error 1
scons: building terminated because of errors.
*** Error code 2

	Note that BDB_ACCEPTED is more liberal than www/apr-util
	allows, and BDB_TYPE is chosen to be db1:

$ bmake -C www/serf -v BDB_ACCEPTED -v BDB_TYPE
db1 db2 db3 db4 db5 db6 db18
db1

>Fix:

	Yes, please!

Home	PR Database Search