fix: detect musl systems through env vars

[samyuh]

Closes #692

[gemini-code-assist]

Summary of Changes

Hello @samyuh, I'm Gemini Code Assist¹! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request refactors the mechanism for identifying Musl-based Linux systems. By transitioning from a file system check to an environment variable-based detection, the change aims to provide a more robust and flexible solution, particularly beneficial for containerized environments. This update enhances the reliability of Musl-specific build configurations.

Highlights

• Musl System Detection Logic: The method for detecting Musl-based systems has been updated to rely on an IS_MUSL environment variable instead of checking for the existence of a specific file (/lib/ld-musl-x86_64.so.1).
• Dockerfile Configuration: The docker/Dockerfile.linux-x86_64-musl has been modified to set the new IS_MUSL=true environment variable, ensuring compatibility with the updated detection logic.
• Improved Error Handling: A warning message has been added to the isX64Musl() method in OSInfo.java to inform users if access to environment variables is restricted due to a SecurityException.

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point in your pull request via creating an issue comment (i.e. comment on the pull request page) using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands.

Feature	Command	Description
Code Review	/gemini review	Performs a code review for the current pull request in its current state.
Pull Request Summary	/gemini summary	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in issue comments and review comments.
Help	/gemini help	Displays a list of available commands.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here.

You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.

Footnotes

1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩

[gemini-code-assist]

Code Review

This pull request updates the detection logic for musl-based systems, switching from a file existence check to an environment variable. This is a positive change for making detection more reliable and configurable. The associated Dockerfile is correctly updated to set this new environment variable. However, I've identified a critical issue in the Java implementation where the system architecture is no longer being verified. This could cause the application to load an incorrect native library on non-x86_64 systems, leading to a runtime crash. My review includes a specific code suggestion to address this problem.

[gemini-code-assist]

The method isX64Musl now only checks for the IS_MUSL environment variable, but it no longer verifies that the architecture is x86_64. This is a regression from the previous file-based check which was specific to x86_64. If IS_MUSL is set to true on a different architecture (e.g., aarch64), getArchName() will incorrectly return "x86_64-musl", leading to an UnsatisfiedLinkError at runtime.

To fix this, the method should also check the system architecture to ensure it's x86_64 when IS_MUSL is true.

        try {
            if ("true".equalsIgnoreCase(System.getenv("IS_MUSL"))) {
                String osArch = System.getProperty("os.arch");
                String lcArch = osArch.toLowerCase(Locale.US);
                return X86_64.equals(archMapping.get(lcArch));
            }
            return false;
        } catch (SecurityException e) {
            System.err.println("WARNING! Access to environment variables or system properties is restricted, not able to detect musl-x86_64.");
            return false;
        }