Re: darwin library_names_spec

[Gary V. Vaughan]

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

Peter O'Gorman wrote:
| Gary V. Vaughan wrote:
| | Removing the long versioned flavour will break the libtool versioning
| | paradigm.  Maybe you could make libfoo.dylib the symlink, and
| | libfoo.x.dylib
| | the target?
|
| Okay, to better explain why this isn't broken :)

Okay, on second read after a strong coffee, I think I can follow you :-b

| Given we have libfoo.la linked with version 3:12:1 , currently this will
| create 3 files
| libfoo.dylib -> libfoo.2.1.12.dylib
| libfoo.2.dylib -> libfoo.2.1.12.dylib
| libfoo.2.1.12.dylib
| The encoded information will be "install_name libfoo.2.dylib" (this is
| the file the dynamic linker will look for) and compatibility_version 4
| current_version 4.12.

Not sure what the `compatibility_ and current_' represent, but my feeling is
that these are the values that need to be twiddled rather than the soname or
the library filenames.

3:12:1 declares that this is the 12th release that supports interfaces 2 and 
3...

| Now, with my proposed change we would only get two files
| libfoo.dylib -> libfoo.2.dylib
| libfoo.2.dylib
| The encoded information would be the same (CURRENT + 1 for the
| compatibility version).
|
| Now lets release a new libfoo 4:0:2
| Current system:
| libfoo.dylib -> libfoo.2.2.0.dylib
| libfoo.2.dylib -> libfoo.2.2.0.dylib
| libfoo.2.2.0.dylib
| install_name libfoo.2.dylib compatibility_version 5 current_version 5.0
| Proposed :
| libfoo.dylib -> libfoo.2.dylib
| libfoo.2.dylib
| same encoded information.

Okay, so 4:0:2 says this library supports interfaces 2, 3 and 4...

| If we link an application against libfoo 3:12:1, it will continue to run
| ~ with libfoo 4:0:2 (it will not work the other way around, an app linked
| against libfoo 4:0:2 will not run with libfoo 3:12:1 installed). Current
| and proposed systems are the same.

So far so good, 3:12:1 doesn't support interface 4, so the dynamic linker
should not choose 3:12:1 as a library to satisfy a dependency on 4:0:2.
However, 4:0:2 does support all of the interfaces exported by 3:12:1, so the
linker can choose 4:0:2 to satisfy a program linked against 3:12:1...

| Let's update libfoo again 5:0:0
| Current:
| libfoo.dylib -> libfoo.5.0.0.dylib
| libfoo.5.dylib -> libfoo.5.0.0.dylib
| libfoo.5.0.0.dylib
| install_name libfoo.5.dylib compatibility_version 6 current_version 6.0
| Proposed:
| libfoo.dylib -> libfoo.5.dylib
| libfoo.5.dylib

So now you have created a library that doesn't support any of the interfaces
in the previous two releases, but that has a brand new interface 5 only.

| link to this lib and it will refuse to run for libfoo.2.dylib (the
| dynamic linker will not look for libfoo.2.dylib) link to an older lib
| and the dynamic liner will not find the new one.

Yep, neither of the old releases has any interface revisions in common with
the new release so the libraries are not compatible with one another.

| Now, I'm tired of updating libfoo, hard work all these updates :-)
| The proposed patch affects nothing much except that there is one less
| symlink and the encoded library name is the same as the real library.

But you can no longer keep several versions of the library installed at once.
~   Say I install 5:1:0 and 5:2:0, under the current scheme we have:

~    libfoo.5.0.0.dylib
~    libfoo.5.0.1.dylib
~    libfoo.5.0.2.dylib
~    libfoo.5.dylib->libfoo.5.0.2.dylib
~    libfoo.dylib->libfoo.5.0.2.dylib

| Is this clear? (I often make sense only to myself)

I think the question is:  Do we need to keep this many versions around?  If we
do, then your proposal is void, and we need to figure out another way to solve
your problem.  If not, then several of the other versioning schemes are also
broken and need to be fixed too.

Cheers,
        Gary.
- --
Gary V. Vaughan      ())_.  address@hidden,gnu.org}
Research Scientist   ( '/   http://www.oranda.demon.co.uk
GNU Hacker           / )=   http://www.gnu.org/software/libtool
Technical Author   `(_~)_   http://sources.redhat.com/autobook
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQE/1G2kFRMICSmD1gYRAkObAJ4+VfnUMZuCpgetg1DbCBAytdZTGwCeL4Al
93cRhoRe4doB+3djlAr/aNw=
=QOwq
-----END PGP SIGNATURE-----