[GRADLE-2445] File system support does not work on Rasberry Pi Created: 24/Aug/12  Updated: 04/Jan/13  Resolved: 28/Aug/12

Status: Resolved
Project: Gradle
Affects Version/s: 1.1
Fix Version/s: 1.2-rc-1

Type: Improvement
Reporter: Gradle Forums Assignee: Adam Murdoch
Resolution: Fixed Votes: 0


 Description   

So, I can get this far....

pi@raspberrypi ~ $ gradle-1.1/bin/gradle -version
19:53:07.341 [main] DEBUG o.g.l.i.TerminalDetectorFactory - Unable to initialise the native integration for current platform: Linux 3.1.9+ arm. Details: Could not locate JNA native library resource '/com/sun/jna/linux-arm/libjnidispatch.so'.

------------------------------------------------------------
Gradle 1.1
------------------------------------------------------------

Gradle build time: Tuesday, July 31, 2012 1:24:32 PM UTC
Groovy: 1.8.6
Ant: Apache Ant(TM) version 1.8.4 compiled on May 22 2012
Ivy: 2.2.0
JVM: 1.7.0_06 (Oracle Corporation 23.2-b09)
OS: Linux 3.1.9+ arm


Attempting to run any tasks such as "gradle tasks" or start the daemon "gradle --daemon" results in the following error:

FAILURE: Build aborted because of an internal error.

* What went wrong:
Build aborted because of an unexpected internal error. Please file an issue at: http://forums.gradle.org.

* Try:
Run with --debug option to get additional debug info.

* Exception is:
java.lang.ExceptionInInitializerError
at org.gradle.internal.nativeplatform.filesystem.FileSystems$DefaultFileSystem.<clinit>(FileSystems.java:29)
at org.gradle.internal.nativeplatform.filesystem.FileSystems.getDefault(FileSystems.java:22)
at org.gradle.initialization.DefaultCommandLineConverter.convert(DefaultCommandLineConverter.java:94)
at org.gradle.initialization.DefaultCommandLineConverter.convert(DefaultCommandLineConverter.java:35)
at org.gradle.launcher.cli.BuildActionsFactory.createAction(BuildActionsFactory.java:74)
at org.gradle.launcher.cli.CommandLineActionFactory$ParseAndBuildAction.createAction(CommandLineActionFactory.java:205)
at org.gradle.launcher.cli.CommandLineActionFactory$ParseAndBuildAction.execute(CommandLineActionFactory.java:195)
at org.gradle.launcher.cli.CommandLineActionFactory$ParseAndBuildAction.execute(CommandLineActionFactory.java:173)
at org.gradle.launcher.cli.CommandLineActionFactory$WithLogging.execute(CommandLineActionFactory.java:169)
at org.gradle.launcher.cli.CommandLineActionFactory$WithLogging.execute(CommandLineActionFactory.java:138)
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:48)
at org.gradle.launcher.bootstrap.EntryPoint.run(EntryPoint.java:45)
at org.gradle.launcher.Main.main(Main.java:39)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at org.gradle.launcher.bootstrap.ProcessBootstrap.runNoExit(ProcessBootstrap.java:50)
at org.gradle.launcher.bootstrap.ProcessBootstrap.run(ProcessBootstrap.java:32)
at org.gradle.launcher.GradleMain.main(GradleMain.java:26)
Caused by: java.lang.ClassCastException: org.jruby.ext.posix.JavaPOSIX cannot be cast to org.jruby.ext.posix.BaseNativePOSIX
at org.gradle.internal.nativeplatform.filesystem.FileSystemServices.addServices(FileSystemServices.java:64)
at org.gradle.internal.nativeplatform.filesystem.FileSystemServices.<clinit>(FileSystemServices.java:38)
... 22 more

It's the Raspian Wheezy distribution from 08-08-2012, which is a Debian variant.
uname -a provides:
Linux raspberrypi 3.1.9+ #272 PREEMPT Tue Aug 7 22:51:44 BST 2012 armv6l GNU/Linux

A simple check for the return type of the PosixUtil.current() call in the "linux/macosx" section would probably be sufficient. I'm guessing the Linux/Mac libC calls are better for chmod or stat than Java 7, since they are tested first? I may try hand-patching so that the Java 7 test runs first and see how things fare from there.

-Spencer


Generated at Wed Jun 30 12:22:07 CDT 2021 using Jira 8.4.2#804003-sha1:d21414fc212e3af190e92c2d2ac41299b89402cf.