What's up with __register_frame_info?

[Jake Hamby]

Hi all,

I'm using EGCS 1.0.3 on RH5 (recently upgraded to RH5.1).  The first
programs I tried to compile after upgrading from GCC 2.7.2.3 to EGCS were
Hello world in C and C++.  I noticed that the C version was about 25k,
much bigger than the C++ version at 5k.  This seemed unusual, so with nm,
I traced it to the fact that the C version was including definitions of
__deregister_frame_info and __register_frame_info, while the C++ version
was grabbing these definitions from libstdc++.so.

I wasn't too concerned about this until I recompiled SANE (a scanner
package that broke after RH5.1 upgraded GIMP and GTK).  When I tried to
run the front-ends, they complained about a missing definition of
__register_frame_info.  After installing the program, it started working,
and now I believe it was due to the front-ends being compiled against the
new version of libsane.so (which exports __register_frame_info by virtue
of having been compiled with EGCS) but at runtime finding the previously
installed version of libsane.so, which doesn't.

Therefore, I wouldn't classify what I experienced as a bug, necessarily,
but I'm still curious why this relatively large chunk of code for
__register_frame_info and __deregister_frame_info is being pulled into C
programs when it wasn't before.

Actually, I can think of one situation where this could cause some bizarre
problems:  What if somebody recompiles libc.so with EGCS, then wouldn't
all of their recompiled C programs start importing __register_frame_info
from there?  Wouldn't all of those binaries then break when used on a
system where libc.so hadn't been compiled with EGCS? Suppose, for example,
that RedHat 5.2 is compiled entirely with EGCS (while RH5.1 includes RPMS
for EGCS, it looks like they're still building libc with GCC, because I
couldn't find __register_frame_info in it).  This could lead to massive
RPM incompatibility, right?

-Jake