GLIBC incompatibility with default Ubuntu 22.04 binary (inla.mkl) on containerized deployment; older Linux-build binary works but INI format mismatch (INLA.stiles)

[Manuel Spínola]

Hi all,
 
I'm deploying a Shiny app (R package built with golem) that uses INLA on Posit
Connect Cloud, a containerized platform running Ubuntu 22.04.5 with GLIBC 2.35.
I'd appreciate any guidance on the best way forward.
 
**Setup:**
- INLA R package version 26.06.08 (installed fresh at deploy time)
- inlabru 2.14.1
- Platform: Ubuntu 22.04.5 container, GLIBC 2.35 available (confirmed via ldd)
 
**Problem 1 (resolved by working around it, not fixed):**
The only binary distributed for this platform is `inla.mkl` / `inla.mkl.run`.
Running it fails with:
 
  version `GLIBC_2.38' not found (required by .../inla.mkl)
  version `GLIBC_2.36' not found (required by .../first/libstdc++.so.6)
 
So the distributed Ubuntu-22.04.5 build appears to require a newer GLIBC than
is available in this (fairly standard) Ubuntu 22.04 container.
 
**Workaround attempted:**
Following the guidance in the docs and mailing list about alternative Linux
builds (downloading directly from the Linux-builds directory rather than the
interactive inla.binary.install() menu, since our deploy process is
non-interactive), I substituted the Ubuntu-20.04.6 build, Version_23.05.30-1
(the most recent one listed for that OS folder), using the inla.run wrapper
script (not the raw inla binary, which fails separately on a missing
libRmath.so.1 — using inla.run resolves that by setting up
LD_LIBRARY_PATH correctly).
 
**Problem 2 (current blocker):**
With that older binary in place, INLA now runs (no GLIBC error, no missing
library, no segfault), correctly parses most of the model, but fails with:
 
  *** ERROR *** inla_build: section=[INLA.stiles] is not used; please check its type=[STILES]
 
I understand this is because the Version_23.05.30-1 binary predates the
23.08.18 change where INLA moved to depending on the fmesher package instead
of a standalone binary -- so the INI file being generated by our (current,
26.06.08) R package includes a section format the old binary doesn't
recognize.
 
**Question:**
Is there a supported combination of (a) a Linux-builds binary compiled
against an older/lower GLIBC baseline, that is (b) recent enough (post
23.08.18) to be compatible with the INI format generated by a current INLA/
inlabru installation? Or alternatively, is there a recommended way to pin the
INLA R package itself to an older, matching version without breaking
compatibility with a current inlabru (2.14.1)?
 
Any pointers on the right binary/package combination for a GLIBC-2.35-only
Ubuntu 22.04 container would be very helpful.
 
Thanks,
Manuel Spinola

[Håvard Rue]

The glibc issue is fixed by installing the ubuntu2204 build,

inla.binary.install()

and chose ubuntu-22.04

please use the recent testing-version of INLA and R-4.6.

the 'stiles' issue is due to different version of the R-INLA and the binary that
it runs, syncronizing these will fix the issue.

let me know if this does not work

best
H

> --
> You received this message because you are subscribed to the Google Groups "R-
> inla discussion group" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to r-inla-discussion...@googlegroups.com.
> To view this discussion, visit
> https://groups.google.com/d/msgid/r-inla-discussion-group/8d306522-0989-4c80-8760-2493f127db1bn%40googlegroups.com
> .

--
Håvard Rue
hr...@r-inla.org

[Finn Lindgren]

Note: Inla.binary.install() is only interactive if “os” isn’t specified, so you _can_ run it non-interactively by specifying a specific build.
Finn

> On 16 Jul 2026, at 16:51, Håvard Rue <hr...@r-inla.org> wrote:
>
> The glibc issue is fixed by installing the ubuntu2204 build,

> You received this message because you are subscribed to the Google Groups "R-inla discussion group" group.

> To unsubscribe from this group and stop receiving emails from it, send an email to r-inla-discussion...@googlegroups.com.

> To view this discussion, visit https://groups.google.com/d/msgid/r-inla-discussion-group/2f808786e37ca8f6b852f323c995856f07118c0b.camel%40r-inla.org.

[Håvard Rue]

the inla.binary.install just download, for ubuntu 2204, from

https://inla.r-inla-download.org/Linux-builds/Ubuntu-22.04.5%20LTS%20%28Jammy%20Jellyfish%29%20x86_64/

and replaces 64bit directory in the installation, like

/home/hrue/R/x86_64-redhat-linux-gnu-library/4.6/INLA/bin/linux/64bit

with the '64bit.tgz' one on the web (unpacked)

the testing version run into an error if an argument to 'inla.binary.install()'
is used (sorry about that). I just fixed it, but a new build needs to wait until
I'm back at KAUST 4th Aug.

as you see, its easy to do manually...

best
H

[Manuel Spínola]

Hi H (and Finn),
Thank you both for the earlier suggestions — they helped us narrow this down to a much more specific problem than where we started.
Where we landed:

For INLA 26.06.08, the Ubuntu-22.04.5 Linux-builds folder only contains the MKL variant (inla.mkl/inla.mkl.run) — there's no plain inla binary for that OS/version combination anymore. So we can't sidestep the MKL binary by pinning a specific Ubuntu-22.04 build.
We tried both MKL_ENABLE_INSTRUCTIONS=SSE4_2 and MKL_CBWR=COMPATIBLE to force MKL onto the most conservative code path (no CPU auto-detection). Neither helped, because the actual failure isn't a CPU-instruction mismatch — it's a hard GLIBC version requirement:

