[OS-BUILD PATCHv2] kernel.spec: Add glibc-static build requirement

[Prarit Bhargava (via Email Bridge)]

From: Prarit Bhargava <prarit(a)redhat.com&gt;

kernel.spec: Add glibc-static build requirement

CKI and brew builds resulted in two different values for
CONFIG_CC_CAN_LINK_STATIC.  In CKI CONFIG_CC_CAN_LINK_STATIC=y while in
brew CONFIG_CC_CAN_LINK_STATIC was not defined.  This occurs because
glibc-static is installed on the CKI build containers and was not
installed in brew.

In order to guarantee consistency across build systems add a build
requirement for the glibc-static package.

Signed-off-by: Prarit Bhargava <prarit(a)redhat.com&gt;

diff --git a/redhat/kernel.spec.template b/redhat/kernel.spec.template
index blahblah..blahblah 100755
--- a/redhat/kernel.spec.template
+++ b/redhat/kernel.spec.template
@@ -585,6 +585,8 @@ BuildRequires: net-tools, hostname, bc, elfutils-devel
 BuildRequires: dwarves
 BuildRequires: python3-devel
 BuildRequires: gcc-plugin-devel
+# required for CONFIG_CC_CAN_LINK_STATIC=y
+BuildRequires: glibc-static
 %ifnarch %{nobuildarches} noarch
 BuildRequires: bpftool
 %endif

--
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/1538

[Prarit Bhargava (via Email Bridge)]

From: Prarit Bhargava on gitlab.com
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/1538#note_8074...

Weird.  I only see one commit in this MR?

[Prarit Bhargava (via Email Bridge)]

From: Prarit Bhargava on gitlab.com
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/1538#note_8074...

In any case, refreshed and pushed.

[Bruno Meneguele (via Email Bridge)]

From: Bruno Meneguele on gitlab.com
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/1538#note_8086...

@prarit I still didn't get why we don't disable `CONFIG_CC_CAN_LINK_STATIC`
instead of bringing `glibc-static` to buildroot, even because the don't expect
to have any users of it anytime soon.

[Prarit Bhargava (via Email Bridge)]

From: Prarit Bhargava on gitlab.com
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/1538#note_8096...

> @prarit I still didn't get why we don't disable
> `CONFIG_CC_CAN_LINK_STATIC` 
instead of bringing `glibc-static` to buildroot, even
because we don't expect
to have any users of it anytime soon.

CONFIG_CC_CAN_LINK_STATIC is set dynamically at runtime in init/Kconfig:68,

```
config CC_CAN_LINK_STATIC
        bool
        default $(success,$(srctree)/scripts/cc-can-link.sh $(CC)
$(CLANG_FLAGS) $(m64-flag) -static) if 64BIT
        default $(success,$(srctree)/scripts/cc-can-link.sh $(CC)
$(CLANG_FLAGS) $(m32-flag) -static)

```
I thought about submitting a patch to add CONFIG_CC_CAN_LINK_STATIC_FORCE
upstream, or yet-another RHEL & ARK only commit to force
CONFIG_CC_CAN_LINK_STATIC to "not set" but both of those have some
trade-offs associated with them.

Ultimately we want a "known" compile.  Adding glibc-static to the
buildroot guarantees that we have the same compile on any platform (brew
or CKI containers).

[Jan Stancek (via Email Bridge)]

From: Jan Stancek on gitlab.com
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/1538#note_8132...

+CC @veruu

3rd option is to remove glibc-static from CKI buildroot, since it was
installed proactively, not as result of BuildRequires.

>  In order to guarantee consistency across build systems 
Is CKI buildroot based on BuildRequires from kernel.spec? If yes, then it's
safe to remove glibc-static, since if we need it later we'll add it to
BuildRequires. If no, then anytime we change BuildRequires, CKI needs to catch
up to be consistent.

[Veronika Kabátová (via Email Bridge)]

From: Veronika Kabátová on gitlab.com
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/1538#note_8135...

Yes, we can remove `glibc-static` from the RHEL env. ARK is *kinda* upstream
so I'd need to double check we'd not break anything else by doing that, since
we inherited the binary from some upstream run in the past. I did offer this
solution in the original email thread, and it is a possibility, but IMO it's
not the whole solution in this case:

One negative of doing that is that developers/users building the kernel on
various local environments will run into the inconsistency of the configs that
can puzzle them. Having either the config or the dependency stable (always
on/off) would prevent the confusion. Basically what @prarit said about a known
compile but across *any* environment.

[Ondrej Mosnacek]

