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]

Re: A shared version of libgcc


>>>>> "Richard" == Richard Henderson <rth@cygnus.com> writes:

    >> And what about the C++ specific symbols?  Since we control
    >> libstdc++, we have some additional flexibility here:
    >> 
    >> * Keep those in a static library.  If they're also included in
    >> libstdc++ this static library will only be used for C++
    >> programs that don't use the standard C++ library.
    >> 
    >> * Include those symbols in libstdc++ and link all C++ programs
    >> against libstdc++.
    >> 
    >> * Include those symbols in a special C++ runtime shared
    >> library.
    >> 
    >> * Include those symbols in both libstdc++ and the special C++
    >> runtime shared library.  That way one doesn't have to
    >> distribute two libraries for C++ programs that use the standard
    >> C++ library.

    Richard> All of these are reasonable, from what little I know of
    Richard> what's involved with the C++ support in libgcc.  What to
    Richard> do with this stuff is a question for the G++ and
    Richard> libstdc++-v3 teams to work out.

Actually, these aren't C++-specific symbols.  There EH-specific
symbols.  Any EH-using front-end will need them.  That includes C++,
Java, and probably Ada.  C, as well, if we were to implement
Microsoft's C EH model.

So, these symbols shouldn't be squished into libstdc++; they need to
stay in a separate library.  They could be removed from libgcc, but
I'm not sure I see any particular benefit.

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com

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