Zen engine works locally when using Mac , but Fails on the CI pipeline during build

[dabluswiffy]

Hi, I started using the zen engine for one of our use case.
I use the below maven bundle in java for building my application.
<!-- GoRules ZEN Engine --> <dependency> <groupId>io.gorules</groupId> <artifactId>zen-engine</artifactId> <version>0.7.2</version> </dependency>

Everything worked well on local but failed when we deployed our code on Azure.
It failed with the issue
java.lang.ExceptionInInitializerError: Exception java.lang.UnsatisfiedLinkError: /lib/x86_64-linux-gnu/libm.so.6: version GLIBC_2.35' not found (required by /root/.cache/JNA/temp/jna13898457806617768842.tmp) [in thread "http-nio-auto-1-exec-3"]
at com.sun.jna.Native.open(Native Method)
at com.sun.jna.NativeLibrary.loadLibrary(NativeLibrary.java:298)
at com.sun.jna.NativeLibrary.getInstance(NativeLibrary.java:483)
at com.sun.jna.Library$Handler.(Library.java:197)
at com.sun.jna.Native.load(Native.java:622)
at com.sun.jna.Native.load(Native.java:596)
at io.gorules.zen_engine.NamespaceLibrary.loadIndirect(NamespaceLibrary.java:17)
at io.gorules.zen_engine.UniffiLibInitializer.load(UniffiLibInitializer.java:9)
at io.gorules.zen_engine.UniffiLib.(UniffiLib.java:10)
at io.gorules.zen_engine.ZenEngine.lambda$new$0(ZenEngine.java:38)
at io.gorules.zen_engine.UniffiHelpers.uniffiRustCallWithError(UniffiHelpers.java:16)
at io.gorules.zen_engine.UniffiHelpers.uniffiRustCall(UniffiHelpers.java:50)
at io.gorules.zen_engine.ZenEngine.(ZenEngine.java:37)
at com.swiffylabs.cortex.adapter.gorules.ZenEngineRuleEvaluator.evaluateWithTrace(ZenEngineRuleEvaluator.java:32)
at com.swiffylabs.cortex.domain.service.impl.RuleExecutionServiceImpl.execute(RuleExecutionServiceImpl.java:76)
at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103)
at java.base/java.lang.reflect.Method.invoke(Method.java:580)
at org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:360)
at org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:196)
at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:163)
at org.springframework.transaction.interceptor.TransactionAspectSupport.invokeWithinTransaction(TransactionAspectSupport.java:380)
at org.springframework.transaction.interceptor.TransactionInterceptor.invoke(TransactionInterceptor.java:119)
at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:184)
at org.springframework.aop.framework.CglibAopProxy$DynamicAdvisedInterceptor.intercept(CglibAopProxy.java:728)
at com.swiffylabs.cortex.domain.service.impl.RuleExecutionServiceImpl$$SpringCGLIB$$0.execute()
at com.swiffylabs.cortex.core.handler.http.RuleExecutionController.execute(RuleExecutionController.java:22)
at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103)
`

After reading about it , we got to know that

GLIBC (GNU C Library) is the core C library on Linux. It provides fundamental system functions — file I/O, memory allocation, threading, networking, etc. Every native binary on Linux
depends on it. It's like the foundation layer between your code and the Linux kernel.

Why it fails on CI but not on macOS

• macOS doesn't use GLIBC at all — it uses Apple's libSystem.dylib. So GLIBC version is irrelevant locally.
• The zen-engine:0.7.2 jar bundles a pre-compiled native library (linux-x86-64/libzen_uniffi.so) built with Rust. That .so file was compiled against a specific GLIBC version (likely
  2.39).
• Your CI Ubuntu image has an older GLIBC (e.g., Ubuntu
  20.04 has GLIBC 2.31, Ubuntu 22.04 has GLIBC 2.35).
• GLIBC is forward-compatible but NOT backward-compatible — a binary built against GLIBC
  2.39 cannot run on a system with GLIBC 2.35.

How to fix (without code changes)

You have 3 options:

1. Upgrade the CI Ubuntu image to one with GLIBC ≥
   2.39 (Ubuntu 24.04 has GLIBC 2.39)
2. Downgrade zen-engine to an older version that was compiled against an older GLIBC
3. Use an older zen-engine native binary — check if GoRules provides builds targeting older GLIBC versions (e.g., musl-based builds)

Now I can choose option 1 but if there are cases where I am not able to upgrade the ubuntu image , as my software could be deployed on On premise client application , is there a possibility of option 2 , or anything else which we are not aware