Summary: | =sys-devel/autoconf-2.69 should support clang, clang++ in AC_PROG_{CC,CXX,..} (clang-only environment) | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Fabio Scaccabarozzi <fsvm88> |
Component: | Current packages | Assignee: | Gentoo's Team for Core System packages <base-system> |
Status: | RESOLVED UPSTREAM | ||
Severity: | normal | CC: | jer |
Priority: | Normal | Keywords: | PATCH |
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: |
Add support to autoconf-2.69 for clang and clang++
build.log make.conf of the test environment emerge --info of the failing environment |
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. |
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.