Skip to content
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

Merged
merged 5 commits into from
Oct 1, 2021
Merged

Conversation

bcressey
Copy link
Contributor

@bcressey bcressey commented Sep 29, 2021

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 that chronyc can issue commands like "dump" without causing a seccomp violation.

Tested aws-k8s-1.21 for both architectures and verified that sonobuoy passed. Confirmed that tasks could run on an aws-ecs-1 build.

Tested vmware-k8s-1.21 with a cluster created by EKS Anywhere. Verified that sonobuoy 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.

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>
etungsten
etungsten previously approved these changes Sep 29, 2021
@etungsten
Copy link
Contributor

vmware builds are failing due to libglib package needed by open-vm-tools

@etungsten etungsten dismissed their stale review September 29, 2021 19:15

vmware variants builds are failing.

@bcressey bcressey marked this pull request as draft September 29, 2021 19:51
@bcressey
Copy link
Contributor Author

Back to draft to fix open-vm-tools.

Copy link
Contributor

@tjkirch tjkirch left a 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.

packages/glibc/glibc.spec Outdated Show resolved Hide resolved
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>
Copy link
Contributor

@tjkirch tjkirch left a 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.

packages/libglib/libglib.spec Show resolved Hide resolved
Copy link
Contributor

@arnaldo2792 arnaldo2792 left a 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>
@bcressey bcressey marked this pull request as ready for review October 1, 2021 03:26
Copy link
Contributor

@zmrow zmrow left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🦘

@bcressey bcressey merged commit b7d6059 into bottlerocket-os:develop Oct 1, 2021
@bcressey bcressey deleted the glibc-update branch October 1, 2021 19:57
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

update to glibc 2.34 Update libglib to 2.69.0+
5 participants