corwin@polari.UUCP (Don Glover) (09/19/90)
I have a large program that I am trying to compile with the -g option under the latest update of the Xenix 386 C compiler. When compiled with out debug the executable is about 700k, when I try to compile for debug, I get 2/3 of the way thru the compile befor the .o files eat all of the 20meg of free space that I have ~ravailble, would some one like to hazard a guess as to why the friggin thing looks like the object files want to 30 meg when the non debug ones take about 650k?
steve@robobar.co.uk (Steve Bleazard) (09/20/90)
In article <2499@polari.UUCP> corwin@polari.UUCP (Don Glover) writes: >I have a large program that I am trying to compile with the -g option >under the latest update of the Xenix 386 C compiler. When compiled >with out debug the executable is about 700k, when I try to compile for >debug, I get 2/3 of the way thru the compile befor the .o files eat all >of the 20meg of free space that I have ~ravailble, would some one >like to hazard a guess as to why the friggin thing looks like the object >files want to 30 meg when the non debug ones take about 650k? This is usually caused by included .h files. ALL the symbols in the header files are encoded into the debug info, even if they are not used. Bloat can be particularly serious if you have single .h file containing all the typedefs etc for the program. As this file is invariably included in every .c file, the objects produced all contain a copy of this file (in debug format). This alone can increase object size by a factor of 10 and the effect will be even more dramatic if the program has been broken down into a lot of small files. Steve. -- Steve.Bleazard@RoboBar.Co.Uk | Phone: +44 81 991 1142 x153 Snr Software Engineer, Robobar Ltd. | Fax: +44 81 998 8343 (G3) 22 Wadsworth Road, Perivale. | Middx., UB6 7JD ENGLAND. | ...!ukc!robobar!steve