This is the mail archive of the
mailing list for the glibc project.
Re: Special symbol version for glibc's internal interfaces
Andreas Jaeger <email@example.com> writes:
> Do you see any problems implementing this? This is a glibc 2.3 issue
> IMO but we should discuss whether it can be done or not.
I have discussed this issue with the guys at Sun when I was there a
few months ago. It certainly is an appealing idea. No 2.2.x
material, definitely since I am almost sure that there are programs
violating the rules and introducing something like this in a minor
release isn't adequate.
But people shouldn't be too enthusiastic either. All this buys is to
know that programs cannot use internal functions and so might not be
broken if something changes. People doing this don't have my
sympathies and I have no problem with seeing their program being
broken. This change (and the tools for its enforcement and checking)
are only a mean to avoid a few flames from people using such code and
it makes it easier to provide an alternative implementation of the
libc (be on Linux, Hurd, or another OS in compatibility mode).
I have some plans for other radical changes in the ABI/API of the libc
anyway for 2.3 and this might fit just well.
There is only one problem I see. Currently the GLIBC_2.0 is used as
the default by programs linked against glibc 2.0. How the
introduction of another bottom-line version (and the private version
should be no child of another version) affects this lookup behavior
remains to be seen. Hopefully it will just work but testing is
needed. If I haven't convinced you yet that this is no 2.2 material
this hopefully will.
---------------. ,-. 1325 Chesapeake Terrace
Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA
Red Hat `--' drepper at redhat.com `------------------------