libtool
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

lib*.so symlink


From: Brian May
Subject: lib*.so symlink
Date: 02 Feb 2001 19:37:03 +1100
User-agent: Gnus/5.0807 (Gnus v5.8.7) XEmacs/21.1 (Capitol Reef)

Hello,

Following a debate that regularly pops up on debian-policy (see
<URL:http://bugs.debian.org/83669>), I have a simple (read: hopefully)
question regarding the symlinks for shared libraries.

(I assume that correct conventions have been used in the version
number of the shared library).

Currently the convention, at least on Linux is (for the example of
libz):

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

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

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.

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.

(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)

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.

Any comments?
-- 
Brian May <address@hidden>



reply via email to

[Prev in Thread] Current Thread [Next in Thread]