This is the mail archive of the
libc-hacker@cygnus.com
mailing list for the glibc project.
Re: A patch for glibc 2.0/2.1
- To: Mark Kettenis <kettenis@phys.uva.nl>
- Subject: Re: A patch for glibc 2.0/2.1
- From: Zack Weinberg <zack@rabi.columbia.edu>
- Date: Fri, 22 Jan 1999 19:11:02 -0500
- cc: libc-hacker@cygnus.com
On Sat, 23 Jan 1999 00:57:22 +0100 (CET), Mark Kettenis wrote:
>
>Remember that gcc 2.8.1 has gotten a bad name amongst Linux users
>because it fails to compile the 2.0.x kernels, because these used some
>undocumented inline assembler features. And of course it is not
>really useful for C++ (but who wants to write C++ anyway :-)). But
>that's all irrelevent for compiling glibc.
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
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. Not allowing the use of gcc 2.8 to compile libc
comes pretty damn close, however. [It doesn't matter which compiler
is used to compile the binaries.]
Incidentally, Ulrich, if we're going to do it this way, we need this
patch for csu/Versions:
============================================================
Index: csu/Versions
--- csu/Versions 1998/07/10 20:43:33 1.2
+++ csu/Versions 1999/01/23 00:10:22
@@ -8,7 +8,7 @@
# Exception handling support functions from libgcc
__register_frame; __register_frame_table; __deregister_frame;
- __register_frame_info; __deregister_frame_info;
+ __register_frame_info; __deregister_frame_info; __frame_state_for;
# variables in normal name space
errno;
zw