116.0.5845.141 build not working on Linux Mint 20.3, but 110.0.5481.78 does
sebkur opened this issue · comments
Thanks for making this project!
I have a small test project set up for trying things out with this library. It's pretty simple, I'm using the native bundle, like so:
dependencies {
implementation 'me.friwi:jcefmaven:110.0.25.1'
implementation 'me.friwi:jcef-natives-linux-amd64:jcef-87476e9+cef-110.0.25+g75b1c96+chromium-110.0.5481.78'
}
then after running ./gradlew clean create, I can do a ./scripts/test-jcef and use the browser!
However, when I change this to:
dependencies {
implementation 'me.friwi:jcefmaven:116.0.19'
implementation 'me.friwi:jcef-natives-linux-amd64:jcef-37f25dc+cef-116.0.19+gc6a20bc+chromium-116.0.5845.141'
}
things no longer work. I get this stack trace:
$ ./scripts/test-jcef
Oct 26, 2023 9:39:58 PM me.friwi.jcefmaven.impl.progress.ConsoleProgressHandler handleProgress
INFO: LOCATING |> In progress...
Oct 26, 2023 9:39:58 PM me.friwi.jcefmaven.impl.progress.ConsoleProgressHandler handleProgress
INFO: EXTRACTING |> In progress...
Oct 26, 2023 9:40:00 PM me.friwi.jcefmaven.impl.progress.ConsoleProgressHandler handleProgress
INFO: INSTALL |> In progress...
Oct 26, 2023 9:40:00 PM me.friwi.jcefmaven.impl.progress.ConsoleProgressHandler handleProgress
INFO: INITIALIZING |> In progress...
Exception in thread "main" java.lang.UnsatisfiedLinkError: /home/user/github/sebkur/test-jcef/jcef-bundle/libjcef.so: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.32' not found (required by /home/user/github/sebkur/test-jcef/jcef-bundle/li
bjcef.so)
at java.base/jdk.internal.loader.NativeLibraries.load(Native Method)
at java.base/jdk.internal.loader.NativeLibraries$NativeLibraryImpl.open(NativeLibraries.java:388)
at java.base/jdk.internal.loader.NativeLibraries.loadLibrary(NativeLibraries.java:232)
at java.base/jdk.internal.loader.NativeLibraries.loadLibrary(NativeLibraries.java:174)
at java.base/java.lang.ClassLoader.loadLibrary(ClassLoader.java:2389)
at java.base/java.lang.Runtime.load0(Runtime.java:755)
at java.base/java.lang.System.load(System.java:1953)
at me.friwi.jcefmaven.impl.step.init.CefInitializer.initialize(CefInitializer.java:57)
at me.friwi.jcefmaven.CefAppBuilder.build(CefAppBuilder.java:308)
at de.topobyte.jcef.TestJcef.<init>(TestJcef.java:110)
at de.topobyte.jcef.TestJcef.main(TestJcef.java:251)
When looking for other issues online, I thought I had found a similar issue reported before, but could not find it, so I'm filing this issue here now.
An obvious solution is to upgrade my system from Mint 20.3 (which is based on Ubuntu 20.04 LTS) to Mint 21.2 (which is based on Ubuntu 22.04 LTS). However, when I want to build an application using jcefmaven, I'll only be able to support Ubuntu 22.04 upwards and its derivatives. That's a pity as Ubuntu 20.04 and Mint 20.3 are LTS releases and will still get standard support until mid 2025 (and even extended support until 2030), so dismissing all users on those seems a bit harsh.
I think it's probably configured somewhere and somehow which version of GLIBC this is linked to. I'm not sure if it's explicitly set anywhere or implicit by the system this gets built on. So maybe a solution for supporting older systems would be building on Debian bullseye instead of Debian bookworm. As far as I can tell, glibc is backwards compatible, i.e. it won't be a problem for systems to have a newer glibc than the one this is compiled for, but the other way around it is a problem.
Do you have any idea where the version of glibc is configured and if there's an easy way for you to change this?
Hey, thank you for all this input. Sadly I think that the underlying binaries from spotify are already built with the newer glibc versions. I also switched to the newer debian versions due to glibc errors while compiling, so I dont think a downgrade would work out. Sadly this is generally a problem with debian based distributions locking on certain versions of the toolchain. Maybe you can try forking jcefbuild and to downgrade debian again for a build or to configure a glibc version to be compatible with for a build. If you manage to, I can surely integrate the change to support those older debian versions too.
Sadly I think that the underlying binaries from spotify are already built with the newer glibc versions
Oh, aha, how's spotify involved with this? Do you repackage their binaries somehow? I was under the assumption you're building the binaries yourself...
Maybe you can try forking jcefbuild and to downgrade debian again for a build or to configure a glibc version to be compatible with for a build
OK sounds good, I'll give that a try. Already forked it and let the Github CI build a release. That works (and doesn't run on my machine giving the same error). So it looks like I can start poking around with the config and see if I can come up with a solution. Thanks so far!
I've been able to build successfully using a Debian Bullseye image. This is my config: sebkur/jcefbuild@996bb31
Found the connection to Spotify - didn't realize they maintain the CEF builds and then JCEF adds a bit on top of those existing builds. Anyway it looks like they also build with a older libc, their binaries are compatible with Ubuntu 20.04. It's only libjcef.so that's not compatible currently.
Alright, I've updated the jcefdocker image that I use for building to use debian bullseye instead and your build configuration. I hope that it will work for a build of the next jcefmaven version :)
@sebkur A build with the adapted glibc version is now published as version 116.0.19.1. Please make sure to test and report back whether it is working :)
Thanks a lot!
When I use the method where jcefmaven downloads the jcef-bundle at runtime, things do work now.
When I used it in combination with the jcef-natives-linux-amd64 dependency (me.friwi:jcef-natives-linux-amd64:jcef-37f25dc+cef-116.0.19+gc6a20bc+chromium-116.0.5845.141), I still get the exception, but that's expected I think. Probably a new release of the natives artifact is necessary too?
Yes, that is to be expected as I cant publish another build of the chromium binaries to the central maven repo due to the versioning schemes of the natives. I can however publish a new release on github which is what jcefmaven primarily tries to download. Starting from the next version of jcef you can use the natives again as you were used to. I will close this for now, thanks for your help and suggestion :)
Great. Thank you very much, too!