Thank you, Michael, for the information that the binaries of sagemath contain linux-distribution-specific binary files.
(After reading that, I continued on the basis that only compile-from- source will get sagemath running on Mandriva in the absence of a specific pre-compiled product.) I've now managed to compile it on Mandriva linux. Here are some basic details that could be of some use to others (especially, there are signs that the documentation needs some updates, which would help others trying to do the compile from source). Based on the previous trial and failure, I went to another desktop machine (Pentium-3, Mandriva, 384MB RAM) (i.e. the same cpu as the target laptop on which the operation had failed with shortage of RAM). Before beginning, I fixed this machine up with extra swap- partition space, plus a destination for the compile, a separate partition symlinked to the user home directory (to make it easier to monitor size and location of the compiled product). To avoid unnecessary RAM consumption, I also started the compile from a text console when no X-windows was running (and also no other application s/ w running at all). Under these conditions, the compile did work on the 384 MB RAM machine. The heaviest (c++) memory usage was (again) on linboxwrap (this was the package on which the previous compile attempt on a 256 MB machine broke down). But even on linboxwrap, the memory usage was no more than 66% of the available RAM. So it looks as if the marginal RAM requirement there can't be more than about 256MB, and '1GB RAM' should not be needed. (A big difference from last time was that the successful compilation process made no use at all of any swap partition space. Last time, the usage of swap space as well as the RAM memory (512MB in total) became saturated, in what looked suspiciously like a memory-leak breakdown. In view of the compile conditions that worked, it might seem that 512MB in total of RAM and swap should have been enough if the swap space was being used effectively. During the successful compile, there was an surprisingly large amount of memory cacheing --- but if this included any memory leaks, the RAM now was just about big enough to absorb it directly without overload or attempts to swap to disk. Memory management therefore seems suspect in this whole process: maybe it could indicate an intrinsic problem with the c++ compiler, or maybe it could be triggered by pathological source input to the compiler -- plenty of invalid compiler directives for example.) Minimum free RAM during compilation reduced to a little under 5MB at peak usage times. So it looks as if 384MB RAM in total was only just enough. Some of the processes associated with the compilation were seen to be running with root privileges, even though the ordinary user launched the compile rocess. Specific examples were the msec.py and Perms.py scripts. This appears to raise a question about user-area restriction of the results of the compile process. The disk usage of the partition with the products of compilation rose from 195MB (the tar file alone before compilation) to 1.5GB with the compilation products afterwards. This is a much bigger compilation product than the 850 MB free space advised/assumed in the documentation. After following the instruction in the documentation to issue 'make clean' afterwards, only about 8 MB was cleared, not 400MB. On this occasion, it was satisfactory that no significant bulk of file- writing occurred outside the intended compile-destination area, except in /var/log. (The results of the previous failed compile attempt remain to be investigated: maybe breakdown of memory management was associated with unpredictable effects.) The compile was started after an attempt to make sure that necessary s/ w packages mentioned in the documentation were all present and correct. But the compile process still issued error messages, to say that 'makeinfo' 4.7 or better is required, and was missing, and that without it, the R s/w documentation is not converted to html. This makeinfo was not mentioned in the list given in the documentation. I now find that it is part of the 'texinfo' package, which I did not have installed, but would have installed it if the hint had been there in the documentation. So the compile is not yet quite complete, until I find a way to perform this missing task. It would be helpful to add this item to the list mentioned in the documentation. This compilation product has been passing all of the tests described in the documentation and nearly all of those run with ' -testall ' except that: .../calculus/calculus.py and .../graphs/graph.py timed out, and the .../dsage/tests/testdoc.py and related tests were skipped -- (was this because of the missing makeinfo?) -- and .../sage/ plot/plot.py also failed. Some of the messages I received on here yesterday indicated, that up to now there was no binary compilation product available for Mandriva linux. If anybody else would like to have these files compiled for Mandriva linux I'd be glad to pass mine on. (There was mention in some of the messages, of using VMware to assemble a Mandriva compilation product. Sorry, but I don't know anything of VMware beyond its name.) regards Terry On Apr 17, 12:25 am, mabshoff <[EMAIL PROTECTED] dortmund.de> wrote: > On Apr 16, 9:01 pm, terry-s <[EMAIL PROTECTED]> wrote: > > > On Apr 16, 6:27 pm, "William Stein" <[EMAIL PROTECTED]> wrote: > > > > On Wed, Apr 16, 2008 at 11:21 AM, terry-s <[EMAIL PROTECTED]> wrote: > > > > > ok, I've tried out the instructions. > > > > > [1] On the desktop, the binary file downloaded and expanded ok, but I > > > > get (different from before) error messages when I run ./sage > > > > [screenful reproduced below]. > > > > That just means the binary is for a much older machine than yours. > > > You can either try a different linux binary, or wait for a Mandriva > > > binary. > > > --- Well if the binaries are for a restricted range of machines, then > > it would be > > helpful, if the webpages or documentation would actually say just what > > machines > > the binaries are for. > > Your problem is that your glibc version does not match with the Debian > binary build on Athlon. Since nobody has asked for Mandriva binaries > in the past there are none. The outline how to get them produced has > been suggested, so the ball is not in out court any more. > > Sage can easily be build from source; it is unfortunate that you do > not seem to have enough RAM to get that done, but we didn't write the > compiler. I would also doubt that you can build many other project > with 5 million lines of code with some portion written with templated C > ++ code. That is just life. > > > > > [2] On the laptop, there is no longer enough room even to expand the > > > > binary file, because of the 400MB debris left by the failed attempt to > > > > compile from source. If I could only know what it has installed on to > > > > the disk, I would like to remove it. (The failed compile attempt was > > > > made in a branch directory off 'home'. The total extra disk > > > > utilization after the compile attempt was about 800 MB more than at > > > > the start. About 400MB of that was in the subdirectory where the > > > > compile was done. I've now deleted that. But there remains an extra > > > > 400MB somewhere unidentified. Any ideas on where to look would be > > > > appreciated.) > > > > Sage is 100% local. It *does not* install any files anywhere else > > > on your hard drive unless you type "make install", and even then > > > the install only happens at the very end. In other words, just delete > > > the directory where you tried to do the build, and it will be as > > > if you had never done anything. Nice, eh? > > > "As if I had never done anything". Unfortunately that is not true, on > > the > > evidence of the state of my machine. > > > Terry > > Well, I am sure that unless *you* do something Sage does not touch > *any* file outside its own directory and $HOME/.sage. If for some > reason Sage did spew files all over the place I would like to hear > about it, but "the state of my machine" does not cut it for me and > that isn't something that can be debugged. > > Cheers, > > Michael --~--~---------~--~----~------------~-------~--~----~ To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-support URLs: http://www.sagemath.org -~----------~----~----~----~------~----~------~--~---
