NetBSD Problem Report #45267
From kre@munnari.OZ.AU Thu Aug 18 10:42:26 2011
Received: from mail.netbsd.org (mail.netbsd.org [18.104.22.168])
by www.NetBSD.org (Postfix) with ESMTP id EF9E663B89A
for <gnats-bugs@gnats.NetBSD.org>; Thu, 18 Aug 2011 10:42:25 +0000 (UTC)
Date: Thu, 18 Aug 2011 17:42:18 +0700 (ICT)
Subject: buildlink machinery produced bogus CFLAGS
>Synopsis: buildlink machinery produced bogus CFLAGS
>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 jade.coe.psu.ac.th 5.1 NetBSD 5.1 (JADE-1.12-20101117) #5: Wed Nov 17 05:30:55 ICT 2010 firstname.lastname@example.org:/usr/obj/5.1/kernels/i386/JADE 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
expecting to get its own private base64.h file from its own
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: query-full-pr,v 1.39 2013/11/01 18:47:49 spz Exp $
$NetBSD: gnats_config.sh,v 1.8 2006/05/07 09:23:38 tsutsui Exp $
Copyright © 1994-2007
The NetBSD Foundation, Inc. ALL RIGHTS RESERVED.