8000 When running java application it fails loading `libgcc_s.so.1` · Issue #275 · Unleash/unleash-client-java · GitHub
[go: up one dir, main page]
Skip to content

When running java application it fails loading libgcc_s.so.1 #275

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Open
miquelrossello opened this issue Feb 3, 2025 · 12 comments
Open

When running java application it fails loading libgcc_s.so.1 #275

miquelrossello opened this issue Feb 3, 2025 · 12 comments
Assignees
@sighphyre
Labels
bug

Comments

@miquelrossello
Copy link

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
Copy link
dadadom commented Feb 3, 2025

Same here, though without Spring (Boot).

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

@miquelrossello miquelrossello changed the title When running java application this fails loading shared library When running java application it fails loading shared library Feb 3, 2025
@miquelrossello miquelrossello changed the title When running java application it fails loading shared library When running java application it fails loading libgcc_s.so.1 Feb 3, 2025
@FredrikOseberg FredrikOseberg moved this from New to Investigating in Issues and PRs Feb 4, 2025
@sighphyre
Copy link
Member

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

@sighphyre sighphyre self-assigned this Feb 4, 2025
@dadadom
Copy link
dadadom commented Feb 4, 2025

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
Copy link

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 8000 would indeed be nice if there's a way to avoid this.

@rtc11
Copy link
rtc11 commented Feb 13, 2025

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
Copy link
Member

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
Copy link
Member

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
Copy link
Member

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
Copy link
rtc11 commented Feb 14, 2025 •
edited
Loading

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

@sighphyre
Copy link
Member

Thanks for the response @rtc11, yeah that makes sense. 9.3.2 should be okay for a while. I'll carve out some time to see what I can do about this next week with a bit of luck

@chriswk chriswk removed their assignment Feb 25, 2025
A267
@sighphyre sighphyre moved this from Investigating to Todo in Issues and PRs Mar 4, 2025
@sighphyre
Copy link
Member

Hey folks, so we've heard quite a lot of feedback on the new binary embedded in the jar. We've taken this seriously and we're trying our best to make a plan here. While we can't free ourselves from this binary completely, what we can do is embed a WASM version of this that runs on a pure Java WASM runtime. We're currently experimenting with that now. In theory that should address some of the security and portability concerns. We'd love some feedback on this approach if anyone is willing to share

@cliffcotino
Copy link

I've since moved on to a different project/company, so I have less skin in the game currently so to say.
Did you also consider the approach that Netty takes where they make jars available with native libraries included?

Personally I would still trend more towards the OpenFeature Unleash provider for the use-case we were using unleash for instead of this additional Java WASM / libgcc requirement.

(we noticed that there was an unleash provider available already: https://github.com/open-feature/java-sdk-contrib/tree/main/providers/unleash)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@sighphyre sighphyre

Labels
bug
Projects
Issues and PRs
Status: Todo
Milestone
No milestone
Development

No branches or pull requests
6 participants
@chriswk @rtc11 @dadadom @cliffcotino @sighphyre @miquelrossello
0