gRPC + SSL + uber jar + Linux = Failed to load net

Thanks to @nmittler on gRPC + SSL = UnsatisfiedLinkError I've got gRPC + SSL working on my Windows PC and on the target Linux platform.

But only when I specify a <classifier> for the io.netty/netty-tcnative-boringssl-static/1.1.33.Fork17 dependency. That can be:

hard-coded (e.g. to windows-x86_64)
injected using os-maven-plugin and ${os.detected.classifier}

But that means I can only run on:

Windows (or whichever platform I hard-code)
the platform I used to compile

But what I'd really like to be able to do is compile on Windows but run on Linux. So, in theory, I can just leave off the <classifier> to bring in the uber-jar (as specified in the docs).

But this doesn't work: when I step through io.netty.util.internal.NativeLibraryLoader.load() I find a call to System.mapLibraryName().

On Windows this correctly returns netty-tcnative.dll.
But on Linux (RHEL 7) it returns libnetty-tcnative.so ... which isn't in the uber-jar (jar tf netty-tcnative-boringssl-static-1.1.33.Fork17.jar returns, among others, META-INF/native/libnetty-tcnative-linux-x86_64.so).

Looking at the classified linux version of the jar I can see it contains META-INF/native/libnetty-tcnative.so ... which implies either the uber jar needs to be built differently (to rename libnetty-tcnative-linux-x86_64.so to libnetty-tcnative.so) or NativeLibraryLoader somewhere needs to take account of the different naming...

Am I on the right track? Can someone help fix this?

回答1:

You're right, the uber jar on Maven Central does not contain the shared libraries. It's not yet clear whether the issue is building or deploying the jar. I've raised https://github.com/netty/netty-tcnative/issues/145 to track the fix.

回答2:

Upgrading to io.grpc/grpc-all/0.14.0 (from 0.13.2) cured my problem because it brings in a newer version of io.netty/netty-handler (4.1.0.CR7 vs. 4.1.0.CR3).