Support systems with both glibc and Musl #661
Conversation
graebm
changed the title
| StringBuilder outputBuilder = new StringBuilder(); | ||
| while ((line = stdOutput.readLine()) != null) { | ||
| outputBuilder.append(line); | ||
| // The system might have both musl and glibc on it: |
There was a problem hiding this comment.
We should add a log or print statement of what was detected. This way, we can easily debug in the future if the wrong library gets loaded.
There was a problem hiding this comment.
Currently, CRT java code logs via our native logger, but we can't use that yet because the C code isn't loaded...
The only place we do System.err.println() is when the CRT has failed to load.
I'm hesitant to print debug-but-not-error info to stderr or stdout. People hate when libraries do that.
I'm just going to 🤷♀️ for now
| // https://github.com/awslabs/aws-crt-java/issues/659 | ||
|
|
||
| // First, check which one java is using. | ||
| // Run: ldd $JAVA_HOME/bin/java |
There was a problem hiding this comment.
$JAVA_HOME and System property can return different values.
| // Run: ldd $JAVA_HOME/bin/java | |
| // Run: ldd System.getProperty("java.home")/bin/java |
There was a problem hiding this comment.
The comment was a hand-wavey allusion to something you could copy paste to your own terminal
I changed it to be less literal by pretty obvious /path/to/java
| // https://github.com/awslabs/aws-crt-java/issues/659 | ||
|
|
||
| // First, check which one java is using. | ||
| // Run: ldd $JAVA_HOME/bin/java |
There was a problem hiding this comment.
Not relevant to this PR, but looking more into how other people are detecting musl vs glibc, this solution will fail if the env doesn't have access to ldd; see facebook/rocksdb#9956. Maybe we should just add an environment override like other people; see dmlc/xgboost#7915, and xerial/sqlite-jdbc#706 (comment). We can add it now, or wait until someone has this issue. Your call.
There was a problem hiding this comment.
Yeah, that's a solid idea. Now user's can do -Daws.crt.libc=musl or -Daws.crt.libc=glibc if our autodetection fails.
I ended up documenting all our System properties in the README, since none of them were documented, and I needed to document the new one somewhere
There was a problem hiding this comment.
And yeah, there are lots of other ways to detect Musl out there, and every PR and stackoverflow has people commenting "this still doesn't work on my machine". We can revisit other ways in the future. Just run them all one after another. But this seems good enough for now...
Co-authored-by: Waqar Ahmed Khan <waahm7@gmail.com>
Issue #: #659
Customer has a system with both glibc and Musl on it. The system is Alpine-based, and uses Musl for most things. But the installed Java is using glibc.
aws-crt-java used to work on this system, back when the shared lib only worked with glibc. But as of v0.23.0 we have different shared libs for glibc and Musl, and need to detect at runtime which to use.
Our current method checks only checks whether the system's built-in libraries use Musl.
Description of changes:
NEW: Let users specify "musl" or "glibc" via system property "aws.crt.libc".
NEW: Otherwise, check whether the current Java executable is using glibc or Musl.
And if those fail, fall back to the previous method of calling
ldd --versionto see if it mentions "musl".Testing:
I tested this by hand. It would be a ton of effort to hook up regular CI for this. Seeing as this is such an edge-case, that feels sufficient.
I didn't touch the compile-time CMake logic, only the runtime logic. So you can't test this without using our released JARs (which have shared libs for every platform), or by preparing a JAR by hand with shared libs for both Musl and glibc. Again, since this is such an edge case, this level of effort seems sufficient.
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.