You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The Centos 6 asset is able to run ruby code using native extensions compiled against Centos 6 glibc.
Current behavior
The centos 6 asset errors when running ruby code using native extensions.
Reproduction steps
Stand up a Centos 6.10 host running the Sensu agent
Add assets for version 0.0.10 of sensu-ruby-runtime for centos 6 and version 5.0.0 of sensu-plugins-disk-checks
add a check which uses those runtime assets, with check-disk-usage.rb
Observe that the check results show an error related to GLIBC_VERSION 2.14 not found -- centos 6.10 is expected to have GLIBC version 2.12
Context
I feel like I've run into similar behavior in the past where using Docker containers to compile binaries for platforms with one version of glibc actually results in binaries linked to the docker host glibc. It might be the case that we cant use Docker for our build process here?
The text was updated successfully, but these errors were encountered:
I think case of sensu-plugins-disk-checks, it looks like it was not rebuilt after the glibc issues were sorted out in the ruby runtime. To work on centos6, assets need to offer an explicit centos6 build.
I'm spinning up a update for sensu-plugins-disk-checks in my namespace now as a test to make sure I'm right.
Probably what we need to do is review/update the .bonsai.yml for the existing sensu-plugins that have assets and respin them all in one push to make sure we have centos6 builds for all the existing ones.
Expected behavior
The Centos 6 asset is able to run ruby code using native extensions compiled against Centos 6 glibc.
Current behavior
The centos 6 asset errors when running ruby code using native extensions.
Reproduction steps
check-disk-usage.rb
GLIBC_VERSION
2.14 not found -- centos 6.10 is expected to have GLIBC version 2.12Context
I feel like I've run into similar behavior in the past where using Docker containers to compile binaries for platforms with one version of glibc actually results in binaries linked to the docker host glibc. It might be the case that we cant use Docker for our build process here?
The text was updated successfully, but these errors were encountered: