This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: RFA: Please review the new C++ demangler patch


Phil Edwards <phil@jaj.com> writes:

| On Fri, Jun 27, 2003 at 10:55:47PM +0200, Gabriel Dos Reis wrote:
| > Phil Edwards <phil@jaj.com> writes:
| > 
| > | support can still use it.  That's why it was moved to libsupc++, so that...
| > | 
| > |     gcc a_c++_program_only_using_clause_18.cc -lsupc++
| > | 
| > | ...a.out does not depend on libstdc++.so at runtime.
| > 
| > May I suggest static link?
| 
| You can suggest it, but that doesn't mean it's a good idea.

Maybe, maybe not.

|  :-)  Why fold
| a completely unused library into the executable?

static link against libstdc++-v3, does not mean the whole libstdc++-v3
(especially the unused bits) is pulled into the executable.  Does it?
The contention seems to be the dependence on <string> and <vector>.

| Not only would the executable be needlessly large, the users would still
| suffer the overhead caused by libstdc++'s startup code.  That's one of the
| whole points of libsupc++.  Static linking doesn't solve the problem that
| libsupc++ was created to solve, and it introduces its own problems.

it isn't libsupc++ that is under debate.  I was talking of the
demangler issue.

(Yes, I know the purpose of libsupc++).

-- Gaby


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]