You receive this bug because this package prints directly gcc instead of system's CC This could be a cosmetic bug because mostly this is only a print error and it really uses system's CC The possible solution to fix this issue is check the config.log and: - if this is a print error and it uses the system's CC, a sed could fix. - if you really see gcc instead of system's CC, this package does not respect CC From the build log: checking whether gcc -fPIE works... yes
As you know, for such bugs we require a build.log Have you actually see this problem when compiling the sources?
(In reply to Markos Chandras from comment #1) > As you know, for such bugs we require a build.log The build log is needed for bug irreproducible on all machines, which is not this case.
I don't understand what you mean
I am asking you to provide a build.log to verify this is an actual problem during build time. If you don't bother providing proper bug reports then please do not ask as to do the bug investigation for you.
Created attachment 357934 [details] build log After you read the build log, please tell me how this is useful in this case. thanks.
(In reply to Agostino Sarubbo from comment #5) > Created attachment 357934 [details] > build log > > After you read the build log, please tell me how this is useful in this > case. thanks. Looking at the build.log there is no bug here. The build system uses the correct toolchain tuple when building the sources (x86_64-pc-linux-gnu-gcc). See? The build.log is actually useful without me having to actually build the package to produce it myself.
(In reply to Markos Chandras from comment #6) > Looking at the build.log there is no bug here. The build system uses the > correct toolchain tuple when building the sources (x86_64-pc-linux-gnu-gcc). Did you understand the sense of this bug? who talked about the build of the source? otherwise the bug summary would be: does not respect CC Also, make no sense do the test at configure with A and compile with B. The bug is not invalid.
It does respect CC while during configure phase. 1) please check config.log configure:5488: checking whether gcc -fPIE works configure:5504: x86_64-pc-linux-gnu-gcc -o conftest -fPIE -pie conftest.c >& 5 2) also check configure.in, you may find following lines. AC_MSG_CHECKING([whether gcc -fPIE works]) so "checking whether gcc -fPIE works... yes" is just the output message. btw, I do agree we should make CC consist during configure and compile phases.. thanks.
(In reply to Dennis 'dlan' Lan from comment #8) > It does respect CC while during configure phase. > > 1) please check config.log > > configure:5488: checking whether gcc -fPIE works > configure:5504: x86_64-pc-linux-gnu-gcc -o conftest -fPIE -pie conftest.c > >& 5 > > 2) also check configure.in, you may find following lines. > > AC_MSG_CHECKING([whether gcc -fPIE works]) > > so "checking whether gcc -fPIE works... yes" is just the output message. > > btw, I do agree we should make CC consist during configure and compile > phases.. > thanks. I don't know if we are talking 2 different languages. I _KNOW_ that it does the check with the correct CC but it prints the wrong, and this is a bug for me.
(In reply to Agostino Sarubbo from comment #9) > (In reply to Dennis 'dlan' Lan from comment #8) > > It does respect CC while during configure phase. > > > > 1) please check config.log > > > > configure:5488: checking whether gcc -fPIE works > > configure:5504: x86_64-pc-linux-gnu-gcc -o conftest -fPIE -pie conftest.c > > >& 5 > > > > 2) also check configure.in, you may find following lines. > > > > AC_MSG_CHECKING([whether gcc -fPIE works]) > > > > so "checking whether gcc -fPIE works... yes" is just the output message. > > > > btw, I do agree we should make CC consist during configure and compile > > phases.. > > thanks. > > I don't know if we are talking 2 different languages. > > I _KNOW_ that it does the check with the correct CC but it prints the wrong, > and this is a bug for me. It might be a bug for you but not for us. Please stop re-opening this bug. There is nothing wrong with the configure phase. The check for -fPIE is correct.
Created attachment 357940 [details, diff] respect CC, patch for the ebuild oh, I just didn't realized that you mean *the message* .. this patch should improve the readability, make user feel less confusion. please review.. thanks
(In reply to Dennis 'dlan' Lan from comment #11) > Created attachment 357940 [details, diff] [details, diff] > respect CC, patch for the ebuild > > oh, I just didn't realized that you mean *the message* .. > > this patch should improve the readability, make user feel less confusion. > > please review.. thanks *sigh* fine. If we are really fixing this when i think it should use $(tc-getCC) instead of $CC
You're complaining about hard-coded strings in a configure message? This has ZERO impact in the final binaries. It's purely a cosmetic fix in the compile, and I'm NOT carrying code for cosmetic changes.
