Roy, somewhere between dhcpcd-6.3.1 and dhcpcd-6.3.2, the configure script was changed so that it does not set the compiler correctly. I'll attach build logs for dhcpcd-6.3.1-r1 and 6.3.2.
Created attachment 373372 [details] dhcpcd-6.3.1-r1.log Notice which compiler the configure script is using in this version.
Created attachment 373374 [details] dhcpcd-6.3.2.log Notice that the compiler changed in this version. This is a regression.
Roy, It turns out that a downstream fix was added both to 6.3.1-r1 and 6.3.2 without reporting this to you. I am working on a patch.
To clarify: the build system no longer uses the host-prefixed compiler by default. This was probably introduced by this check-in: http://roy.marples.name/projects/dhcpcd/info/82cd85d0eb
This change was made so that the clang static analyzer can be used easily like so ./configure scan-build make
So, if CC is not passed to configure then we assume cc in $PATH just like default make $CC variable. That kinda made sense unless anyway can poke a hole in it.
It's just a bit strange to those of us who are used to the autoconf behavior. To use your own example, I imagine this would work for your "clang static analyzer" use case: export CC=clang ./configure scan-build make
One further point of clarification: autoconf uses CC if it is set, and otherwise falls back on HOST-gcc, gcc and finally cc. I think that's the behavior most people would expect.
Created attachment 373380 [details, diff] fix-compiler.patch Roy, here is a patch that would take care of this issue I believe. The problem is that if CC is not in the env, you force it to cc, which is not correct.
Yeah, so that's configure forcing CC on make,(In reply to Mike Gilbert from comment #8) > One further point of clarification: autoconf uses CC if it is set, and > otherwise falls back on HOST-gcc, gcc and finally cc. I think that's the > behavior most people would expect. HOST-cc *should* be cc in $PATH. If there is no cc in $PATH then we play find the compiler. But this is a moot point. Is there a reason why Gentoo cannot export CC in either the configure or make phase?
(In reply to William Hubbs from comment #9) > The problem is that if CC is not in the env, you force it to cc, which > is not correct. I disagree. cc is supposed to be the default host compiler, which can be changed via CC environment variable. If you think otherwise then why does Gentoo install cc in the first place?
(In reply to Roy Marples from comment #10) > Is there a reason why Gentoo cannot export CC in either the configure or > make phase? No reason at all; the latest ebuild already does that. > I disagree. cc is supposed to be the default host compiler, which can be changed via CC environment variable. Why bother supporting the --build, --host, and --target options then? You are pretending to be autotools, but doing it incompletely.
(In reply to Mike Gilbert from comment #12) > Why bother supporting the --build, --host, and --target options then? You > are pretending to be autotools, but doing it incompletely. That is a good point. If any of those flags are set then CC should be set in configure. Anyone care to patch that as I'm about to hit the hay?
I am willing to do the patch, what should the rules be for setting CC in that case?
I'm not sure what happened to an earlier comment I posted, but I did attempt something else that should have worked but got nowhere. According to the message from your configure script, I should be able to do this: configure CC="$(tc-getCC)" but that fails. Should it?
(In reply to Roy Marples from comment #13) > That is a good point. If any of those flags are set then CC should be set in > configure. Anyone care to patch that as I'm about to hit the hay? If CC is set in the environment we should use it unconditionally; this allows the user to pass a valid --host triplet while also using a compiler which may not utilize the GNU naming convention. Again, this is standard autoconf behavior. William's patch is pretty close. I would just reverse the order of $HOST-gcc and clang (putting $HOST-gcc first).
Does this patch work for you? I think it meets my view at least. http://roy.marples.name/projects/dhcpcd/ci/8d65cb3139?sbs=0
Not quite. Here's a cross-compile example: ./configure --build=x86_64-pc-linux-gnu --host=armv7a-hardfloat-linux-gnueabi This outputs: Using compiler .. /usr/bin/x86_64-pc-linux-gnu-gcc I would expect to see: Using compiler .. /usr/bin/armv7a-hardfloat-linux-gnueabi-gcc I think you may be mixing up the meaning HOST and TARGET a bit. TARGET is only used when building a cross-compiler; it is ignored when cross-compiling an application.
One thing I think I would change is the order in which you search for compilers. On line 260, when you set the _COMPILERS variable, it might be better to put cc last so you can look for the other compilers first. You might also consider putting gcc before clang in that list since gcc is a bit more common, but I think putting cc last is probably more important. Thoughts? William
I have nfc why I did this anyway, I just use the host thingy to work out which source files I need - linux / bsd / kfreebsd
http://roy.marples.name/projects/dhcpcd/fdiff?v1=d28c0112ca02c172&v2=c47c6746cf5e5e75&sbs=1 http://roy.marples.name/projects/dhcpcd/fdiff?v1=c47c6746cf5e5e75&v2=2b2bb463784b8253&sbs=1 Better?
(In reply to William Hubbs from comment #19) > One thing I think I would change is the order in which you search for > compilers. On line 260, when you set the _COMPILERS variable, it might > be better to put cc last so you can look for the other compilers first. > > You might also consider putting gcc before clang in that list since gcc > is a bit more common, but I think putting cc last is probably more > important. > > Thoughts? cc is supposed to be the user selected compiler. So we're going to play "pick the compiler based on --host" then cc will be first, then a list of real compilers.
(In reply to Roy Marples from comment #21) > Better? That works quite well. Thanks!
Roy, should I cherry-pick all of these patches, or are you going to release 6.3.3 soon? Thanks, William
You're already forcing $CC so no real need to cherry pick. But I should be releasing a new version soon.
Roy, yes, $CC is being forced in 6.3.2, but I was asking because I want to change our package to use the upstream fix and stop forcing $cc. If you are going to release in the nesxt few days I'll wait for that, but if not, I want to cherry-pick and do a revbump. Thanks, William
(In reply to William Hubbs from comment #26) Calling "tc-export CC" as the ebuild currently does resolves the issue. There is absolutely no reason to cherry-pick these changes.
Also, even if you do cherry-pick them, a revbump is unnecessary: this is a build-time issue, and we are not actually changing any of the installed files.
I have added the patches to dhcpcd-6.3.2.
