Re: [Bug-readline] Set correct -compatibility_version in .dylib on Mac OS X

[Chet Ramey]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 4/25/14, 2:51 PM, Max Horn wrote:

> That is incorrect (and I tried to explain in my email why that is). 
> 
> First off, the change is necessary because new API was added -- it would have 
> been necessary for 6.2, 6.1, etc., too, just nobody noticed.

OK.  I'm under the impression that Mac OS X treats compatibility_version
like DT_SONAME.

For those not familiar, Unix systems that use ELF shared libraries set
them up

libabsinthe.so -> libabsinthe.so.6
libabsinthe.so.6 -> libabsinthe.so.6.5

where libabsinthe.so.6.5 is a real file, in this case the newest version.
The soname in this example is libabsinthe.so.6.  libabsinthe.so.6.5 sets
the DT_SONAME field to libabsinthe.so.6 (the soname).

Clients store the sonames of each library they require in the DT_NEEDED
section of the executable, and the run-time linker (ld.so) is responsible
for resolving each soname to a real on-disk file that can be mapped into
the program's address space.  The most recent minor version always wins,
and clients looking for, say, libabsinthe.so.6.1 will be satisfied with
libabsinthe.so.6.n, n>=1, since minor versions are backwards compatible.
They can even introduce new APIs/ABIs as long as the set common to all
versions of the library with soname libabsinthe.so.6 remains constant.

The Mach-O format includes the same kind of library-specifying sections.
It's my impression that programs specify the equivalent of soname and
depend on dyld to find the right library versions and dynamically link
them, in much the same way that ld.so works.  The current_version is the,
well, current version, and the compatibility_version is the soname
equivalent.

So if compatibility_version is used to indicate when new functions are
added, as you said, not when incompatible changes are made, how is this
functionality used?  Is it supposed to indicate some kind of `forward
incompatibility' instead of the more-or-less backwards compatibility
function of soname?

> Secondly, the removal of those typedefs is irrelevant, because that was only 
> an API change, not an ABI change, so it doesn't affect the shared lib in any 
> way.

True.  That's the only backwards-incompatible change between readline-6.2
and readline-6.3.

> Indeed, if the *ABI* would have been changed in a backward incompatible way 
> (i.e. a function gets removed, or changes its semantics in an incompatible 
> way) then the major version of the shared library should be changed from 6 to 
> 7... but that is something that of course would already be covered by the 
> existing build rules.

Sure, that's universally true.

Chet
- -- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
                 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, ITS, CWRU    address@hidden    http://cnswww.cns.cwru.edu/~chet/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlNdicEACgkQu1hp8GTqdKvq9gCfZSgA/zdNzXNe2zBnz0w7JB4x
waYAn1KXzAII2gCvEInLJjQwTFIYWsLO
=slLo
-----END PGP SIGNATURE-----