[vlc-devel] Improper #include statements in /usr/include/vlc files
Rémi Denis-Courmont
rdenis at simphalempin.com
Tue Jul 8 15:25:53 CEST 2008
On Tue, 08 Jul 2008 09:10:20 -0400, "Bill C. Riemers" <briemers at redhat.com>
wrote:
> Two points:
> 1. Normally the library only the major version numbers are included in
> the so link and include files directories. The major number only needs
> to be updated when backwards compatibility is broken.
This is definitely not how libtool and Debian-based distros _typically_
handle it. Here, I have:
% ls /usr/lib/lib*.so.*.*.*|wc -l
440
% ls /usr/lib/lib*-*.so|wc -l
47
> 2. Generally, library version numbers don't have to match build
> versions. In fact they don't. libvlc is at version 2.0.1. So you
> would have libvlc-2.0.so, not libvlc-0.9.1.so.
No. libvlc ABI version is 2.0.1 so that the SONAME is libvlc2, and files:
libvlc.so.2.0.1
libvlc.so.2 -> libvlc.so.2.0.1
libvlc.so -> libvlc.so.2.0.1
If we switched to version-dependent naming, we'd get a soname of
libvlc-2.0.1 (or libvlc-0.9.0), and a single file:
libvlc-2.0.so
It is very likely that VLC 0.9.1 will get new APIs, so the version would
become 2.1.0, whereas the 0.9.0-bugfix series would go 2.0.2, 2.0.3... And
that means the SONAME would change to libvlc-2.1 requiring recompilation. I
suggest you re-read section 6 of the libtool manual.
It might be that libvlccore should use release-dependent versioning, but I
really think it is not how we want to go forward with libvlc.
--
Rémi Denis-Courmont
More information about the vlc-devel
mailing list