Alpine 3.19 + Java 8: Symbol not found: __xstat64 #7455
Comments
|
Thanks for the report. I think a workaround would be setting |
|
In my case this is workaround is fine as the build is running on a cicd server, so incremental compilation is no issue there. My local environment is already running on java 21, so this is also no problem. But, as far as I can see from the source, the usage of _xstat64() is not correct? Why don't you use stat64() instead? |
Honestly I'm not sure since I did review the change at the time, but did not catch the nuance of the native call that was chosen. If I were to venture a guess this was an attempt to have a stable runtime behavior on Ubuntu by hardcoding to a specific version? I'm also a bit confused since as far as I know sbt has been used inside Alpine before. |
|
The difference is in the different musl libc. Starting with alpine:3.19: I've found some commits mentioning LFS64 specific changes in the musl-libc at alpine, but I don't really understand why it was removed. I'll ask at the irc and post the response here. // Edit: LFS64 support was removed from musl, but alpine decided to add a workaround in older releases. This workaround was removed with alpine:3.19, so the issue arises now. Details why it was removed and why it shouldn't be used in first place can be found here: https://www.openwall.com/lists/musl/2022/09/26/1 |
|
After reading the thread at the musl mailinglist I come to the conclusion that using a non standard-abi like the lfs64 stuff is the root cause of the problem here. So Test application: #include <stdio.h>
#include <sys/stat.h>
int main(void) {
struct stat statbuf;
printf("stat() = %i\n", stat("/etc/os-release", &statbuf));
printf("sizeof(st_ctim) = %zu\n", sizeof(statbuf.st_ctim));
printf("st_ctim.tv_nsec = %li\n", statbuf.st_ctim.tv_nsec);
printf("st_ctim.tv_sec = %li\n", statbuf.st_ctim.tv_sec);
}On alpine x86_64: On alpine x86: On alpine armhf: On Ubuntu 22.04 armv7: On Ubuntu 18.04 x86: So using just Doc: |
|
Sounds good to me. Would you like to send a pull request for this? |
|
PR is open. If you could build me a version of |
**Problem** Ref sbt/sbt#7463 Ref sbt/sbt#7455 On some Linux sbt 1.9.8 fail with "java.lang.UnsatisfiedLinkError: Error looking up function 'stat'". This is due to our workaround another stat related-issue. The general issue is that we currently call native call to retrieve the last modified time because JDK 8 use to have a bug JDK-8177809 that failed to get milliseconds. The bug was fixed in 2021 openjdk8u302. **Solution** We can drop the whole native code mechanism.
**Problem** Ref sbt/sbt#7463 Ref sbt/sbt#7455 On some Linux sbt 1.9.8 fail with "java.lang.UnsatisfiedLinkError: Error looking up function 'stat'". This is due to our workaround another stat related-issue. The general issue is that we currently call native call to retrieve the last modified time because JDK 8 use to have a bug JDK-8177809 that failed to get milliseconds. The bug was fixed in 2021 openjdk8u302. **Solution** We can drop the whole native code mechanism.
steps
Running sbt with java 8 on alpine 3.19 fails due to java.lang.UnsatisfiedLinkError.
Try to invoke sbt when running on alpine 3.19, e.g. using docker:
problem
sbt can't be run when using java 8 and latest musl libc. All invocations fail with the following stacktrace:
expectation
Builds using java 8 on latest alpine release should be possible.
notes
When using Java 11 (
openjdk11-jdk) / Java 17 (openjdk17-jdk) / Java 21 (openjdk21-jdk), everything is fine.When using alpine:3.18, everything is fine too.
The text was updated successfully, but these errors were encountered: