Man, still no success in getting through the libm4rie build. It ran for 38 hours before I had to get ready to head back to North America (which involved cutting power to the Pi). It looks like the swap (on a connected usb drive) just got so jammed up after a couple hours that the work was happening at a truly glacial pace: cpu usage was basically zero, with 98+% of the cpu time spent 'waiting,' according to top.
So I'm wondering about options for making a more portable Sage, given that we're going to want to build on more kinds of devices in the future. Things I've thought about: a) Is it possible to cross-compile some packages, while leaving tuned pacages like ATLAS to compile on the actual device? This would let us build _most_ of Sage, and then do the remainder on the slow device. b) Would it be reasonable to build a 'lite' version of Sage, with some of the heavier packages left as optional? This would probably involve setting up some extra flags when checking for dependencies in the code.......... maybe terrible for doc-testing, and probably a very large project overall. c) ATLAS has these default settings which one can choose from for different processors with different instruction sets. Is there a place I could harvest/submit the processor profile of the Raspberry Pi for inclusion in ATLAS? I think this is pretty important stuff, as the Pi has sold piles and piles of units; if we can have a Sage binary, it becomes available to every 10-20 year old nerd with $35+ to burn on a new machine.......... I'm personally looking at deploying in rural schools in Western Kenya. Best, -tom On Thursday, December 20, 2012 12:47:53 AM UTC+3, Snark wrote: > > Le 19/12/2012 21:52, tom d a �crit : > > I'm experimenting with building Sage on the Raspberry Pi. It apparently > > has an ARM6 processor, so I'm running from scratch. I ran into problems > > building libm4rie as well (and also on building conversion.c); it would > > start running and then after about 20 minutes the device would freeze up > > and my ssh session (since I'm running headless!) would seize up. Nothing > > I can find in the log files; seems like just a straight out crash. I'm > > trying again from the beginning in case something went wrong earlier in > > the build process. > > Yes, that one file is a problem. > > > ATLAS took 807 minutes to compile on the first attempt. I seem to recall > > hearing that ATLAS has some kind of processor database at some point? I > > poked around looking for whether there's a good way to store the > > timings, etc, and chop down the ATLAS compile time but wasn't > > immediately able to turn any answers up. Anyone have a good idea of > > where to look? > > apt-get install libatlas-dev (or something like this), > then export SAGE_ATLAS_LIB=/usr > that way atlas won't get compiled in sage. > > Snark on #sagemath > -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To post to this group, send email to sage-devel@googlegroups.com. To unsubscribe from this group, send email to sage-devel+unsubscr...@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel?hl=en.
