quarkus: native image fails to start due to missing libfreetype.so.6 library

Describe the bug

Running a quarkus native application (2.5.0.Final) fails with following error at startup:

./application: error while loading shared libraries: libfreetype.so.6: cannot open shared object file: No such file or directory

With 2.4.2.Final it was working correctly

Expected behavior

The application should just start.

Actual behavior

The application can not start.

In the application.properties we have following settings for the native build:

quarkus.jib.base-native-image=quay.io/quarkus/quarkus-micro-image:1.0
quarkus.native.additional-build-args=\
  -J--add-exports=java.security.jgss/sun.security.krb5=ALL-UNNAMED

as build image we use quay.io/quarkus/ubi-quarkus-native-image:21.3-java17

and the build.gradle has following dependendies:

plugins {
    id 'java'
    id 'io.quarkus'
    id 'com.github.ben-manes.versions'
}

dependencies {
    implementation enforcedPlatform("${quarkusPlatformGroupId}:${quarkusPlatformArtifactId}:${quarkusPlatformVersion}")

    implementation 'io.quarkus:quarkus-jdbc-postgresql'
    implementation 'io.quarkus:quarkus-container-image-jib'
    implementation 'io.quarkus:quarkus-smallrye-openapi'
    implementation 'io.quarkus:quarkus-smallrye-health'
    implementation 'io.quarkus:quarkus-hibernate-orm-panache'
    implementation 'io.quarkus:quarkus-resteasy'
    implementation 'io.quarkus:quarkus-resteasy-jackson'
    implementation 'io.quarkus:quarkus-rest-client'
    implementation 'io.quarkus:quarkus-rest-client-jackson'
    implementation 'io.quarkus:quarkus-liquibase'
    implementation 'io.quarkus:quarkus-arc'
    implementation 'io.quarkus:quarkus-micrometer-registry-prometheus'
    implementation 'io.quarkus:quarkus-scheduler'

    implementation 'org.apache.commons:commons-lang3'
    implementation 'io.quarkiverse.hibernatetypes:quarkus-hibernate-types:0.2.0'

    compileOnly "org.projectlombok:lombok:$lombokVersion"
    annotationProcessor "org.projectlombok:lombok:$lombokVersion"
    testCompileOnly "org.projectlombok:lombok:$lombokVersion"
    testAnnotationProcessor "org.projectlombok:lombok:$lombokVersion"

    compileOnly 'org.osgi:osgi.annotation:8.0.1'
    testCompileOnly 'org.osgi:osgi.annotation:8.0.1'

    testImplementation 'at.favre.lib:bcrypt:0.9.0'
    testImplementation 'io.quarkus:quarkus-junit5'
    testImplementation 'io.rest-assured:rest-assured'
}

group 'com.qumea'

java {
    sourceCompatibility = JavaVersion.VERSION_17
    targetCompatibility = JavaVersion.VERSION_17
}

quarkusDev {
    workingDir = rootProject.projectDir
}

compileJava {
    options.encoding = 'UTF-8'
    options.compilerArgs << '-parameters'
    options.compilerArgs << '-Xlint:all'
    options.compilerArgs << '-Xlint:-exports'
    options.compilerArgs << '-Xlint:-requires-automatic'
    options.compilerArgs << '-Xlint:-processing'
    options.deprecation = true
}

compileTestJava {
    options.encoding = 'UTF-8'
}

quarkusBuild {
    nativeArgs {
        containerBuild = System.env.BITBUCKET_BRANCH == null
        builderImage = "quay.io/quarkus/ubi-quarkus-native-image:21.3-java17"
    }
}

How to Reproduce?

No response

Output of uname -a or ver

No response

Output of java -version

Java 17.0.1

GraalVM version (if different from Java)

quay.io/quarkus/ubi-quarkus-native-image:21.3-java17

Quarkus version or git rev

2.5.0.Final

Build tool (ie. output of mvnw --version or gradlew --version)

Gradle 7.3

Additional information

No response

About this issue

  • Original URL
  • State: closed
  • Created 3 years ago
  • Comments: 15 (10 by maintainers)

Commits related to this issue

Most upvoted comments

@wabrit @vladimirfx The fix in #20850 is pretty close to getting merged now 👍

Yes, that’s probably it. So, the approach would be to extend the runtime image to add the lib. Something like https://github.com/quarkusio/quarkus-quickstarts/blob/development/awt-graphics-rest-quickstart/src/main/docker/Dockerfile.native-distroless.

We should document that.

Checked on 2.6.0.CR1 - works fine. Thank you!

Thanks, I will check today

Workaround is build your own base image with needed libs. Actually is what we do in our company. And yes, for applications that not using fonts or other graphics elements it is just annoying.