-
Notifications
You must be signed in to change notification settings - Fork 524
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
update glibc to 2.34 #1763
update glibc to 2.34 #1763
Conversation
Otherwise, when the host and target architectures are the same, the codegen programs will be linked with target libraries like glibc, and could fail to execute because of missing symbols. Signed-off-by: Ben Cressey <bcressey@amazon.com>
vmware builds are failing due to |
Back to draft to fix |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM modulo the vmware build issue.
In 2.34, many of the separate libraries like `pthread` are integrated in the main library, and shared objects are no longer installed with versioned file names. Update the packaged file lists to reflect these changes. Add patches from the upstream branch for the 2.34 release, to pick up additional fixes, such as the fix for CVE-2021-38604. Sync the C.UTF-8 locale patch with recent changes from Fedora. Signed-off-by: Ben Cressey <bcressey@amazon.com>
Signed-off-by: Ben Cressey <bcressey@amazon.com>
Setting "needs_exe_wrapper" without defining a wrapper binary causes meson to skip execution. Otherwise, when the build and target architectures match, meson may decide that cross-compiled binaries can be executed. That may not be true, for example if the target's glibc version is more recent. Signed-off-by: Ben Cressey <bcressey@amazon.com>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I left a couple suggestions to help future packagers keep these up to date, but overall it looks good to me.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🛥️
Includes a fix for calling the `close_range()` function, which was added in glibc 2.34. glib2 still depends on the original PCRE library, rather than PCRE2 which we package as "libpcre". Older versions of glib2 included pcre sources directly in the tree; newer versions use a meson subproject and wrap to vendor the dependency. meson is blocked from downloading sources, so we now include the pcre archive and build overlay as external files. This package is expected to remain the only consumer of PCRE in the distro. Signed-off-by: Ben Cressey <bcressey@amazon.com>
8b8eec4
to
8fffc5a
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🦘
Issue number:
Fixes #1717
Fixes #1675
Description of changes:
Update glibc to 2.34. Change the patching strategy to include patches added to the maintenance branch after the official 2.34 release, which aligns with Fedora's current approach.
Fix a cross-compilation bug for kubelet that caused us to link with target libraries for host programs when the architectures were the same. This was exposed by missing glibc symbols following the update, but was a latent regression from when we switched to the new upstream method of specifying the toolchain in #1612. It does not apply to older builds of kubelet, which used a local patch instead.
Add the upstream patch for chrony's seccomp filter so it runs with the newer glibc.
Update glib2 to 2.70.0, which includes a fix for the newer glibc. Tweak the cross-compiling file for meson to avoid attempts to execute target files, which failed because of missing glibc symbols.
Testing done:
Verified that
chronyd
starts running and stays up for multiple days on both architectures. Using the developer image, confirmed thatchronyc
can issue commands like "dump" without causing a seccomp violation.Tested
aws-k8s-1.21
for both architectures and verified thatsonobuoy
passed. Confirmed that tasks could run on anaws-ecs-1
build.Tested
vmware-k8s-1.21
with a cluster created by EKS Anywhere. Verified thatsonobuoy
passed.Terms of contribution:
By submitting this pull request, I agree that this contribution is dual-licensed under the terms of both the Apache License, version 2.0, and the MIT license.