NetBSD Problem Report #45267

From kre@munnari.OZ.AU  Thu Aug 18 10:42:26 2011
Return-Path: <kre@munnari.OZ.AU>
Received: from ( [])
	by (Postfix) with ESMTP id EF9E663B89A
	for <>; Thu, 18 Aug 2011 10:42:25 +0000 (UTC)
Message-Id: <>
Date: Thu, 18 Aug 2011 17:42:18 +0700 (ICT)
From: kre@munnari.OZ.AU
Subject: buildlink machinery produced bogus CFLAGS
X-Send-Pr-Version: 3.95

>Number:         45267
>Category:       pkg
>Synopsis:       buildlink machinery produced bogus CFLAGS
>Confidential:   no
>Severity:       serious
>Priority:       low
>Responsible:    pkg-manager
>State:          open
>Class:          change-request
>Submitter-Id:   net
>Arrival-Date:   Thu Aug 18 10:45:01 +0000 2011
>Originator:     Robert Elz
>Release:        NetBSD 5.1 (all versions, and pkgsrc -current 2011-08-18)
	Prince of Songkla University
System: NetBSD 5.1 NetBSD 5.1 (JADE-1.12-20101117) #5: Wed Nov 17 05:30:55 ICT 2010 i386
Architecture: i386
Machine: i386
	See PR pkg/40198 for the history leading up to this PR
	(in particular, the parts added to that PR in the few days
	leading up to this PR, rather than the stuff from years ago).

	It appears that the buildlink machinery (though I'm not sure
	yet how) manages to run /usr/bin/krb5-config --cflags, and
	include the result in CFLAGS of a package being compiled
	simply because a dependency of a dependency of a dependency
	of the program being compiled was built with the gssapi option
	set (and actually uses it).

	That's insane - if the package in question doesn't want or
	need include files from some foreign directory, it should
	not have those foisted upon them simply because some other
	program (or library) that it happens to (indirectly) use
	needed those include files.

	See PR pkg/40198 for all the details.

	But basically, on NetBSD 4 (and I am 99% certain NetBSD 5, and
	most probably NetBSD current as well) build www/curl with the
	gssapi option enabled (as it is by default).

	Then attempt to build www/amaya

	amaya depends upon redland which depends upon raptor which
	depends upon curl, so the curl package (and its buildlink
	machinery) all gets installed.

	Something (and here I haven't found the actual culprit) causes
	krb5-config to run with --cflags, and passes that CFLAGS to
	configure, where it ends up getting used in all of the compilations
	(as it should, once passed down of course.)

	In amaya, one of the files has
		#include "base64.h"
	expecting to get its own private base64.h file from its own
	include directory.

	Instead, the -I/usr/include/krb5 that gets stuck early in the
	(long) -I list in the build, causes it to include
	/usr/include/krb5/base64.h which is nothing like the file it
	was expecting, lots of data types don't get defined, and the
	compile (naturally) fails.

	All because of that stray -I that amaya desn't need at all.

	Make it go away!   At least, that kind of CFLAGS should only
	ever be used (ir it is ever needed at all) when compiling a
	package that is directly using the option in question.

	So, when compiling www/curl with the gssapi option set, then
	it is reasonable (whether required or not I have no idea) to
	include the -I for the kerberos include files.

	But when compiling packages that have no gssapi option, and
	know nothing about kerberos at all (I can find no references
	anywhere in the amaya sources to anything relevant related to
	krb or gss) that CFLAGS can only possibly cause problems (like
	the namespace pollution in this case).

NetBSD Home
NetBSD PR Database Search

(Contact us) $NetBSD: query-full-pr,v 1.39 2013/11/01 18:47:49 spz Exp $
$NetBSD:,v 1.8 2006/05/07 09:23:38 tsutsui Exp $
Copyright © 1994-2007 The NetBSD Foundation, Inc. ALL RIGHTS RESERVED.