Build duckdb_java linux-amd64-musl

[hrl20]

Build duckdb_java for Alpine linux on amd64

(arm64 is possible but takes 4+ hours on the default GHA runner, so skipping for now)

[carlopi]

Main question: can we get away from static linking the libc++ ?
I see that working with, question is if we can manage without.

[hrl20]

Main question: can we get away from static linking the libc++ ? I see that working with, question is if we can manage without.

I think in general this will not work because the standard alpine distribution doesn't include these libraries. Not linking it means requiring users to always install them in their Alpine containers when they want to use duckdb. This error happened trying to run duckdb (libstdc++ and libgcc linked) in the standard Metabase container which uses alpine, and loading httpfs (no libstdc++ and libgcc linked).

Also this does mean the extensions need to have statically linked libstdc++ and libgcc. Idk if there's a better solution here.

[carlopi]

But I think the problem here is that v1.1.2 has no concept (yet) of musl.

Would it be possible to run the same workflow again using a recent duckdb commit (such as 09cef57892 the one currently backed in duckdb-java)

[hrl20]

But I think the problem here is that v1.1.2 has no concept (yet) of musl.

Would it be possible to run the same workflow again using a recent duckdb commit (such as 09cef57892 the one currently backed in duckdb-java)

I tried this again on this branch and it still fails /tmp/libduckdb_java14876668067405368824.so: Error loading shared library libstdc++.so.6: No such file or directory (needed by /tmp/libduckdb_java14876668067405368824.so)

[staubt]

Hello
Is it planned to bring that to one of the next releases?
I would like to use duckdb java with an alpine base image.

[staticlibs]

@staubt

Hi, yes, preliminary JDBC v1.3.0.x is going to include the build with musl libc. Though it was found that on some workloads DuckDB on musl may be multiple times slower than DuckDB on glibc, so should be used with caution.

Also, may I ask which JDK build are you considering to use on Alpine, is it glibc-based or musl-based?

[staubt]

Hi
Thanks for the fast answer. The Alpine image I want to use is musl-based.

[carlopi]

@hrl20: I realize my previous comments are void, thanks for the explanation.

[carlopi]

@staticlibs: unsure how to proceed, I think it's more appropriate for you to make a call

[staticlibs]

@hrl20

Thanks for this PR, and sorry for the long waiting time with it! I've incorporated it into #226, the nightly dev version can be used now from the Maven snapshots repo:

    <dependencies>
        <dependency>
            <groupId>org.duckdb</groupId>
            <artifactId>duckdb_jdbc</artifactId>
            <version>1.3.0-SNAPSHOT</version>
	    <classifier>linux_amd64_musl</classifier>
        </dependency>
    <dependencies>
    <repositories>
        <repository>
            <id>oss-sonatype</id>
            <name>oss-sonatype</name>
            <url>https://oss.sonatype.org/content/repositories/snapshots/</url>
            <snapshots>
                <enabled>true</enabled>
            </snapshots>
        </repository>
    </repositories>

Notable changes from the original PR:

• x86_64 and aarch64 builds with musl libc are NOT added to the main "universal" JAR. They are published as standalone arch-specific JARs with classifiers linux_amd64_musl and linux_aarch64_musl
• libstdc++ is NOT linked statically, it is required to run apk add libstdc++ when preparing Alpine containers
• aarch64 build is added the same way as amd64 one, but prebuilt extensions are not yet available for linux_aarch64_musl so it is not very useful right now