GLIBC 2.29 requirement for Pandas 0.15.0 breaks crispr

[fdrennan]

Hey folks — I’ve tracked down an error on systems using GLIBC_2.28 (shpc) with an error requiring GLIBC_2.29 in the crisprScore call stack.

The issue comes from a binary in this Basilisk-managed environment:

/apps/rocs/cedar/2020.08/cascadelake/site-libs/R/cedar_r4.4_bioc3.20-release/2024_11_22/incremental/rlibs/crisprScore/basilisk/crisprai_basilisk/lib/python2.7/site-packages/pandas/_sparse.so

That _sparse.so binary links against GLIBC_2.29, which isn't available on our RHEL 8.6 systems (we’re on GLIBC_2.28). This means the crisprScore call fails at runtime anytime it touches the crisprai scoring logic with Basilisk active.

Important: this is not a Cedar or LSF runtime bug — it’s a Conda ecosystem artifact. The .so came from a precompiled pip/conda wheel, which was likely built on a newer system (e.g., Ubuntu 20.04+), and wasn’t rebuilt from source in our controlled GLIBC context.

Basilisk doesn’t override this by default, so unless explicitly told to compile from source, it will pull binaries that may be incompatible.

Thoughts regarding what’s acceptable upstream:

• We could try pinning pandas==0.15.0 to a version that predates _sparse.so if that's safe in basilisk.R.
• Or, rebuild that environment from source with an older GLIBC toolchain, though that adds complexity to the Basilisk bootstrap.

[Jfortin1]

Hi @fdrennan,

The basilisk team has modified their machinery so that this doesn't happen; we are adapting crisprScore accordingly, and will keep you updated