I am trying to compile the lastest version of Panda under Linux Suse 8.2
and I must interrupt the process after more than 3h because it seems to
be hang. It stops while compiling builder/graph_composite.cxx (or something
I am using a P IV 1.7 GHz, 256 MB and GCC 3.3.
Any idea?. Thanks.
I can’t speak for Suse 8.2 in particular, or of gcc 3.3 (maybe Josh can answer more specifically about these), but I have seen problems with some versions of gcc in the past that just seem to hang when they are attempting to optimize large bodies of code, and pgraph_composite1.cxx is one of the largest. In fact, gcc is not truly hanging in these cases, but is just consuming obscenely large amounts of virtual memory; I once had a report from a very patient person that it eventually finished in something like 12 hours, and required several gigabytes of virtual memory. (Normally it should take under a minute, and not use more than a few hundred megabytes at most.)
But I have heard that gcc 3.3 works successfully to compile Panda, so presumably it is not encountering the same absurd bug. But I suppose it might still require more than your 256 MB physical ram, which will force it to thrash virtual memory–causing an extreme slowdown at that point.
Still, it does seem like 256 MB ought to be enough. Try running a “top” process running in another window while you are compiling–how much memory does it seem to be using when it gets to that point and seems to hang? (This number is displayed in the “SIZE” and “RSS” columns of top.)
Thanks for the reply.
While, it was compiling the source code, I opened another text console
and executed the ‘top’ command, and you are right, the process takes
more than 300 MB of memory.
I am using the flag OPTIMIZE=4, so if I reduce the optimization
level, will it compiles sucessfully?
Well, that’s one option. But OPTIMIZE=1 is the only level that does not invoke the optimizer. It will certainly compile at OPTIMIZE=1, but the resulting Panda will run very slowly.
Another option might be to define NO_COMBINED_SOURCES to 1 in your Config.pp; this will turn off the use of the composite files and allow each file to be compiled independently. This is slower in most cases, but it will consume less memory, and so it will probably be much faster in your case. However, you will have difficulties with this, because we have gotten sloppy–with NO_COMBINED_SOURCES in effect, you will find many compilation errors from header files that aren’t #included where they should be. It will take some trial-and-error and a lot of patience to figure out which .h files should be #included in which .cxx files. (If you were interested in doing this, and successfully added #includes where appropriate, we would be happy to accept your patches. But I’m not asking you to do this.)
A third option, much easier than the above, is to do this just in the directories that are causing you problems. Try putting “#define NO_COMBINED_SOURCES 1” in the pgraph/Sources.pp file (and then re-running ppremake). (This does require you to follow the ppremake build instructions, which have this flexibility, rather than the makepanda build instructions.)
A final option is, of course, just to let it build overnight.