Xref: utzoo comp.lang.c++:6169 comp.emacs:7568 Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!usc!zaphod.mps.ohio-state.edu!sunybcs!oswego!news From: dl@g.g.oswego.edu (Doug Lea) Newsgroups: comp.lang.c++,comp.emacs Subject: Re: libg++ question Message-ID: Date: 19 Jan 90 12:14:48 GMT References: <1000@abvax.UUCP> Sender: news@oswego.Oswego.EDU (Network News) Reply-To: dl@oswego.edu Organization: SUNY Oswego Lines: 41 In-reply-to: jaz@calvin's message of 17 Jan 90 17:16:02 GMT First, please send g++ or libg++ questions to the GNU mailing lists (like bug-lib-g++@prep.ai.mit.edu), not to more general newsgroups. (I wouldn't followup here either, except it's a good opportunity to remind people.) > I get an unresolved external error on symbol LBE242 when linking > tPlex in the test subdirectory of 1.36.2 of libg++. I can't find reference > to this symbol anywhere. This unused/unnecessary debugger reference to an optimized-out label is fixed in 1.36.3, but, as it says in the installation instructions, it is a good idea to use the gnu assembler, which can handle such things. > Also the following code generates a 250kb binary: > #include > main() > { > cout << "hello, world"; > } > > The corrosponding gcc program produces a 30kb binary. > Is there that much overhead here ? Do the commercial C++ compilers do > much better at this ? > The difference stems mainly from the *current* inability of g++ to handle/manage/generate shared libraries like those used with Sun C programs. The .o file is only 416 bytes on a SPARC. Most of the other 250K results from the linker pulling in a good part of libg++, plus Sun C libraries. With shared libraries (as are possible now with C), the differences between C and C++ executable sizes should be much smaller. -Doug -- Doug Lea, Computer Science Dept., SUNY Oswego, Oswego, NY, 13126 (315)341-2367 email: dl@oswego.edu or dl%oswego.edu@nisc.nyser.net UUCP :...cornell!devvax!oswego!dl or ...rutgers!sunybcs!oswego!dl