Correct a false statement made about shlibs.

Shamelessly stollen from an expert source.

Obtained from:	Peter Wemm's email reply to Satoshi
This commit is contained in:
obrien 1996-12-10 10:02:48 +00:00
parent 1665979d2e
commit fcf606e187

View File

@ -1,4 +1,4 @@
<!-- $Id: policies.sgml,v 1.6 1996/12/09 11:18:52 obrien Exp $ -->
<!-- $Id: policies.sgml,v 1.7 1996/12/10 05:54:31 asami Exp $ -->
<!-- The FreeBSD Documentation Project -->
<chapt><heading>Source Tree Guidelines and Policies
@ -142,7 +142,7 @@ should be added and it should states things like:
<label id="policies:shlib">
</heading>
<p><em>Contributed by &a.asami; and &a.obrien;.
<p><em>Contributed by &a.asami;, &a.peter;, and &a.obrien;.
<newline>9 December 1996.</em></p>
<p>If you are adding shared library support to a port or other piece
@ -166,8 +166,16 @@ should be added and it should states things like:
<p>Stick to version numbers of the form major.minor (x.y). Our dynamic
linker does not handle version numbers of the form x.y.z well. Any
version number after the ``y'' is ignored, and cannot be used to
differentiate between two different shared library versions.
version number after the ``y'' (ie. the third digit) is totally ignored
when comparing shared lib version numbers to decide which library to
link with. Given two shared libraries that differ only in the `micro'
revision, ld.so will link with the higher one. Ie: if you link with
libfoo.so.3.3.3, the linker only records 3.3 in the headers, and will
link with anything starting with libfoo.so.3.(anything >= 3).(highest
available).
<p>Note that ld.so will always use the highest "minor" revision.
Ie: it will use libc.so.2.2 in preference to libc.so.2.0, even if the
program was initially linked with libc.so.2.0.
<p>For non-port libraries, it is also our policy to change the
shared library version number only once between releases. When