Re: A patch for default version and archive

[Ian Lance Taylor <ian at zembu dot com>]

   From: Ulrich Drepper <drepper@redhat.com>
   Date: 14 Nov 2000 10:32:52 -0800

   Ian Lance Taylor <ian@zembu.com> writes:

   > What I am saying is that if we did not have @ symbols, we could set
   > symbol versions only in the linker version script.  My understanding
   > is that that is how it works on Solaris.  Solaris does not have @
   > symbols.

   This is because they don't support multiple versions of a function in
   the same binary.  Just think, who would you have two versions for a
   function foo?  They are both named foo (cannot really be) or they both
   would have different names (in which case the version script would
   have to make the association between the alternative name and the
   version).  If we get rid of something then it is the versioning
   script.  This is the one piece which is not necessary anymore.

I don't think you are really listening to me.  You seem to think that
I am arguing some position which you must defend against.  However,
this is a minor point, and I will drop it.

   > Where is this documentation?

   I posted it to various places on various occasions.  Once more it's
   now available at http://www.cygnus.com/~drepper/symbol-versioning.

Thanks for the pointer.  Perhaps we could incorporate some of this
into the binutils documentation, or perhaps we don't need to.

However, I guess this isn't quite what I was looking for.  It is very
operational.  To my eyes it is also written backward--the order of
sections should be reversed.  Documentation of this sort is very
important.  However, the kind of description I was thinking of was at
a more conceptual level.

For example, look at the documentation for the --warn-common option in
the linker (which I believe was written by DJM).  It tells people what
a common symbol is, gives an example, and describes by example how
common symbols behave.  The documentation is incomplete, because it
does not describe how common symbols behave in the presence of shared
objects.  But it provides enough of a guideline that we were able,
over time, to implement common symbol semantics for shared objects to
follow the lines of the semantics in regular objects.

That is, I would like to see something which describes version symbols
at a more conceptual level, while still being precise.  That would
certainly need to be backed up by documentation of the sort you wrote.
But it would explain the what and the why rather than the how.

Ian