Created attachment 565682 [details, diff] Add support to autoconf-2.69 for clang and clang++ As per summary, I am running a (mostly stable) test environment with clang as only compiler (gcc was unmerged). I get failures with the same pattern from some ebuilds: "no acceptable C compiler found in $PATH". After some investigation, I discovered autoconf-2.69 added some macros to check for specific pieces of toolchain, main ones being: AC_PROG_CC, AC_PROG_CXX. These functions check whether the a compiler is present in $PATH, but do not include clang-based compilers in the checks. The attached patch fixes the issue in autoconf-2.69 ebuild, inserting clang(++) in the probed compilers. Most ebuilds come with bundled scripts and will require running eautoreconf in prepare phase to actually pick up the changes and avoid per-package patching. If I remember correctly there are other functions of the same family (_OBJC, _OBJCXX, _LD -> lld) that may also need patching. After applying patch autoconf-2.69 and adding eautoreconf in src_prepare to sys-devel/flex-2.6.4-r4 ebuild, I am able to successfully emerge it without reinstalling gcc. I am currently running an "emerge -e1 @world", and will report back with the other failing packages.
Comment on attachment 565682 [details, diff] Add support to autoconf-2.69 for clang and clang++ This shouldn't be needed if the meta-build system (i.e portage) sets CC properly so that configure doesn't need to hunt for a working compiler.
Created attachment 565690 [details] build.log
Created attachment 565692 [details] make.conf of the test environment
Created attachment 565694 [details] emerge --info of the failing environment
(In reply to Jeroen Roovers from comment #1) > Comment on attachment 565682 [details, diff] [details, diff] > Add support to autoconf-2.69 for clang and clang++ > > This shouldn't be needed if the meta-build system (i.e portage) sets CC > properly so that configure doesn't need to hunt for a working compiler. I know, and that's also part of the reason why I'm puzzled. I'm running into failures with other packages for completely unrelated reasons, but this looks plain wrong. I have attached net-dns/libidn2 ebuild (failing with same error, but configure script is much shorter compared to flex), and also make.conf and emerge --info. Other packages (currently +900 done) are picking up CC just fine.
It looks like libidn2's configure.ac tries to be cross-compile aware, and uses CC_FOR_BUILD to compile code that needs to run during the build process. Try setting CC_FOR_BUILD=clang in make.conf. For other packages, you might need to also set BUILD_CC and/or HOSTCC. For reference, see tc-getBUILD_PROG() in toolchain-funcs.eclass. Also, I think the libidn2 ebuild could call tc-getBUILD_CC, and that would automatically copy CC to CC_FOR_BUILD when not cross-compiling. As for the autoconf patch, that is something you should pursue upstream if you want AC_PROC_CC to auto-detect clang.
