The configure script of dhcpcd 6.4.5 attempts to find a suitable compiler using its own algorithm. On ARM systems (and perhaps others) the script seems to have the internal variable HOSTCC set, probably because --host is supplied. As a result it looks for a list of compilers with a host prefix. The list is uses is "cc clang ...", but normal systems do not have a host-cc binary installed (/usr/bin/cc is a program which selects the configured C compiler for the machine, so this would not work.) As a result on ARM systems with clang installed 'host-clang' is selected as the C compiler, unless CC is defined in /etc/portage/make.conf or a dhcpcd specific environment. On hardfloat systems arm*-hardfloat-linux-gnueabi-clang requires -mfloat-abi=hard to successfully build an executable, see this bug: https://bugs.gentoo.org/show_bug.cgi?id=510906 As a result the build of dhcpcd on such systems (ARM+hardfloat+clang) is currently failing. The work-round is to set CC=/usr/bin/cc in the ebuild if it is not already set, but it is an upstream bug; dhcpcd should *NOT* be building with clang, unless it is deliberately configured as the default C compiler.
The workround is to set: CC=cc The path is not necessary (though I haven't tested either approach - I simply set CC=gcc in make.conf)
1) Please post your `emerge --info' output in a comment. 2) Please attach the entire build log to this bug report.
Created attachment 385232 [details] emerge -pqv '=net-misc/dhcpcd-6.4.5::gentoo'
Created attachment 385234 [details] emerge --info '=net-misc/dhcpcd-6.4.5::gentoo'
Created attachment 385236 [details] build.log (ebuild configure) NOTE: I had to revert my fix to do this, but the result is the same (i.e. I got the temporary revert to /etc/portage/make.conf correct).
Created attachment 385238 [details] build.log Got it wrong the first time, here is the corrected log (the CFLAGS was incorrect before).
Created attachment 385240 [details] ebuild environment (reverted to original) This is the reverted environment (reverted /etc/portage/make.conf)
Ok, attached, but note that I had to revert my fix to generate this and the ebuild.log is signally useless (because, once again, of the dumb configure - look at the redirections on line 1158!)
Looks like it may be a duplicate of bug 517188 (which was originally submitted with "net-misc/dhcpcd-6.4.2 tries to build with clang and fails" summary). There is nothing specifically related to ARM here. Just Clang happens to have higher priority than GCC, which is probably not something that the users would normally expect when emerging dhcpcd.
(In reply to John Bowler from comment #0) > The work-round is to set CC=/usr/bin/cc in the ebuild if it is not already > set, but it is an upstream bug; dhcpcd should *NOT* be building with clang, > unless it is deliberately configured as the default C compiler. Because --host was specified dhcpcd will look for a compiler matching your host, so it won't look for cc in path, it will look for your default host compiler x86_64-pc-linux-gnu-cc. I have no idea why Gentoo wants to give --host and/or --build options when not cross compiling. It seems that the autoconf docs changed since I last looked at them: https://www.gnu.org/software/autoconf/manual/autoconf-2.69/html_node/Hosts-and-Cross_002dCompilation.html It says that it only enters "cross compile mode" when host != build. Pretty sure it used to say when --host was set but it's been a few years since I last read that doc. Anyway, I cut this patch: http://roy.marples.name/projects/dhcpcd/ci/d77d685a15531da700ed7c9714c8b8f055bc74a2?sbs=0 So this issue should be fixed.
(In reply to Siarhei Siamashka from comment #9) > Just Clang happens to > have higher priority than GCC, which is probably not something that the > users would normally expect when emerging dhcpcd. All things being equal, clang
(In reply to Roy Marples from comment #10) > I have no idea why Gentoo wants to give > --host and/or --build options when not cross compiling. It seems to always pass both --host and --build to 'configure', at least if the .ebuild uses the built-in 'econf' command. It doesn't provide --target unless building a cross compiler (i.e. host == build != target). host != build seems to me to be the correct test John Bowler
dhcpcd-6.4.7 is now in the tree, so this issue should now be fixed.
