This is the mail archive of the
libc-alpha@sources.redhat.com
mailing list for the glibc project.
Re: Special symbol version for glibc's internal interfaces
- To: Philip Blundell <pb at nexus dot co dot uk>
- Subject: Re: Special symbol version for glibc's internal interfaces
- From: Andreas Jaeger <aj at suse dot de>
- Date: Tue, 28 Aug 2001 16:09:56 +0200
- Cc: libc-alpha at sources dot redhat dot com, Karl dot Runge at Sun dot COM
- References: <ho1ylwmhiu.fsf@gee.suse.de><E15bjRJ-0004ML-00@mill.nexus.co.uk>
Philip Blundell <pb@nexus.co.uk> writes:
>>Hiding those symbols with GLIBC_PRIVATE would make it explicit that
>>those are internal interfaces.
>>
>>Why didn't we follow this at first when adding symbol versioning to
>>glibc? What do other think about this?
>
> What does that really buy you? People can still link to the symbols if they
> are determined, whatever version you give them. The presence of the two
> leading underscores ought to be sufficient to warn people that these are an
> internal interface.
The two advantages I see directly are:
- psychological, you see that a program is using internal symbols
directly. We can much easier tell people that they're using
internal symbols. The two underscores is not always correct, some
inline functions/macros that are public use them.
- Tools can be easily implemented that check whether objects use these
symbols, we don't need to maintain a database of internal functions.
Have a look at the following RPM output:
$ rpm -q --requires bash
/bin/sh
ld-linux.so.2
libc.so.6
libc.so.6(GLIBC_2.0)
libc.so.6(GLIBC_2.1)
libc.so.6(GLIBC_2.2)
libdl.so.2
libdl.so.2(GLIBC_2.0)
libdl.so.2(GLIBC_2.1)
libhistory.so.4
libncurses.so.5
libreadline.so.4
A GLIBC_PRIVATE would stick out and alarm people.
> That said, I don't think your proposal will do any harm either.
;-)
Andreas
--
Andreas Jaeger
SuSE Labs aj@suse.de
private aj@arthur.inka.de
http://www.suse.de/~aj