Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Invoke protoc in a way that works on NixOS Linux #108

Open
raboof opened this issue Sep 23, 2022 · 3 comments
Open

Invoke protoc in a way that works on NixOS Linux #108

raboof opened this issue Sep 23, 2022 · 3 comments

Comments

@raboof
Copy link

raboof commented Sep 23, 2022

Is your feature request related to a problem? Please describe.

When protobuf-maven-plugin downloads a protoc binary, that binary expects the ELF interpreter to exist at /lib64/ld-linux-x86-64.so.2 . Unfortunately, on NixOS, /lib64/ld-linux-x86-64.so.2 does not exist, because different applications are allowed to use different versions of the loader. This means invoking the protoc compiler fails.

Describe the solution you'd like

I would like the maven plugin to detect the NIX_CC environment variable on Linux, and when it exists, explicitly invoke $NIX_CC/nix-support/dynamic-linker to load the protoc binary. This is the solution/workaround used by protoc-bridge as well.

Describe alternatives you've considered

  • NixOS comes with packaged protoc binaries in various versions, so one solution could be to ask users to not have the protobuf maven plugin download the protoc binary, but use the system-installed one. This is inconvenient, however - the protobuf-maven-plugin feature to download the correct protoc binary version is very useful.
  • We could ask NixOS users to use the patchelf utility to fix up the downloaded binary. This is inconvenient, since it is somewhat obscure, and would need to be repeated each time the target directory is cleared

Additional context
I understand this is something rather obscure. If you don't have objections againt the approach I'm happy to provide a PR implementing it.

@yswtrue
Copy link

yswtrue commented Feb 8, 2023

Same here.

@ptrcnull
Copy link

ptrcnull commented Apr 5, 2023

same happens on Alpine Linux, which doesn't have glibc:

Caused by: java.io.IOException: Cannot run program "target/protoc-plugins/protoc-3.19.2-linux-x86_64.exe": error=2, No such file or directory
    at java.lang.ProcessBuilder.start (ProcessBuilder.java:1143)
    at java.lang.ProcessBuilder.start (ProcessBuilder.java:1073)
    at java.lang.Runtime.exec (Runtime.java:594)
    at org.codehaus.plexus.util.cli.Commandline.execute (Commandline.java:660)
    at org.codehaus.plexus.util.cli.CommandLineUtils.executeCommandLineAsCallable (CommandLineUtils.java:136)
    at org.codehaus.plexus.util.cli.CommandLineUtils.executeCommandLine (CommandLineUtils.java:106)
    at org.codehaus.plexus.util.cli.CommandLineUtils.executeCommandLine (CommandLineUtils.java:89)
    at org.xolstice.maven.plugin.protobuf.Protoc.execute (Protoc.java:242)

is there a workaround that uses system protoc?

@jkulubya
Copy link

jkulubya commented Jul 7, 2023

I got it running like so. I'm not a java buff, but the key is setting protoExecutable to the protoc you'd like to use. In the nix case, just whatever is available on the path

<plugin>
                <groupId>org.xolstice.maven.plugins</groupId>
                <artifactId>protobuf-maven-plugin</artifactId>
                <version>0.6.1</version>
                <executions>
                    <execution>
                        <goals>
                            <goal>compile</goal>
                            <goal>test-compile</goal>
                        </goals>
                    </execution>
                </executions>
                <configuration>
                    <protocExecutable>protoc</protocExecutable>
                    <protocArtifact>com.google.protobuf:protoc:3.22.0:exe:${os.detected.classifier}</protocArtifact>
                </configuration>
            </plugin>

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

No branches or pull requests

4 participants