pkg/45267: buildlink machinery produced bogus CFLAGS

[kre%munnari.OZ.AU@localhost]

>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)
>Organization:
        Prince of Songkla University
>Environment:
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 
kre%jade.coe.psu.ac.th@localhost:/usr/obj/5.1/kernels/i386/JADE i386
Architecture: i386
Machine: i386
>Description:
        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.

>How-To-Repeat:
        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.

>Fix:
        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).