Nixpkgs: Gradle fails to run on 16.03

[a1russell]

Issue description

Can't use gradle on 16.03 stable release. Possibly related to #14454, @Baughn?

Steps to reproduce

1. Run rm -rf ~/.gradle/{caches,daemon,native}
2. Run gradle --stacktrace
3. Get output:

$ gradle --stacktrace

FAILURE: Build failed with an exception.

* What went wrong:
Failed to load native library 'libnative-platform.so' for Linux amd64.

* Try:
Run with --info or --debug option to get more log output.

* Exception is:
net.rubygrapefruit.platform.NativeException: Failed to load native library 'libnative-platform.so' for Linux amd64.
    at net.rubygrapefruit.platform.internal.NativeLibraryLoader.load(NativeLibraryLoader.java:49)
    at net.rubygrapefruit.platform.Native.init(Native.java:55)
    at org.gradle.internal.nativeintegration.services.NativeServices.initialize(NativeServices.java:74)
    at org.gradle.internal.nativeintegration.services.NativeServices.initialize(NativeServices.java:60)
    at org.gradle.launcher.cli.CommandLineActionFactory$WithLogging.execute(CommandLineActionFactory.java:203)
    at org.gradle.launcher.cli.CommandLineActionFactory$WithLogging.execute(CommandLineActionFactory.java:169)
    at org.gradle.launcher.cli.ExceptionReportingAction.execute(ExceptionReportingAction.java:33)
    at org.gradle.launcher.cli.ExceptionReportingAction.execute(ExceptionReportingAction.java:22)
    at org.gradle.launcher.Main.doAction(Main.java:33)
    at org.gradle.launcher.bootstrap.EntryPoint.run(EntryPoint.java:45)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
    at java.lang.reflect.Method.invoke(Method.java:498)
    at org.gradle.launcher.bootstrap.ProcessBootstrap.runNoExit(ProcessBootstrap.java:54)
    at org.gradle.launcher.bootstrap.ProcessBootstrap.run(ProcessBootstrap.java:35)
    at org.gradle.launcher.GradleMain.main(GradleMain.java:23)
Caused by: java.lang.UnsatisfiedLinkError: /home/myuser/.gradle/native/19/linux-amd64/libnative-platform.so: libstdc++.so.6: cannot open shared object file: No such file or directory
    at java.lang.ClassLoader$NativeLibrary.load(Native Method)
    at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1938)
    at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1821)
    at java.lang.Runtime.load0(Runtime.java:809)
    at java.lang.System.load(System.java:1086)
    at net.rubygrapefruit.platform.internal.NativeLibraryLoader.load(NativeLibraryLoader.java:45)
    ... 16 more

Technical details

• System: 16.03.526.567b65d (Emu)
• Nix version: nix-env (Nix) 1.11.2
• Nixpkgs version: "16.03.526.567b65d"

[joachifm]

Possibly fixed by backporting https://github.com/NixOS/nixpkgs/pull/14326
cc @reltuk @Baughn @NeQuissimus

[NeQuissimus]

The backport should fix this issue, correct. I don't think I know the procedure for that. Somebody with committer status could just cherry-pick into 16.03. @joachifm ? :D

[joachifm]

Picked to release at ed2d804d5dbe102e0b33465e8122a08219e9bf88

[joachifm]

Please re-open if the problem persists.

[puffnfresh]

For anyone else having this problem on 16.03: try to rm your ~/.gradle directory. I had some old stuff in there which the Gradle wrapper was picking up.

[mgkimsal]

I hit this issue months ago, and _just_ hit it again today - same box, everything.

removing ~/.gradle doesn't help because the gradle binary doesn't get past initialization to even read ~/.gradle

What i noticed in my case today - I was running gradle from inside a 'screen' session. Exiting out of screen and running from regular terminal - worked like a champ. That may help point someone to a working solution, or bug tracking, or whatever.

[copumpkin]

What actually caused this? I'm seeing this again from a recent nixpkgs

[copumpkin]

I think it might be due in part to https://github.com/NixOS/nixpkgs/commit/6c9c59067b1927f37f02a23d2cbe776d8cb6c1fc having amended the patchelf invocation to use .lib, but not the manual dependency tracker below it.

[copumpkin]

Then again, I'm not using sandboxed builds or stdenvNoCc so that probably isn't it. What's weird is that it worked fine on a CentOS linux box but failed on an Ubuntu one.