Re: lib*.so symlink

[Alexandre Oliva]

On Feb  2, 2001, Brian May <address@hidden> wrote:

> where several people (including me) have been wondering if a better
> system would be:

>  /usr/lib/libz.so -> libz.so.1.1.3
>  /usr/lib/libz.so.1 -> libz.so.1.1.3
>  /usr/lib/libz.so.1.1.3

This is the scheme adopted by libtool, as a matter of fact.

> The benefit here would be you have a installation like this

>  /usr/lib/libz.so -> libz.so.1.1.2
>  /usr/lib/libz.so.1 -> libz.so.1.1.3
>  /usr/lib/libz.so.1.1.2
>  /usr/lib/libz.so.1.1.3

> so programs use the previous version for compiling, but the latest
> versions for run-time. It is assumed that header files for the correct
> library have version been installed.

Where, by `correct', I hope you mean those of 1.1.2.  Otherwise,
1.1.3's headers might get you using features of 1.1.3.  For example,
it would be perfectly legal for the newer headers to contain
backward-compatibility #defines such as:

#define old_func(args) new_func(args, extra_args)

and have the actual library still implement old_func() as a call to
new_func, for binary backward-compatibility, while arranging for new
users to get the additional function call optimized away.

> I believe that libz.so.1.1.3 means that code compiled for
> libz.so.1.1.2 should still work fine, but at the same time, compiled
> code can be transferred to other computers which only has
> libz.so.1.1.2 installed.

Correct.

> (you probably wouldn't want to do the reverse though - If my
> understanding is correct, code compiled for libz.so.1.1.3 would not
> run using libz.1.1.2)

It just can't be guaranteed.  It might work :-)

> The only real concern I have with this proposal is libz.la (assuming
> libz is built with libtool). However, this is already a potential
> problem (programs designed for libz.so.1 could mistakenly use the
> libz.la file from libz.so.2 build). So I won't consider these
> problems here.

Presumably, libz.la would be that from the older version, since
libz.la is used for linking.  And then, because libtool sets dlname to
the SONAME of the library, you'd still get the newer version dlopened.

The only problem scenario is if you don't have the .la file: you'd
probably end up dlopening the .so, that points to the older version.
If, for whatever reason, the program is also explicitly linked with
the library it dlopens, you'd have two different versions of the same
library linked in.  I have no idea of what kind of probably might come
up.  All I know is that I wouldn't like to be there :-)

So it seems to me that the policies already in place are enough to
support this kind of us.  The package manager would have be adjusted
so as to keep the .so and the .la of the earliest version of a library
(as per the lib-dev package), and the .so.MAJOR of the latest version
thereof (as per the lib package).  Or something like that :-)

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                  address@hidden, redhat.com}
CS PhD student at IC-Unicamp        address@hidden, gnu.org}
Free Software Evangelist    *Please* write to mailing lists, not to me