-
Notifications
You must be signed in to change notification settings - Fork 236
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.
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
Alpine images missing fontconfig #529
Comments
@gdams I've not seen the need to symlink libraries in the past on Alpine to get the font support working. Considering how old the linked issue is, ... |
We've left that workaround in our images ever since we encountered that issue. I'll test it over the next few weeks and see if it's still necessary with the newest Docker images. |
@ReillyTevera any luck? |
@karianna I am not OP, but I am also facing issues that were resolved with a workaround mentioned here #75 (comment) I have attached a testframe based on spring-boot (1:1 off of https://start.spring.io/), where I added some code that tries to load an Strangely enough, we dont face this issue with a build from abot 2020-10-* (but I need to refine that from my side, I have no luck reproducing it when pulling the same tag) It is self-contained and only requires this call for testing:
Where this Dockerfile will produce a running application:
Output:
Whereas commenting out
Leads to
|
I was now able to reproduce this as well, here is another testframe demo-gh529-fontConfigProperties.zip When copying
The issue does NOT appear without fontconfig (so vanilla image without
While it breaks with these (and newer images as well)
Also interesting: with that font-config file,
|
Please all forget past experiences. A lot has changed since then, most recently in January. Everything from before then is moot. We unbundled Freetype with the January 2021 updates. Since then, you have to bring your own copy. See https://blog.adoptopenjdk.net/2021/01/adoptopenjdk-8u282-11010-and-1502-available/ for the announcement. https://blog.adoptopenjdk.net/2021/01/prerequisites-for-font-support-in-adoptopenjdk/ lists what's necessary except for Alpine. But you can see the equivalent in https://github.com/AdoptOpenJDK/openjdk-infrastructure/blob/6265fbf2648bd495b1dff903af371897ca7f12e9/ansible/playbooks/AdoptOpenJDK_Unix_Playbook/roles/DockerStatic/Dockerfiles/Dockerfile.alp311#L4-L5. One thing you have to pay attention to: If the JDK was built with glibc, you may not pull in the Alpine packages that are based on musl libc. Otherwise, you end up with the mess I described in #520 (comment). |
Ah okay, understood (I think). Instead of being halfbaked (where some libs would still be missing), images are now blank regarding tools that would be needed for font processing?
IIRC, that musl/glibc incompatibility may occur for anything before jdk16? https://openjdk.java.net/jeps/386 , jdk16 builds and onward are based on musl. And this is not backported to e.g. 8/11, correct? From my understanding, alpine images then need following libs that should be installed by the user, not provided generally?
That seems to be the minimum, based on that article I used FontTest.java:
DockerFile:
Output:
|
From my POV, container images should bring everything needed to run a Java application. This includes freetype, fontconfig, and a couple of fonts. Any image should install libxrender, libxi, libxtst, alsa-lib, libx11, fontconfig, libxext, freetype, zlib, ttf-dejavu.
At the moment, yes.
We have tarballs for musl. Ready-made container images are still based on glibc, for some reason.
8 is unlikely, 11 might be possible, but I'm not aware of any effort to backport JEP 386 to 11. |
Would that also include ready-made images? So future builds would have these libs installed? |
They should, but I'm only the support guy. |
Ah, gotcha. |
Chiming back in, as far as I can tell the linking workaround is no longer necessary with current JDK Alpine images. We were able to remove the symlink commands (while retaining the commands to install I also believe that the base Adoptopenjdk images should be kept as slim as possible with only the required libraries to run the JDK/JVM. If a majority of users do not need font handling then the fontconfig library should be kept out of the adoptopenjdk image and should be installed by any downstream consumer of that image if needed. Side note, @aahlenst are you sure that the JDK images are not linked against musl already? I used |
But what is defined as "required libraries"?. My team is mostly interested in whether or not this is a bug or an intended state. My takeaway so far is that it is intended. Mostly based on the reasoning here: https://blog.adoptopenjdk.net/2021/01/prerequisites-for-font-support-in-adoptopenjdk/ Azul appears to handle it similarily (https://support.azul.com/hc/en-us/articles/360034030692-Using-Fonts-with-OpenJDK-Zulu) while for Corretto also has some open tickets (corretto/corretto-11#118, corretto/corretto-11#124) |
@DRoppelt I would define "required libraries" as "all that the JVM itself requires to be fully functional AND anything required for a basic 'hello world' program to be compiled and ran". Anything beyond that, even if part of the JDKs public API, should be omitted from the image in the interest of keeping it as small as possible. If think it would then be useful if there was a documentation page where "missing" JDK functionality is listed along with the native library that enables it. |
FYI, this is not needed anymore with JDK16 🎉 |
Hm does not look like it to me. Which tag is working for you? Latest JRE&JDK build did not work
FROM adoptopenjdk/openjdk16:alpine as builder
WORKDIR /workspace/app
COPY FontTest.java .
RUN javac FontTest.java
FROM adoptopenjdk/openjdk16:alpine-jre-nightly
#RUN apk add --no-cache fontconfig ttf-dejavu
COPY --from=builder /workspace/app/FontTest.class .
ENTRYPOINT ["java","FontTest"] import java.awt.*;
public class FontTest {
public static void main(String[] args) {
String[] names = GraphicsEnvironment.getLocalGraphicsEnvironment().getAvailableFontFamilyNames();
System.out.println("Found " + names.length + " fonts:");
for (String name : names) {
System.out.println(name);
}
}
} |
Sorry, what I meant was that I no longer need the hack with symlinks to get rid of errors when installing fonts. I don't see you installing any fonts in your |
your main class + this FROM adoptopenjdk/openjdk16:x86_64-alpine-jdk-16.0.1_9
RUN apk add --no-cache fontconfig ttf-dejavu
WORKDIR /workspace/app
COPY src/main/java/FontTest.java .
RUN javac FontTest.java
ENTRYPOINT ["java","FontTest"] gives me:
previously, the installation of the fonts was outputting errors, not "it works" without the symlink hack ... it is still missing the packages, but IMHO that's not bad, important is that simply installing them is enough :) |
I assumed you meant that JDK16 works without anything, so I uncomented the "apk ..." line. Installation without additional symlinks works for all builds since January'21 or so |
Thanks for the conversation folks I think we can close this now |
Hi, even though this is somewhat off-topic, my remarks may be helpful for those who get here searching for this error. in my case, I encountered the problem in a docker image based on
so the same problem is still there in temurin 17 but fortunately it can be solved using the same fix. |
Thanks for your comments here @Remigius2011 I'll raise a PR at https://github.com/adoptium/containers to get this fixed |
@gdams thanks. |
Alpine images need the following command added:
As discussed in #75
The text was updated successfully, but these errors were encountered: