Bug 753605 – sys-boot/lilo-24.2-r1 calls cc directly

• Product: Gentoo Linux
• Status: CONFIRMED ---

[Description Agostino Sarubbo 2020-11-08 21:48:49 UTC]

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.

[Comment 1 Agostino Sarubbo 2020-11-08 21:48:52 UTC]

Created attachment 670511 [details]
build.log

build log and emerge --info

[Comment 2 Agostino Sarubbo 2020-11-08 21:52:32 UTC]

it uses the right CC while the check picks the wrong one

[Comment 3 Joshua Kinard 2021-06-06 21:13:04 UTC]

(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?

[Comment 4 Agostino Sarubbo 2022-04-23 06:37:01 UTC]

ci has reproduced this issue with version 24.2-r1 - Updating summary.

[Comment 5 Peter Stuge 2022-04-23 13:54:00 UTC]

(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:.

[Comment 6 Peter Stuge 2022-04-23 14:18:15 UTC]

(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.

[Comment 7 Mike Gilbert 2022-04-23 14:34:58 UTC]

(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.

[Comment 8 Peter Stuge 2022-04-23 14:35:01 UTC]

Created attachment 773618 [details, diff]
Remove direct call to gcc from upstream checkit script

[Comment 9 Joshua Kinard 2022-04-23 18:33:20 UTC]

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?