Some ports have adopted the following pattern to work around dependency issues: BUILD_DEPENDS+= clang40:devel/llvm40 CC= clang40 CXX= clang++40 However, on archs where clang is not the default compiler, this creates complaints for any bulk build: /bin/sh: clang40: not found make[2]: "/usr/ports/Mk/Uses/compiler.mk" line 78: warning: "clang40 --version" returned non-zero status make[2]: "/usr/ports/Mk/Uses/compiler.mk" line 133: warning: "clang++40 -### /dev/null 2>&1" returned non-zero status See sysutils/osquery for an example of "clang40". This pattern is also seen for instances of "clang50" and "clang60", but the symptoms are the same. The logic in compiler.mk is hard for me to follow, but here are the offending lines: _CCVERSION!= ${CC} --version _CXXINTERNAL!= ${CXX} -\#\#\# /dev/null 2>&1 These lines were introduced in the initial commit of compiler.mk. I don't know what the proper fix is, but my guess is that the two lines above were written assuming that CC/CXX were whatever is in the base system. So, either those two lines should be fixed, or compiler.mk refactored to take some kind of parameter to say "assign BUILD_DEPENDS/CPP/CC/CXX/ in the following fashion" and use that to trigger a code block exactly like e.g. lines 186, 208, 230, 252, and 274.
Cc: bapt as the original author of the code in question.
Created attachment 194991 [details] patch to remove annoying messages Patch is now undergoing test.
Created attachment 194992 [details] patch to remove annoying messages Patch fixed and being tested now.
Actually I am beginning to suspect the failure more is more specific. Changing sysutils/osquery and running the patch didn't change anything. I currently think that the failure is seen only if CC is defined before bsd.port.options.mk and/or bsd.port.pre.mk are defined. Example: lang/ldc. I'm going to test that.
(In reply to Mark Linimon from comment #4) I've had similar problems with compilers.mk as I use gcc8 for some ports (in addition to those earmarked with USE_GCC), clang 6.0.1 and binutils 2.30 with/without ccache. I got to the point of modifying my make.conf to respond to various parameters. So I'm interested in your outcome(s). I'm intending to use lto to benefit from control flow integrity, which is the reason for the workarounds :) In your patch, Mark, you might consider using absolute paths for the base clang, to avoid any ambiguity (unless you manipulate PATH) in +CPP= clang-cpp +CC= clang +CXX= clang++ Also can I suggest that you change your make.conf to something like REALLY_WANT_CLANG_LIST= sysutils/osquery .for P in ${REALLY_WANT_CLANG_LIST} .if (!empty(.CURDIR:M/usr/ports/$P) || !empty(.CURDIR:M/var/ports/usr/ports/$P/*) REALLY_REALLY_WANT_CLANG= 40 .endif .endfor rather than change the $category/$port/Makefile(s) - its a little less hassle when you svn update, and there will be conflicts ;)
Moin moin Closing this, due to old age. Please re-open the issue, if it is still relevant. mfg Tobias