Description of problem: G++ stalls when trying to compile Openh323 How reproducible: Always Steps to Reproduce: 1. Get PWLib.. compile it 2. get OpenH323 (reproducable with 1.1 and 1.5.5) 3. start compile (run make) Actual Results: At the first "g++" line it starts eating memory and then swap with great appetite and doesnt seems to stop. It never gets past that point. It has to be kill (ctrl-c works) Expected Results: It should or give me a working objet or an error message or at least somethings.. Additional info: Its gcc-2.96-85 and I'm on a P2-300 (i686)... I dont know if it works with gcc 3.0, but it did work with egcs and 2.95
I'm trying gcc from rawhide to see if I have better results.... Does GCC-3.0 produce compitable stuff or not?
I just downloaded the GCC from rawhide and it didnt want to compile it either. I got the sme result... I also forgot to say that it slowly but surely eats megs and megs of ram until I'm forced to kill it... Its your snapshot, fix it...
Please attach preprocessed source which exhibits this problem together with arguments given (e.g. you can use -save-temps option in addition to the ones OpenH323 passes to G++ and resulting .ii file will be created in current directory). The new C++ AST inliner is far more memory hungry (this is the same as in G++ 3.0), but unless you're very tight on memory it should not eat all of your memory and swap.
Created attachment 24968 [details] Preprocessed file
It crashes on the first file it tried to compile... This file is h225.cxx It produces and empty h225.s and the attached h225.ii. This is using gcc-2.96-93 Here is the command used: g++ -Wall -DP_LINUX -m486 -D_REENTRANT -DP_HAS_SEMAPHORES -fPIC -DP_SSL -I/usr/include/openssl -DP_PTHREADS -DPBYTE_ORDER=PLITTLE_ENDIAN -I/home/Tester/pwlib/include/ptlib/unix -DPTRACING -I/home/Tester/openh323/include -save-temps -DHAS_IXJ -DHAS_OSS -DPTRACING -I/home/Tester/pwlib/include -O2 -DNDEBUG -c h225.cxx -o /home/Tester/openh323/lib/obj_linux_x86_r/h225.o
With the given options, this compiles just fine on my box, eating at most 230MB of memory, if you use -finline-limit=1000 option in addition to that, it will top at 150MB. But note that this example is almost a megabyte long main C++ source file with heavily inlined code. Even gcc 2.95.2 eats on this almost 100MB of RAM, and it does far less inlining than 2.96-RH or 3.0 does. There is some work in 3.0.1 and especially in 3.1 to tune the inlining logic better, but AFAIK it is still not good enough and would destabilize 2.96-RH.