inla.mkl: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.38' not found
Connect Cloud's container only provides GLIBC up to 2.35, so inla.mkl simply can't load there, regardless of any MKL environment variable — this isn't a tunable setting, it's a hard binary dependency.

As a workaround we also tried falling back to the last Ubuntu-20.04.6 build (version 23.05.30-1, May 2023), which does load and run. But it's old enough to predate some of the current INLA .ini format — it fails with section=[INLA.stiles] is not used; please check its type=[STILES] when given a real model from the current R package.

Question: is there any plan to publish a non-MKL build for Ubuntu 22.04 again, or a build compiled against an older GLIBC baseline (compatible with 2.35) for that OS? That would resolve this cleanly. Otherwise, is there a recommended older-but-still-fmesher-compatible Linux build we should be pinning instead of Ubuntu 20.04.6/23.05.30-1?
Happy to share the full deploy logs if useful.
Thanks again for your time on this.
Best,
Manuel

--

Manuel Spínola, Ph.D.
Instituto Internacional en Conservación y Manejo de Vida Silvestre
Universidad Nacional
Apartado 1350-3000
Heredia
COSTA RICA
mspi...@una.cr
mspin...@gmail.com
Teléfono: (506) 8706 - 4662
Sitio web institucional: ICOMVIS

Sitio web personal: Sitio personal

Blog sobre Ciencia de Datos: Blog de Ciencia de Datos

[Håvard Rue]

its compiled against the most recent update of Ubuntu 22.04, sure you're not on
an old version of it?

[Håvard Rue]

or you can compile the binary yourself? i can share the makefile

On Thu, 2026-07-16 at 12:03 -0600, Manuel Spínola wrote:

[Manuel Spínola]

Hi H,

Thanks for the quick reply. One clarification that might matter here: Ubuntu 22.04 (including 22.04.5, the current point release) ships GLIBC 2.35 throughout its entire LTS lifecycle — Ubuntu doesn't bump the GLIBC major version within a release series, only patches within the 2.35.x line. GLIBC 2.38 only appears starting with Ubuntu 23.10. So this isn't a matter of us running an outdated 22.04 — no version of 22.04 will ever have 2.38.
On compiling it ourselves: we'd be glad to try, but Connect Cloud's build environment is fairly locked down (no root access, and we're not sure a C compiler is even available to us there) — so self-compiling as part of our deploy may not be feasible on our end.
Would it be possible for you to build a variant targeting GLIBC 2.35 for Ubuntu 22.04, similar to what's available for Ubuntu 20.04.6? That would let us pin a compatible binary the same way we're already doing for the other build.
Thanks again for the back-and-forth on this.

Best,

Manuel

(I've been working through this debugging process with the help of Claude/Anthropic, in case the level of technical detail here seems unusual for a single afternoon.)

[Håvard Rue]

I checked my ubuntu2204 virt-machine, and it reports version 2.35

can you check again this build,

https://inla.r-inla-download.org/Linux-builds/Ubuntu-22.04.5%20LTS%20%28Jammy%20Jellyfish%29%20x86_64/devel/64bit.tgz

I do not see where GLIBC_2.38 is required.

if this build does not work, then I can try to link without MKL and see if that
helps

let me know...

Best
Havard

[Manuel Spínola]

Hi Havard,
Thanks for building that — unfortunately the devel/64bit.tgz build has the same issue.
First, the folder itself only contains the MKL variant (inla.mkl/inla.mkl.run), same as the versioned Ubuntu-22.04.5 folders — no plain inla binary to sidestep MKL with.
More importantly: inla.mkl from this build still requires GLIBC 2.38, and it's not just the main binary — many of the bundled shared libraries do too (libR.so, libgsl.so.27, libmetis.so.5, libhwloc.so.15, libnuma.so.1, libgfortran.so.5, libreadline.so.8, libgomp.so.1, and others all fail the same way; a couple even ask for 2.36). Full error sample:
inla.mkl: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.38' not found (required by .../inla.mkl)
inla.mkl: /lib/x86_64-linux-gnu/libm.so.6: version `GLIBC_2.38' not found (required by .../libRmath.so)
Given you confirmed your VM reports 2.35, this looks like it might be a build/packaging-machine mismatch rather than a target mismatch — i.e., whatever machine produced this specific devel tarball may have had a newer GLIBC on it (or newer build tools defaulting to a newer baseline) than the Ubuntu 22.04 VM you tested on. Might be worth checking what environment actually built this artifact.
For now we'll keep running on the Ubuntu 20.04.6 (23.05.30-1) binary as a stopgap, even though it predates the current .ini format (the "stiles" section error from before). Let me know if there's anything else worth trying on our end.
Thanks again,
Manuel

[Håvard Rue]

ok, so several of the external libs require higher glibc...

can you try the Rocky-8build? 


https://inla.r-inla-download.org/Linux-builds/Rocky%20Linux-8.10%20%28Green%20Obsidian%29%20x86_64/Version_26.06.08/64bit.tgz


for me, this one runs find on my ubuntu 2204