Cross-compiling for DroboFS: nano 2.2.5


Hi everyone,

Here is another post on the cross-compile series for DroboFS.

Introduction: Why nano?

I like it better than vi. Oh yeah, I said it. :slight_smile:

Overall compiling complexity: Easy.

Step 1: Background info

To be able to make use of this post, you need a VM configured as indicated in this post.

Step 2: Enter the cross-compiling environment

See step 2 of this post to see instructions on how to enter the chroot environment.

Step 3: Dependencies

nano needs:

Step 4: Get the source code

nano’s website: http://www.nano-editor.org/
Version: 2.2.5
Direct link: http://www.nano-editor.org/dist/v2.2/nano-2.2.5.tar.gz

Make sure that you are in the folder /root/code, then type:

wget http://www.nano-editor.org/dist/v2.2/nano-2.2.5.tar.gz tar zxf nano-2.2.5.tar.gz cd nano-2.2.5

Step 5: Configuration

Before configuring, a little change has to be made in the include folders:

ln -s /usr/arm/include/ncurses/ncurses.h /usr/arm/include/

If you do not create this soft link, the compilation will fail because it will not find the ncurses.h file.

The traditional configure command applies:

./configure --host=arm-none-linux-gnueabi --prefix=/usr/arm

This should return no errors. If it does, you have to check if you have all required packages in your chroot (although, if you have been following the dependencies, you should have all of them).

Step 6: Compiling

Within the folder /root/code/nano-2.2.5:


Again, there should be no errors. If any errors are reported, make sure you performed steps 3, 4 and 5 correctly. If you still have errors, make sure that the VM is properly configured (e.g. like I did the first time around, when I got the wrong toolchain, or forgot to ‘export’ the proper compiler flags).

Step 6: Installing

As simple as it gets:

make install

…which will place the compiled library under /usr/arm.

Then we package the whole /usr/arm and copy it over to the DroboFS, as indicated on step 9 here.


Now you can run nano on your DroboFS. Enjoy the freedom from vi!


I tried using your port of nano over on DroboPorts, and while it installed properly, it doesn’t seem anything is including it in paths. For instance, the binary isn’t in the shell path, the libraries aren’t located, etc. I’ve noticed this with a few apps, where everything is in place on the DroboApps share, but don’t seem to end up in the proper system paths.

What’s the “correct” way of dealing with this?


Well, it depends on which shell you are using. Since this depends on your environment, I left it as an ‘exercise to the reader’.

But the simplest way is just to create a file called “.profile” (without the quotes, but with the initial dot) in the folder /mnt/DroboFS. Let’s say you have bash and curl installed, and you want them to be on your path. The .profile will look like this:

export APPS=/mnt/DroboFS/Shares/DroboApps
export PATH=$PATH:$APPS/bash/bin:$APPS/curl/bin

Explanation: the PATH variable contains all the folders that you want to be searched when you type a command name. The LD_LIBRARY_PATH variable contains all the folders in which to look for libraries.

So, for each one of the “command-line DroboApps” you have to manually add their respective bin and lib folders to these two variables.

It is possible to script something that would automate this, but all of them involve messing with “.profile”… which is kind of frowned upon by the Linux community, since that file is supposed to be managed by each user.

The other way, which is even uglier, is to script all CLI DroboApps to automatically symlink all their executables and libraries in the traditional folders, such as /usr/bin and /usr/lib. But that can potentially overwrite the FS internal libraries, and I won’t touch that even with a 20-feet pole. :slight_smile:


I’m curious then - how do the DRI-supplied apps work (since they can’t depend on the user having shell access to set things like that up, but they still need to ensure their libraries and support files are usable)?

In the meantime, I have no problem editing profile - I just thought there had to be a more elegant method.


For stuff that is a “full app”, like fuppes, there are two options:

  1. you compile the app as static, i.e., basically build a gigantic binary containing all the code for all the libraries. If the app is small, and has just a couple dependencies, that is ok. For bigger apps a static build kind of sucks, since the FS does not have that much RAM. Since everything depends on the daemon executable, there is no need for PATH.

  2. you make the service.sh script set these variables up. You can see that on the apache app from DRI. Once started, the daemon takes over the variables as set in the service.sh, and that is it.

But if you look at something like the rsync app, you’ll see that they don’t do anything to put the rsync binary on the PATH. If you want to use it, you have to either add it to your .profile or link it somewhere in the PATH.


In that case, I set up .profile to loop through all of the apps and set them up. Less maintenance. :slight_smile:

# Add all DroboApps to the proper environment variables for APP in /mnt/DroboFS/Shares/DroboApps/* do if [ -d "$APP/bin" ]; then export PATH=$PATH:$APP/bin fi if [ -d "$APP/lib" ]; then export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:$APP/lib fi done


Hmm… you know, you gave me an idea for a DroboApp.

How about a DroboApp that would:

  1. fix the /etc/passwd being reset problem
  2. add little scripts like the one you made
  3. have some primitive support for a packaging system

Item (1) would require the DroboApp to make a copy of the current /etc/passwd and replace it on boot (it may be even simpler than that, but I won’t speculate before actually trying on my FS).

Item (2) would be open to community contributions. Your script is a great example of that.

Item (3) could be implemented using a simple script grabbing info from DroboPorts, for example.

We could call it “Real Linux” or something. :stuck_out_tongue:

What do you say?


Well I love the idea, but I’m biased. :wink: I wish there were a real package management system, as I’d love to see a metapackage of “Real Linux”, which included all of the subpackages. That way if you really wanted to get just certain aspects you could.

But I’m probably getting ahead of ourselves.