https://blogs.gentoo.org/ago/2020/07/04/gentoo-tinderbox/ Issue: sys-boot/lilo-24.2 calls cc directly. Discovered on: amd64 (internal ref: ci) NOTE: As per QA policy, toolchain tools must not be called directly because they can cause issue in cross-compiling and because is not possible use a different CC implementation (like clang). To reproduce, please use sys-devel/gcc-config[-native-symlinks], sys-devel/binutils-config[-native-symlinks] and set the CC variable to x86_64-pc-linux-gnu-gcc.
Created attachment 670511 [details] build.log build log and emerge --info
it uses the right CC while the check picks the wrong one
(In reply to Agostino Sarubbo from comment #2) > it uses the right CC while the check picks the wrong one Is the check in lilo itself or is this something the ebuild is doing wrong?
ci has reproduced this issue with version 24.2-r1 - Updating summary.
(In reply to Joshua Kinard from comment #3) > Is the check in lilo itself or is this something the ebuild is doing wrong? The lilo checkit script runs "gcc -v 1>foo1 2>foo2" and parses the output to check for >=gcc-3.3.5. It does the same for >={as,ld}86-0.16.14 and exits 1 if either requirement is not met. Makefile calls ./checkit in the test: target, which is a dependency for all:. I think we have two TODOs here: 1. Correct lilo-24.2-r1.ebuild DEPEND=">=sys-devel/bin86-0.15.5" to 0.16.14 2. Make the checkit script a nop or just remove the test: target from all:.
(In reply to Agostino Sarubbo from comment #0) > toolchain tools must not be called directly because they > can cause issue in cross-compiling and because is not possible use a > different CC implementation (like clang). What about calling as86 and ld86? (from sys-devel/bin86) I'm creating a patch to sed out the gcc call but would like to keep the bin86 checks since our DEPEND could be wrong, as it has been for some time now.
(In reply to Peter Stuge from comment #6) I think as86 and ld86 would always produce x86 output, so cross-compiling (CHOST) is not relevant. It should be fine to call them directly.
Created attachment 773618 [details, diff] Remove direct call to gcc from upstream checkit script
Does anyone know if there have been any attempts to compile lilo with clang/llvm before, and if so, what happened? E.g., did it compile/link, did it boot to the loader prompt, and/or, did it boot a Linux kernel? If clang can successfully compile lilo, then I think the checkit script can either be re-written or maybe even done away with entirely -- let the package manager and the ebuild dictate the minimum require $CC versions, be it gcc or clang. On the other hand, if it is identified that lilo does not work some or at all with clang/llvm, then those issues need to be looked at in closer detail to see if they are fixable and what level of effort is needed to do so. If the issues are not fixable, or are too extensive to fix, then perhaps lilo should be restricted to gcc only. There are other options for bootloaders out there. In this case, I might still be tempted to ditch the checkit script and let the ebuild enforce minimum version requirements. Thoughts?
ci has reproduced this issue with version 24.2-r2 - Updating summary.
