Re: A patch for glibc 2.0/2.1

[Mark Kettenis <kettenis@phys.uva.nl>]

   Date: Fri, 22 Jan 1999 19:11:02 -0500
   From: Zack Weinberg <zack@rabi.columbia.edu>

Hi Zack,

Thanks for your mail, this sheds some more light on the issue.

   When you compile glibc with 2.8.1, does libc.so define and export all
   these symbols?

    T __deregister_frame
    T __deregister_frame_info
    T __frame_state_for
    T __register_frame
    T __register_frame_info
    T __register_frame_info_table
    T __register_frame_table

Nope, I only have 

T __deregister_frame_info
t __frame_state_for
T __register_frame_info
t __register_frame_info_table

__deregister_frame, __register_frame and __register_frame_table are
absent because they are not referenced by libc and live in another
module in the gcc 2.8.1 libgcc.  This of course is easy to solve.  I
can provide a patch if necessary.

Note that __register_frame_info_table currently isn't exported.

However I don't think contaminating the libc ABI with more compiler
specific symbols is a good idea.  And I think it isn't necessary.
I'll post my analysis why to libc-hacker shortly.

   If they aren't all there, executables that use C++ compiled against
   your libc will not work with an egcs-compiled libc, and vice versa.
   We've been kicking this problem around for awhile and there is no
   perfect solution.

Well if you compile your C++ programs with egcs you'll need the shared
libstdc++ that comes with egcs which will contain those symbols.

Mark