Fix RPMs using a too-new version of glibc #11008
Conversation
| @@ -175,7 +176,11 @@ func tagPipelines() []pipeline { | |||
|
|
|||
| // RPM/DEB package builds | |||
| for _, packageType := range []string{rpmPackage, debPackage} { | |||
| ps = append(ps, tagPackagePipeline(packageType, buildType{os: "linux", arch: arch, fips: fips})) | |||
| bt := buildType{os: "linux", arch: arch, fips: fips} | |||
| if packageType == "rpm" && arch == "amd64" { | |||
There was a problem hiding this comment.
Could you add a comment here explaining why we're doing this. Similar to the one in build-package.sh.
There was a problem hiding this comment.
Should I add one here or at #R291 ? This simply sets the field value (which could be used anywhere) while R291-R295 does something with it.
There was a problem hiding this comment.
I think here is appropriate since we want to explain why we're setting the centos7 flag when building x8664 rpms.
There was a problem hiding this comment.
Come to think of it I don't know that we should be checking the architecture here. The original fix only covered amd64, but I don't see any reason why the issue wouldn't affect i386 and ARM as well. That being said, I don't have an easy way to test this. Do you have any thoughts here?
There was a problem hiding this comment.
Good question. I imagine those are less commonly used than amd64 but we'd probably fix them too. Let's do amd64 first so we can fix the most common use case and then follow up with ARM/32-bit (don't know if anyone's actually using it TBH). Can you use AWS account to spin up proper CentOS 7 boxes for testing? They should have ARM boxes.
There was a problem hiding this comment.
Also, looking at our downloads page, it doesn't look like we actually provide CentOS 7 compatible ARM binaries at all currently.
There was a problem hiding this comment.
I can test 64 bit ARM on AWS pretty easily, but as far as I am aware there are not any 32 bit CentOS 7 or RHEL AMIs available on AWS. This makes it non-trivial to test for 32 bit issues. That being said, if the issue persists with 64 bit ARM it probably affects i386 and ARMv7 as well.
| @@ -175,7 +176,11 @@ func tagPipelines() []pipeline { | |||
|
|
|||
| // RPM/DEB package builds | |||
| for _, packageType := range []string{rpmPackage, debPackage} { | |||
| ps = append(ps, tagPackagePipeline(packageType, buildType{os: "linux", arch: arch, fips: fips})) | |||
| bt := buildType{os: "linux", arch: arch, fips: fips} | |||
There was a problem hiding this comment.
| bt := buildType{os: "linux", arch: arch, fips: fips} | |
| bt := buildType{os: "linux", arch: arch, fips: fips, centos7: packageType == "rpm"} |
- You can inline this without the need for a conditional.
- Do we need to check arch? If package type is RPM I think it's safe to assume we should use the CentOS builds.
I stood up an amd64 CentOS 7 box in EC2 (ami-00f8e2c955f7ffa9b) and verified that the commands in the package would run. Previously they would fail to execute because the dynamic linker could not find a matching library for glibc. I did not test any specific functionality outside of |
Fixed an issue where RPMs would contain artifacts built against a newer version of glibc than CentOS and RHEL support. This is a fix for #10686. This is primarily an update to dronegen that formalizes the v8 version of this fix (c0a1e07).