Hello!
So in recent Sensu version there’s been a new feature added to detect libc implementation, that should help make it possible to build assets that require runtime library support to operate.
My understanding is that different libc implementations use incompatible linker ABIs. Dynamic libraries built with one libc implementation can’t be linked on a system using the linker that uses a different libc.
I’m probably using sub-optimal words to describe the situation.
The most common example of this wrinkle is Alpine linux,. widely used as a base container uses musl libc instead of glibc. So dynamic libraries built on Debian, for example. typically can’t be runtime linked on Alpine…without some effort to prep the Alpine environment. This is just the most common example, this also pops up as a problem for uClibc in embedded systems.
For assets we’ve been trying to workaround this by filtering on platform, but hopefully now that Sensu is able to detect the libc version, we can be more accurate with the filter rules and filter on the libc implementation.
So what does this mean?
I’m going to be prepping some forked asset examples in my namespace in Bonsai, with the intent on moving those changes over to the main repositories and then converting the plugin templates to use the new filtering rules. Ideally this shouldn’t impact any existing users running recent version of sensu-backend and sensu-agent. But this may impact users running older versions…similar to the introduction of the multi-build asset concept.