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
"H . J . Lu" <hjl@lucon.org> writes:
> 1. We still have an implementation in libc.so. Are we going to keep it
> compatible with the gcc used to build libc.so?
>From what I understand that part of gc will not change. So there is
no problem.
> 2. We still don't know for sure if libgcc_s.so.1 available at the
> run-time is compatible with the gcc used to build libc.so.
The libgcc.so is versioned. After dlopen() you look with dlsym() for
symbols like GCC_3_0_1 or so. These are the version names and they
are in the symbol table. You look for the minimum version number you
expect and fail if it's not there. The gcc people will ensure that
upwards compatibility is ensured.
> 3. If libgcc_s.so.1 is not available at the run-time and we don't
> keep the libc.so's implementation compatible with the gcc used to
> build libc.so, the old applications won't run correctly.
And the problem is? If a sysadmin decides not to install (or a wrong
version of) ld.so the system won't run either. There is nothing we
can do to prevent stupid people from making mistakes.
> If we don't really care about the old applications, we should just
> remove __frame_state_for from glibc.
No. Adding requirements to the runtime environment (à la requiring
libgcc.so) is not at all the same as dropping compatibility.
--
---------------. ,-. 1325 Chesapeake Terrace
Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA
Red Hat `--' drepper at redhat.com `------------------------