[Cross-] compiling applications for SheevaPlug

[porkupan]

Can anyone provide some pointers regarding compiling and linking user applications for the SheevaPlug's standard Ubuntu distribution?

Building applications on the actual target box does seem to work well enough.  It is possible to find and install most libraries via APT, and build using the gcc/g++ on SheevaPlug.  I use the -march=armv5te compiler flag.

However, cross-compiling on i386 Linux doesn't appear to work nearly as well. The Marvell-supplied cross EABI GCC 4.2 doesn't like the Ubuntu libraries, although it seems to be able to link with the shared libraries from the /lib of rootfsv1.0 (the "NFS" rootfs, very basic image/toolchain provided by Marvell mostly for kernel and rootfs flashing).  The problem is, there are very few libraries in rootfsv1.0, and they are not the same as in Ubuntu distro.   The cross linker totally refuses to see the shared libraries copied from the Ubuntu image. 

Any ideas/suggestions would be greatly appreciated.  Or is compiling for SheevaPlug on SheevaPlug the only way to go?

[bzhou]

You can use distcc. Another approach is scratchbox.

Or use one of the cross compilation framework. I'm bias'ed towards optware, basically

Code:

$ cd $HOME         (you can use whatever directory you want, of course)
$ svn co http://svn.nslu2-linux.org/svnroot/optware/trunk optware
$ cd $HOME/optware
$ make cs08q1armel-target
$ cd cs08q1armel
$ make directories ipkg-utils
$ make toolchain
$ make hello-dirclean hello-check

See http://www.nslu2-linux.org/wiki/Optware/AddAPackageToOptware for detail.

[wstupar]

I am having a little trouble getting started with plug computing. I have not been able to compile "hello world" on the Sheeva. There does not seem to be a gcc on it, and there does not seem to be an APT to download one. I realize that I must be missing something basic here...do you have to make a new kernel and download it first using tftpboot?

I would appreciate your kind advice.

Wes

[pushbx]

The easiest way to get gcc on the sheeva plug is to "apt-get build-essential".  GCC is then installed and I had no problems building hello world on the plug.  Message back if you still have problems after apt-get'ting build-essential.

[KostaP]

Can anyone provide some pointers regarding compiling and linking user applications for the SheevaPlug's standard Ubuntu distribution?

Building applications on the actual target box does seem to work well enough.  It is possible to find and install most libraries via APT, and build using the gcc/g++ on SheevaPlug.  I use the -march=armv5te compiler flag.

However, cross-compiling on i386 Linux doesn't appear to work nearly as well. The Marvell-supplied cross EABI GCC 4.2 doesn't like the Ubuntu libraries, although it seems to be able to link with the shared libraries from the /lib of rootfsv1.0 (the "NFS" rootfs, very basic image/toolchain provided by Marvell mostly for kernel and rootfs flashing).  The problem is, there are very few libraries in rootfsv1.0, and they are not the same as in Ubuntu distro.   The cross linker totally refuses to see the shared libraries copied from the Ubuntu image. 

Any ideas/suggestions would be greatly appreciated.  Or is compiling for SheevaPlug on SheevaPlug the only way to go?

Have you tried Scratchbox?
Based on my experience the cross-compilation is not always supported by some software packages. Yes, building kernel using cross tollchain is OK and can save you a lot of compilation time. But this is not always true with others. I would use native build with small packages and Scratchbox for some massive builds.
Basically Marvell supplies optimized CodeSourcery toolchain and instructions for setting up Scratchbox on host PC for some development platforms. I believe the same should be done for SeevaPlug as well. You should be able to setup Scratchbox even without Marvell's optimized toolchain since several CodeSourcery toolchains are freely available on Scratchbox distribution site.
http://www.scratchbox.org/download/scratchbox-apophis/

[wstupar]

Well, I tried apt-get install build-essential, and this is what I got:

The following packages will be upgraded:
  gcc-4.3-base libc6 libgcc1 libstdc++6
4 upgraded, 21 newly installed, 0 to remove and 9 not upgraded.
E: Could not open lock file /var/cache/apt/archives/lock - open (2 No such file
or directory)
E: Unable to lock the download directory

What is the apt archives lock file?

Wes

[bfmorgan]

Have you created the directory /var/cache/apt/archives/partial?

I added this to my rc.local:

Code:

mkdir -p /var/cache/apt/archives/partial

[wstupar]

OK, now I have gcc. Thank you, Mr. Morgan. I had to stumble through the apt-get several times for install, then I had to do an "apt-get update" and then do an install again, but all's well that ends well. BTW, I looked into rc.local and found that the mkdir was already there.

Wes

[donmesserli]

Have you tried Scratchbox?
Based on my experience the cross-compilation is not always supported by some software packages. Yes, building kernel using cross tollchain is OK and can save you a lot of compilation time. But this is not always true with others. I would use native build with small packages and Scratchbox for some massive builds.
Basically Marvell supplies optimized CodeSourcery toolchain and instructions for setting up Scratchbox on host PC for some development platforms. I believe the same should be done for SeevaPlug as well. You should be able to setup Scratchbox even without Marvell's optimized toolchain since several CodeSourcery toolchains are freely available on Scratchbox distribution site.
http://www.scratchbox.org/download/scratchbox-apophis/

Am I asking for trouble if I try to use Scratchbox under Ubuntu 9.04 on the host instead of Debian?

Don

[erdgeist]

I think it is no good idea to compile your programs natively on the SheevaPlug. The flash memory has a finite number of erase-write cycles. And i think an gcc produces much read/write access on the filesystem while it compiles. Maybe the temporary files which occur during a compilation could be putted on a RAM disk.

[DetunizedGravity]

Maybe the temporary files which occur during a compilation could be putted on a RAM disk.

The easiest way to achieve that is to modify your makefiles to make use of the -pipe option for gcc. It makes tools of the build chain use unix pipes instead of temporary files to exchange data. However, this is only efficient is this case if your whole build chain (os + CLI + compiler + temporary data) fits into the physical memory. Otherwise it will translate into swap I/Os and every benefit you could hope for is lost.

So, basically, it is probably better to cross-compile if you intend to compile anything even remotely useful. I agree with Ergeist on that.