This is the mail archive of the mailing list for the glibc project.

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

Re: [PATCH] Next attempt on the gcc3 vs glibc2.2.4 patch

On Mon, Aug 06, 2001 at 04:41:36PM +0200, Jakub Jelinek wrote:
> On Sun, Aug 05, 2001 at 06:00:14AM -0700, Ulrich Drepper wrote:
> > Andreas Jaeger <> writes:
> > 
> > > Shouldn't we add patch for configure to check for GCC 3.0 and remove
> > > it as soon as the patches go in?
> > 
> > I'll do this for the final release if this is still the case (and I
> > assume it will be).
> Here is an updated version of the GCC 3.0 vs. GLIBC 2.2.4 patch.
> Unlike the previous one, it does not care which gcc was used to build GLIBC
> - everywhere but on Linux/IA-64 it exports the new GCC 3.0 unwind
> register/deregister routines plus _Unwind_Find_FDE (using gcc's
> unwind-dw2-fde.c with just a few changes for glibc), plus on platforms which
> used to export __frame_state_for from glibc it does so. __frame_state_for
> implementation in GLIBC means first try to dlopen if it exists
> and call __frame_state_for in there, if it does not exist, it has a
> fallback, so that GLIBC 2.2.4 does not require GCC 3.0.1+'s libgcc to be
> installed.
> I've tested it using various tests I described last time (basically all
> gcc version combinations of C++ main program and -fexception C shared
> library the C++ main program throws exceptions through), with both glibc
> compiled with GCC 2.96-RH and GCC 3.0.1 CVS.

I like this approach very much. A few commenrs:

1. There should be a run-time vs. link-time version check for libgcc
just in case that there may be some libgcc extensions in the future. I
have brought it up a few times on the gcc mailing list. But I got zero
positive responses there. I believe it is necessary. Even if there are
no interests from the gcc people, I think we should at least do it for
glibc. I can provide patches for gcc and glibc if necessary.
2. I think we should try to share the same files used in both gcc and
glibc. That means we should try to patch those files in gcc so that
they can also be compiled in glibc without any changes. After all,
both gcc and glibc are parts of the GNU project. Mark, can you bring
up this issuse with the gcc SC?



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