This is the mail archive of the
libc-alpha@sources.redhat.com
mailing list for the glibc project.
Re: GCC-3.0.1 can't compile Glibc-2.2.4
- To: Mark Kettenis <kettenis at wins dot uva dot nl>
- Subject: Re: GCC-3.0.1 can't compile Glibc-2.2.4
- From: "H . J . Lu" <hjl at lucon dot org>
- Date: Tue, 2 Oct 2001 08:30:14 -0700
- Cc: jakub at redhat dot com, libc-alpha at sources dot redhat dot com
- References: <20010924103415.B17065@lucon.org> <s3ik7yoz31v.fsf@soliton.wins.uva.nl> <20010925102111.B9236@lucon.org> <200109252357.f8PNvs306972@delius.kettenis.local> <20010925171933.A16536@lucon.org> <200109260924.f8Q9OFb07011@delius.kettenis.local> <20010926055650.A25384@devserv.devel.redhat.com> <20010926132745.B1529@lucon.org> <20011001102832.A12158@lucon.org> <200110021002.f92A2M200378@delius.kettenis.local>
On Tue, Oct 02, 2001 at 12:02:22PM +0200, Mark Kettenis wrote:
>
> If gcc does do #1, which I think is the right thing to do, does anyone
> know how it will impact dlopening libgcc_s.so.1? To me, there are so
> few benefits and so many unanswered questions, I don't think we should
> do dlopening libgcc_s.so.1 at all.
>
> I don't see how we can reliably implement #1. If we don't dlopen
> libgcc_s.so.1 we might consider the unwinder and frame registration
> functions coupled for legacy C++ code, and do the checking you
> suggest, but libgcc_s.so.1 still enters the picture for new C++ code.
> Adding the checks that you suggest will not only make it impossible to
> compile glibc with future versions of GCC, but also make it impossible
> to simply use glibc with future versions of GCC.
I don't know what you were referring to.
>
> BTW, one way to implement #1 for gcc is to update the version of those
> affected functions from GCC_3.0 to GCC_3.1, when the incompatible
> changes are made, and make the GCC_3.0 version of those functions
> invisible to ld. If gcc does that, we can check it in the glibc
> configure to verify if gcc is compatible with glibc. I can write a
> patch for that.
>
> And what are in your view those affected functions?
You have to ask the gcc developers. All affected functions should have
a different version so that ld.so will refuse to load any binary which
references the new version. I don't know why you think it is impossible
to implement.
>
> I repeat once more that coupling glibc to a particular version of GCC
> is something we should try to avoid.
Exactly, with some differences:
1. I don't want to couple glibc with a particular version of GCC, AT
THE RUN-TIME.
2. We should make the glibc in CVS compatible with the current gcc,
including those still under developement, if all possible.
H.J.