Re: Special symbol version for glibc's internal interfaces

[Andreas Jaeger <aj at suse dot de>]

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