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

[sighphyre]

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:

Hey @rtc11, I don't know how to ask this without being dismissive, which is 100% not my intent, really just trying to understand so I know I'm moving in the right direction. Bear with me, but is adding a 1.5MB dependency into your container that painful?

[rtc11]

Hey @rtc11, I don't know how to ask this without being dismissive, which is 100% not my intent, really just trying to understand so I know I'm moving in the right direction. Bear with me, but is adding a 1.5MB dependency into your container that painful?

I get your intent! For me it is not only about fixing the problem but also limit the attack surface, maintainability and control over the environment. With larger, more permissive, complex and feature-full stdlib the attack-surface is larger. This is not very convenient in an environment with a lot of transitive dependencies that we hardly have control over.

The other issue is that this happened runtime in production. This is not a unleash porblem, it is a very dangerous practice in general for runtime-dependencies.

I could have containerized the project and then tested the container - but this is both time and resource consuming.

It may be a temporary solution but this also helps pushing the limit for the ecosystem for what is OK.

Hope this make sense!

Edit: I will be using version 9.3.2 until some CVE will "force" me to remove it