[Breaking change] Glibc version changed in 3.7.1

[alexvasiu]

Version 3.7.1 was build for glibc 2.29+ and version 3.7.0 (and lower) works with glibc lower than 2.29 (e.g. on Amazon Linux)

Exception in thread "main" java.lang.UnsatisfiedLinkError: /mnt/tmp/libh3-java8981121668568062484.so: /lib64/libm.so.6: version `GLIBC_2.29' not found

[isaacbrodsky]

Hi -- what version of Amazon Linux are you using?

I think this is due to not pinning the version of dockcross we use build the Linux binaries for h3-java. We should see if we can pin the version, or if we can specify the target (including libc version) more fully.

[lekkorn]

Why not downward compatible with other versions of glibc?

[alexvasiu]

I was using EMR 5.25.0 with Spark (I think v1 of Amazon Linux, not v2). I was using gradle to include the library in the project.

implementation group: "com.uber", name: "h3", version: "3.7.1"

[isaacbrodsky]

As of #92 we should no longer have unexpected glibc upgrades

[alexvasiu]

@isaacbrodsky Thank you 🚀

[sperka]

Version 3.7.2 shows the same GLIBC_2.29 not found error, both on Amazon Linux 2 (with GLIBC 2.26) and al2022 (with GLIBC 2.34) on arm64.

Downgrading to 3.7.0 helped, no error anymore.

[isaacbrodsky]

@sperka That is very strange because al2022 says it has a much newer version of GLIBC. Indeed, in the linux-arm64 binary I see it seems to require 2.29:

linux-arm64 % nm -a libh3-java.so | grep GLIBC
                 w __cxa_finalize@GLIBC_2.17
                 U __isoc99_sscanf@GLIBC_2.17
                 U acos@GLIBC_2.17
                 U asin@GLIBC_2.17
                 U atan2@GLIBC_2.17
                 U atan@GLIBC_2.17
                 U calloc@GLIBC_2.17
                 U cos@GLIBC_2.17
                 U fmod@GLIBC_2.17
                 U free@GLIBC_2.17
                 U lroundl@GLIBC_2.17
                 U malloc@GLIBC_2.17
                 U memcpy@GLIBC_2.17
                 U memset@GLIBC_2.17
                 U pow@GLIBC_2.29
                 U sin@GLIBC_2.17
                 U sincos@GLIBC_2.17
                 U sprintf@GLIBC_2.17
                 U sqrt@GLIBC_2.17
                 U tan@GLIBC_2.17

is it at all possible the system GLIBC was not being used, perhaps due to a container or something similar?

[sperka]

@isaacbrodsky The code is running on a graviton instance (c6g.metal) using the Amazon Linux 2022.0.20220202 AMI, with corretto 11 and maven 3.8.4, not using docker. 3.7.0 works without error, 3.7.2 errors as mentioned above.

As a sidenote, in contrary, on Mac M1 Max, 3.7.2 works and 3.7.0 fails with an error mentioned in #73