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: Jakub Jelinek <jakub at redhat dot com>
- Subject: Re: GCC-3.0.1 can't compile Glibc-2.2.4
- From: "H . J . Lu" <hjl at lucon dot org>
- Date: Mon, 1 Oct 2001 10:28:32 -0700
- Cc: Mark Kettenis <kettenis at wins dot uva dot nl>,libc-alpha at sources dot redhat dot com
- References: <20010924095200.A16632@lucon.org> <20010924190501.D689@sunsite.ms.mff.cuni.cz> <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>
On Wed, Sep 26, 2001 at 01:27:45PM -0700, H . J . Lu wrote:
> On Wed, Sep 26, 2001 at 05:56:50AM -0400, Jakub Jelinek wrote:
> >
> > > As I said above, the dependency is not very strict. It only kicks in
> > > in some corner cases.
> >
> > I'd stress this. glibc will depend on libgcc_s.so.1 only for legacy C++
> > applications (and only once new DWARF-2 opcodes are added), so IMHO it is
> > not a big deal to do the dlopen.
>
> Why is this dependency absolutely necessary? I'd prefer to have the
> frame fuctions in glibc compatible with the gcc used to build glibc.
>
One more thing, when new DWARF-2 opcodes are added to libgcc, does
anyone know what will happen to the interface of libgcc? Certainly,
the binaries compiled with new gcc won't be compatible with the older
libgcc_s.so.1. Something has to be done to libgcc_s.so.1 so that we
will get a run-time error when it happens. There are 2 ways to detect
this condition:
1. Detect it as early as possible, when the incompatible binary is
loaded into memory.
2. Detect it when the exception is thrown.
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.
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.
H.J.