USE_GCC and CC=clang

b. f. bf1783 at
Mon Jan 9 18:23:00 UTC 2012

> I'm trying to fix a port which absolutely will not build with clang,
> since clang does not support the gcc extension used by this port. I set
> USE_GCC=4.2+, which is the lowest version of GCC which will work, but it
> doesn't properly override CC=clang.
> wxs at ack spamdyke % env CC=clang make test-gcc | grep -E "^(CC|USE_GCC)"
> USE_GCC=4.2+
> CC=clang - CXX=c++ - CPP=cpp - CFLAGS="-O2 -pipe -fno-strict-aliasing"
> wxs at ack spamdyke %

This problem only arises if the base compiler is gcc 4.2.x and
USE_GCC=4.2+. Otherwise CC will be set to the appropriate gcc
compiler.  Since Gerald (who maintains ports/Mk/ is trying
to retire lang/gcc42 anyway, it is not a good idea to set USE_GCC=4.2+
in a port.

> I understand this is probably an acceptable behavior, since if the user
> sets CC=clang they are explicitly asking to build with clang. However,
> in the case of a port known to not work with clang, and more importantly
> not able to be fixed, I was hoping there was a knob I could set that
> would forcible override any compiler related environment variables which
> may be set. I didn't find one, so I came up with this quick (and poorly
> tested) patch to do so.

The problem is due to a slight flaw in the implementation of the
USE_GCC=4.2+ case, which will be obviated soon by the removal of this
case. If in the meantime a change is made to, it should
address this flaw directly -- by setting CC=gcc explicitly where
needed, instead of relying upon the default setting of CC.  Another
knob is unnecessary.

Note that changes to, good or bad, won't address the cases
where a user sets CC on the command-line via "make .... CC= ...", or
adds it to MAKE_ARGS, or sets CC in the environment, and then calls
make with "-e" or "-E CC".  So the right thing to do is to add
something like:

.if !empty(CC:M*clang*)
IGNORE= : clang cannot be used to build this port

to the port Makefile, after the inclusion of or (since a user may have set CC in Makefile.local,, etc).  Or, better yet, to patch the port so that it can
be built with clang (which may have to be done anyway...).



More information about the freebsd-ports mailing list