[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