Mele: SeaMonkey compiling, and compiling...

Ha ha, what a laugh. In my Mele A1000 ARM box, I am running Ubuntu Lucid Lynx armel. Yesterday I tried, for the first time, to run SeaMonkey.

It aborted at startup with "illegal instruction".

Goodness gracious, this is a Cortex-A8 CPU! My thinking is that whoever compiled SM must have done so on a higher-level CPU and not configured the compile options properly. Or, could they have configured for some instruction in a lower-level CPU that is not in the A8?

So, I decided to compile SM myself, on the Mele. I am doing it on a USB 2.5 inch hard drive, as my SATA drive does not work with the Mele yet.
One partition on the hard drive is for swap, essential as the Mele only has 512MB RAM.

Last night I left it running, went to bed. Got up this morning, it is still compiling.

Man, I would hate to do this on a RasPi! Only 256MB RAM. I would of course use my USB hard drive, with swap partition, so it probably is doable, if you have a few days to spare and don't mind thrashing the hard drive.


Posted on 8 May 2012, 8:37


Comments:

Posted on 8 May 2012, 8:12 by BarryK
SM compile finished
Compile finished! Now I shall make a package.



Posted on 8 May 2012, 19:59 by BarryK
Mele: SM still crashes
The official SM in Ubuntu Lucid is 2.0.4.

I compiled in 2.0.13, created a PET package, tested it in the Mele -- ha ha, still get "illegal instruction".



Posted on 8 May 2012, 20:13 by Dougal
Slow Compilation
This is one of the things that is holding back the Fedora ARM people... as long as they don't have more powerful ARM machines, they can't have fast security updates etc.
You might want to keep that in mind if you plan to do a T2 compile or the like... everything will be much slower than you're used to.


Posted on 8 May 2012, 22:54 by Tony
RAM Disk Drive
Not sure, but can you attach a RAM disk (If available) to a USB port / esata. I know the speed would be limited but it might help.


Posted on 9 May 2012, 7:40 by CLAM01
iS The Future The Past?
Setting up last thing at night and waking up to see if you can use your computer yet, of if it is still loading, compiling, downloading,etc. is the way it was " back in the day..."

And then there was feeding sequences of floppies all night, 360kb, or 750kb double-density... I don' t have any floppy floppies anymore, but I think I still have an old BSD on eighty 750kb dd floppies, if you wan to go further into nostalgia (disclaimer: some of the dd floppies may be damaged from being used to shim wobbly furniture over the years)...


Posted on 9 May 2012, 8:34 by Ted Dog
Hybrid drives
As a combo discount I have a hybrid seagate 2.5 HD that includes a 4G SSD attached to a 500G laptop HD SANA on order for my Mele-A1000.
I wonder if we only use 4G of space, all the speed of SSD for compiling, and later space for my media files.


Posted on 9 May 2012, 8:53 by technosaurus
cross compiling
Speeding up compilation is the reason aboriginal includes distcc by default... you can supposedly use distcc to cross-compile on an x86 with the main gcc running on arm-v6 in qemu (though I haven't figured out the networking part between qemu and puppy). This could be great if you have an x86 with 2gb+ of ram and 4gb+ swap - the extra swap let me do my qt4 and seamonkey compiles in a pfix=ram environment and cut the native x86 compile times in half (yes this is one of the few reasons for having that large of a swap drive/partition/file)


Posted on 9 May 2012, 10:18 by Ted Dog
Aboriginal Pup
I've tried to setup an aboriginal environment, a number of times, but the documentation is lacking, been tempted to drive to his night class in Austin TX with laptop in hand just to get it working once!
If anyone has figured out with puppy linux please start a thread on the forum


Posted on 10 May 2012, 16:27 by Tony
Compiling, minimal Kernel and compressed drive
Pardon my ignorance but if RAM is a limiting factor would it be possible to build a minimal ARM install, no X or anything other than essential drivers, tool chain etc and run the compilation on it from a remote PC.

Also could the spare RAM on the arm be set up as a compressed zram http://en.wikipedia.org/wiki/ZRam (or something like that). Although there would be a performance hit from decompression it might be quicker than disk thrash?