This is the mail archive of the libc-alpha@sources.redhat.com 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: gcc 3.x test matrix


On Thu, Sep 06, 2001 at 11:04:45PM +0200, Mark Kettenis wrote:
>    Date: Wed, 5 Sep 2001 23:00:14 -0700
>    From: "H . J . Lu" <hjl@lucon.org>
> 
>    I disagreee. The whole idea of dlopening libgcc.so.1 is for future
>    changes in gcc. If we have no ideas about what the impacts of those
>    changes are, how do we know this scheme will work? There are many
>    ways for gcc to provide the binary compatibility. I don't think it
>    will work right if gcc and glibc don't work together from the very
>    beginning.
> 
> The very beginning is GCC 3.0.1 (and apparently GCC 3.0.2 for
> PowerPC).  IMHO, checking whether new versions of GCC will work right
> with glibc should be part of the GCC release procedures.

If glibc chooses a scheme which will never work with the future gcc
changes, how can it work? libgcc_s.so.2?

> 
> That said, it doesn't hurt to somehow test mainline GCC, and I'll be
> happy to include results in my test reports.  I just don't want to
> increase the number of permutations that we need to test without a
> good reason.  If glibc doesn't work with GCC 3.x, it's GCC 3.x that
> needs to be fixed, not glibc.

I never said it would be easy. However, we can ask the gcc developers
for the possible future changes in the libgcc_s.so ABI and make a new
gcc based on gcc 3.0.x to try them out. We don't even have to make any
real code changes, only the ABI changes.


H.J.


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