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: "H . J . Lu" <hjl at lucon dot org>
- Subject: Re: GCC-3.0.1 can't compile Glibc-2.2.4
- From: Jakub Jelinek <jakub at redhat dot com>
- Date: Tue, 2 Oct 2001 18:06:37 +0200
- Cc: Mark Kettenis <kettenis at wins dot uva dot nl>, libc-alpha at sources dot redhat dot com
- References: <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> <20011002122016.I3251@sunsite.ms.mff.cuni.cz> <20011002083908.B31936@lucon.org>
- Reply-To: Jakub Jelinek <jakub at redhat dot com>
On Tue, Oct 02, 2001 at 08:39:08AM -0700, H . J . Lu wrote:
> You mised the point. When the new DWARF-2 opcodes are added to libgcc,
> the new libgcc_s.so.1 is no longer binary compatible with the previous
> ones. Something has to be done. I don't know what the gcc people have
Wrong. The new libgcc_s will be binary compatible with the apps/libs
compiled with older compiler, only apps/libs compiled with new compiler will
cannot obviously be run against old libgcc_s.
That's the vendor/admin responsibility to ensure the latest libgcc_s used is
installed.
> in mind. IMHO, they should have a new symbol version for those affected
> functions. No, I am not talking about __frame_state_for. I really don't
> see why we should dlopen libgcc_s.so.1 if we incorporate those changes
> into glibc.
I'm lost. If you are not talking about __frame_state_for (but glibc solely
dlopens libgcc_s for __frame_state_for; and this cannot change from
@@GLIBC_2.0, since then nobody will be able to use it) then what are you
talking about?
> > BTW: Concerning pre-gcc3 libstdc++, it might be easier solution to just
> > link the compatibility shared library against -lgcc_s. This way the unwind
> > stuff in glibc will be used only for C programs (the registry part, with
> > nobody using what was registered) or if a C program dlopens a C++ library
> > (that would be the only case where __frame_state_for from glibc is called).
>
> I am not sure if all pre-gcc3 C++ binaries are linked with libstdc++
> dynamically.
There are some libraries incorrectly linked (like some folks use ld -shared
or gcc -shared instead of g++ -shared to link a C++ shared library and thus
they don't have DT_NEEDED libstdc++), but they simply won't be able to throw
exceptions through glibc or other C shared library compiled with gcc 3+ if
those libs come earlier in the search scope. There is nothing that can be
done about them (appart from relinking in which case they should be linked
against libstdc++).
Jakub