Soliciting help with libstdc++ and exceptions

[Martin v. Loewis]

> I don't believe in general that Linux distributors configure with
> --enable-threads.  This means that most of the system's shared
> libraries will contains bits of libgcc.a that are not compatible with
> one configured with --enable-threads (assuming you build your own).

I did a quick check, and found the following

- RedHat 6.1: gcc configured with --enable-threads; glibc (2.1) linked
  with thread-safe frame.o (*)

- Debian Slink: main gcc is 2.7.2.3; this was used to compile glibc
  (2.0), so glibc does not contain any of these functions. g++ (egcs
  1.1) configured with --enable-threads

- SuSE 6.2: gcc configured with --enable-threads; glibc (2.1) linked
  with thread-safe frame.o

So for the current distributions, there is no problem, AFAICT.

> Yes, that should all stay the same.  I actually don't know the answer.
> To really find out, I think what you should do is look at libgcc
> today, and look at the libgcc that was used to build the conflicting
> shared library (on my system, that would probably be 2.7.*).

No, you cannot build a libc.so.6 containing __register_frame_info with
gcc 2.7.2.3. That has to be a glibc 2.1, and it has to be build with
gcc 2.8, egcs 1.0, or newer. So I'm still at a loss under what
circumstance you see the problem, and what exactly the problem is.

Regards,
Martin

(*) To find out what the state of libc.so.6 is, look for
    __register_frame_info first. If it is in the library, also look
    for __gthread_active_ptr. If that is present, --enable-threads was
    used, if not, it wasn't used. If __register_frame_info is not
    present, this is glibc 2.0, and does not conflict, anyway.

    To find out how gcc was built, nm libgcc.a|grep pthread