On Tue, Jan 18, 2022 at 12:19 PM Veronika Kabátová (via Email Bridge)
<cki-gitlab(a)redhat.com&gt; wrote:
>  From: Veronika Kabátová on gitlab.com
>  https://gitlab.com/cki-project/kernel-ark/-/merge_requests/1538#note_8135...
>
>  Yes, we can remove `glibc-static` from the RHEL env. ARK is *kinda* upstream
>  so I'd need to double check we'd not break anything else by doing that, since
>  we inherited the binary from some upstream run in the past. I did offer this
>  solution in the original email thread, and it is a possibility, but IMO it's
>  not the whole solution in this case:
>
>  One negative of doing that is that developers/users building the kernel on
>  various local environments will run into the inconsistency of the configs that
>  can puzzle them. Having either the config or the dependency stable (always
>  on/off) would prevent the confusion. Basically what @prarit said about a known
>  compile but across *any* environment. 
Then how about adding `BuildConflicts: glibc-static` (+ an explaining
comment) to kernel.spec?

https://rpm-software-management.github.io/rpm/manual/spec.html#buildconfl...

-- 
Ondrej Mosnacek
Software Engineer, Linux Security - SELinux kernel
Red Hat, Inc.

[Neal Gompa]

On Tue, Jan 18, 2022 at 6:26 AM Ondrej Mosnacek <omosnace(a)redhat.com&gt; wrote:
>  On Tue, Jan 18, 2022 at 12:19 PM Veronika Kabátová (via Email Bridge)
>  <cki-gitlab(a)redhat.com&gt; wrote:
>  > From: Veronika Kabátová on gitlab.com
>  > https://gitlab.com/cki-project/kernel-ark/-/merge_requests/1538#note_8135...
>  >
>  > Yes, we can remove `glibc-static` from the RHEL env. ARK is *kinda* upstream
>  > so I'd need to double check we'd not break anything else by doing that,
> since
>  > we inherited the binary from some upstream run in the past. I did offer this
>  > solution in the original email thread, and it is a possibility, but IMO it's
>  > not the whole solution in this case:
>  >
>  > One negative of doing that is that developers/users building the kernel on
>  > various local environments will run into the inconsistency of the configs that
>  > can puzzle them. Having either the config or the dependency stable (always
>  > on/off) would prevent the confusion. Basically what @prarit said about a known
>  > compile but across *any* environment.
>
>  Then how about adding `BuildConflicts: glibc-static` (+ an explaining
>  comment) to kernel.spec?
>
>  https://rpm-software-management.github.io/rpm/manual/spec.html#buildconfl...
>  
Do "BuildConflicts" work with "dnf builddep"? Has anyone ever tried
that before? It'd be good to test to be sure it works. If it doesn't,
file a bug so it can be fixed.




--
真実はいつも一つ！/ Always, there's only one truth!

[Prarit Bhargava (via Email Bridge)]

From: Prarit Bhargava on gitlab.com
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/1538#note_8137...

> Do "BuildConflicts" work with "dnf builddep"? Has
> anyone ever tried
> that before? It'd be good to test to be sure it works. If it doesn't,
> file a bug so it can be fixed.
>  
The problem with "BuildConflicts" is that it is only useful for build
environments and not developer environments.  If I have a valid case for
having glibc-static installed on my system then I can no longer no build
the kernel without uninstalling glibc-static.  That's not a good
experience.

I'd prefer to stick with BuildRequires.

[Prarit Bhargava (via Email Bridge)]

From: Prarit Bhargava on gitlab.com
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/1538#note_8293...

@bmeneg ?  I think we answered your question.  The issue is that I want a
reproducible build ANYWHERE.

[Prarit Bhargava (via Email Bridge)]

From: Prarit Bhargava on gitlab.com
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/1538#note_8293...

I have answered this question.  BuildConflicts would require uninstalling
glibc-static, so we must use BuildRequires.  Resolving thread.

[Don Zickus (via Email Bridge)]

From: Don Zickus on gitlab.com
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/1538#note_8294...

@prarit - nitpick.  Can we add a sentence or two to the spec file or changelog
that sums up what Veronika said (or the conclusion we made about build env).
My concern is 3 years from now, someone asks 'why is this here?'  'for
CC_STATIC_LINK' seems to lack context.

Something like, needed to keep all build envs across CI, official builds and
speciality builds consistent.

Thoughts?

[Bruno Meneguele (via Email Bridge)]

From: Bruno Meneguele on gitlab.com
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/1538#note_8310...

Oh, sorry for missing this blocking thread. You did answer my question and I'm
fine with the solution based on the above discussion. Sorry for holding it.