When running java application it fails loading `libgcc_s.so.1`

[miquelrossello]

Describe the bug

This is the error we're registering on our Spring Boot application:

org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'unleash' defined in class path resource [com/adevinta/msreutapigateway/infrastructure/configuration/InfrastructureConfiguration.class]: Failed to instantiate [io.getunleash.Unleash]: Factory method 'unleash' threw exception with message: /tmp/lib317353590028731244libyggdrasilffi_x86_64-musl.so: Error loading shared library libgcc_s.so.1: No such file or directory (needed by /tmp/lib317353590028731244libyggdrasilffi_x86_64-musl.so)

We've been reviewing and we think you moved to ALPHA version of yggdrasil.

Steps to reproduce the bug

No response

Expected behavior

No response

Logs, error output, etc.

org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'unleash' defined in class path resource [com/adevinta/msreutapigateway/infrastructure/configuration/InfrastructureConfiguration.class]: Failed to instantiate [io.getunleash.Unleash]: Factory method 'unleash' threw exception with message: /tmp/lib317353590028731244libyggdrasilffi_x86_64-musl.so: Error loading shared library libgcc_s.so.1: No such file or directory (needed by /tmp/lib317353590028731244libyggdrasilffi_x86_64-musl.so)

Screenshots

No response

Additional context

No response

Unleash version

10.0.0

Subscription type

None

Hosting type

Self-hosted

SDK information (language and version)

Java 17

[dadadom]

Same here, though without Spring (Boot).

We are using eclipse-temurin:21.0.5_11-jre-alpine as our runtime image.

[sighphyre]

I think we've missed a thing in the docs here, if this is alpine then libgcc needs to be installed on version 10 and above. That should be addable in the docker container with

apk add libgcc

[dadadom]

I think we've missed a thing in the docs here, if this is alpine then libgcc needs to be installed on version 10 and above. That should be addable in the docker container with

apk add libgcc

We are using jib for our application.
Adding a dependency on OS level would require us to switch from a default base image to a self-built image, increasing the complexity of our build process. So far, we managed to run our whole application without any modifications to the alpine based image.

Is there any way to avoid this native, OS level dependency in this Java library?

[cliffcotino]

Similar to @dadadom, this is also an unfortunate additional requirement of the new version of this library.

It goes against the portability of a Java library, so it would indeed be nice if there's a way to avoid this.

[rtc11]

Sorry, but I am using alpine linux in my Docker build. I would rather remove unleash from my gradle dependencies than introduce glibc in my environment.
I now get this error runtime:

java.lang.UnsatisfiedLinkError: /tmp/lib17867888075817098264libyggdrasilffi_x86_64-musl.so: Error loading shared library libgcc_s.so.1: No such file or directory (needed by /tmp/lib17867888075817098264libyggdrasilffi_x86_64-musl.so)
	at java.base/jdk.internal.loader.NativeLibraries.load(Native Method)
	at java.base/jdk.internal.loader.NativeLibraries$NativeLibraryImpl.open(Unknown Source)
	at java.base/jdk.internal.loader.NativeLibraries.loadLibrary(Unknown Source)
	at java.base/jdk.internal.loader.NativeLibraries.loadLibrary(Unknown Source)
	at java.base/java.lang.ClassLoader.loadLibrary(Unknown Source)
	at java.base/java.lang.Runtime.load0(Unknown Source)
	at java.base/java.lang.System.load(Unknown Source)
	at io.getunleash.engine.NativeLoader.loadLibrary(NativeLoader.java:107)
	at io.getunleash.engine.NativeLoader.<clinit>(NativeLoader.java:59)
	at io.getunleash.engine.UnleashFFI.getInstance(NativeLoader.java:48)
	at io.getunleash.engine.UnleashEngine.<init>(UnleashEngine.java:36)
	at io.getunleash.EngineProxyImpl.<init>(EngineProxyImpl.java:35)
	at io.getunleash.DefaultUnleash.defaultToggleRepository(DefaultUnleash.java:36)
	at io.getunleash.DefaultUnleash.<init>(DefaultUnleash.java:40)
        ....

[sighphyre]

Is there any way to avoid this native, OS level dependency in this Java library?

Probably not for the near future no. v9.3.x and below don't rely on this though, you should be able to use those more or less indefinitely if the binaries are a deal breaker

[sighphyre]

Okay I thought about it a bit. I think there might be some things we can do here to remove this native binary. I can't promise timelines though and it needs some investigation to see if it'll work