From a132f331c4aae7df29ba1342ec0a1d384a703b46 Mon Sep 17 00:00:00 2001 From: "David E. O'Brien" Date: Tue, 10 Dec 1996 10:02:48 +0000 Subject: [PATCH] Correct a false statement made about shlibs. Shamelessly stollen from an expert source. Obtained from: Peter Wemm's email reply to Satoshi --- handbook/policies.sgml | 16 ++++++++++++---- 1 file changed, 12 insertions(+), 4 deletions(-) diff --git a/handbook/policies.sgml b/handbook/policies.sgml index 57011abd83..a8c3bd8186 100644 --- a/handbook/policies.sgml +++ b/handbook/policies.sgml @@ -1,4 +1,4 @@ - + Source Tree Guidelines and Policies @@ -142,7 +142,7 @@ should be added and it should states things like: -

Contributed by &a.asami; and &a.obrien;. +

Contributed by &a.asami;, &a.peter;, and &a.obrien;. 9 December 1996.

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:

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). +

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.

For non-port libraries, it is also our policy to change the shared library version number only once between releases. When