Since every attempt to produce a compiler for my NAS that can be used to compile the OpenJDK failed, I decided to create a toolchain on the NAS to compile this stuff. The reason for a separate toolchain is that libraries are needed that are used by the running system. Replacing them is a bad idea. Therefore I set up a native toolchain to compile other programs into the running system. Basically this is the same as the first couple of chapters form the Linux from Scratch (Version 6.5) approach, which I used as guidance. The following listing does not produce the desired results but it is never the less a good starting point. (weiterlesen …)
Since the original aim was to have a Java runtime on my NAS I tried this description and failed. Based on the error message I recieved when calling
java -version, I figure that the binaries are not compatible. Therefore I am back to either cross compile or compile a native toolchain to compile on the NAS.
On my way to compile a compiler I must have messed my NAS up. The ipkg install command aborted with
ipkg_download: error: command failed with return value 139: 'wget --passive-ftp - q - P ...'. therefore my first step was to reinstall the bootstrap. Since this needs rebooting after deleting the @optware directory, I detected that port 5000 was not reachable. I first figured it to be some issue with port forwarding of the router. Then I checked the running processes on my NAS. Right you are no httpd process was running that would back the web UI. Therefore the port 5000 and 5001 were not open. Trying to restart with
/usr/syno/etc/rc.d/S97apache-sys.sh start issued also a Segmentation fault. Therefore it suggests itself that some way along my trails some piece of binary code was introduced that resulted in this.
The resolution was that I reset the station, installed the firmware, the bootstrap and subversion again.
This article describes my infutile first attempt to compile a gcc 4 toolchain for my NAS DS 509+. Every step described works, but the endresult are binaries that do not run on my NAS. Never the less, this article may be worthwhile. (weiterlesen …)
While working on a new plugin I tried to reuse components, that already exist.
While testing the plugin froze. You could see it in the debug view by stepping to the reused component. There where no exceptions that tell you anything. Suddenly I had the idea that in the eclipse environment that I started to test the plugin might have something in the error log. Bingo: NoClassDefFoundException. But how could the plugin compile if the resource is not available? The answer is quite simple: I added the needed resource file to the buildpath instead to the plugin dependencies. Therefore at compile time the resource could be found but the plugin knew nothing of the needed resource. When building a plugin never add something needed to the buildpath, add it to the dependencies. Doing this the plugin worked as desired