2013/6/1 Pete Batard <p...@akeo.ie>: > On 2013.05.31 08:57, Ludovic Rousseau wrote: >> Another proposal is to remove the version number from the .pc file. > > Well, it sure looks like dead weight to me. > >> On my Debian system I have: >> $ ls -l /usr/lib/x86_64-linux-gnu/pkgconfig >> total 172 >> -rw-r--r-- 1 root root 323 mai 7 09:38 libusb-1.0.pc >> -rw-r--r-- 1 root root 207 oct. 2 2012 libusb.pc >> Many .pc file do _not_ have a version. > > # ls -alFh /usr/lib64/pkgconfig/libftdi* > -rw-r--r-- 1 root root 252 Mar 30 02:30 /usr/lib64/pkgconfig/libftdi1.pc > -rw-r--r-- 1 root root 224 Mar 30 02:30 /usr/lib64/pkgconfig/libftdipp1.pc > > Just pointing that one (since I'm playing with OpenOCD on Linux, and > libFTDI v1.0 from source, through make install, a couple days ago). > > Is it me or are the libftdi people also doing something they probably > shouldn't do then? Likewise, I also have a whole bunch of libftdi1's in > my lib64 directory. > >> The filename libusb.pc is already used by libusb-0.1. So we can't use >> that without conflicts. > > OK, so we can't actually remove the version. > Does that mean that, while the API/ABI compatibility problem has been > solved at the library level on POSIX, it still hasn't been solved at the > pkgconfig level? > > You mentioned one can use PKG_CHECK_MODULES(LIBUSB, libusb-1.0 >= > 1.0.15, ...). Is there anything along these lines that would allow the > use of a single libusb.pc to pick 0.1, 1.0, etc?
Only one libusb.pc file can be installed at a given time. I will take an example with a foo library on Linux. The libfoo-x.y.z.tar.gz archive when build will provide the files - libfoo.pc - libfoo.so.0.1.0 - libfoo.so.0 (link to libfoo.so.0.1.0) - libfoo.so (link to libfoo.so.0) The libfoo.so.0 and libfoo.so.0.1.0 files are used at the execution time. The libfoo.so and libfoo.pc files are used a build time. libfoo.so.0 and libfoo.so.0.1.0 will be packaged in libfoo0_x.y.z.deb libfoo.so and libfoo.so.pc will be packaged in libfoo-dev_x.y.z.deb (or -devel for rpm packages) One benefit of this naming is that if the ABI change in an incompatible way then the library will use libfoo.so.1. So both libfoo.so.0 and libfoo.so.1 can be installed on the system at the same time. Binaries using the old ABI can coexist with binaries using the new ABI. You can install both libfoo0 and libfoo1 packages at the same time. But you can't install libfoo-dev from 2 different releases. This is not really a problem since you only need this package at build time, not at run time. So, no, it is not possible to use PKG_CHECK_MODULES(LIBFOO, libfoo, ...) and select the version you want. You will only use the version installed by the libfoo-dev package. What you can do is check the version installed correspond to what the program needs and complain/abort if not. A side effect is that it is not safe to use "pkg-config --modversion libfoo" since the libfoo.pc file may: - not be installed - reference a version different from the version used by the binary (libfoo.pc from libfoo.so.1 is installed when the binary is using libfoo.so.0) The only safe way to know what library version is used is with something already done by libusbx: $ LIBUSB_DEBUG=99 ./listdevs libusbx: debug [libusb_init] created default context libusbx: debug [libusb_init] libusbx v1.0.15.10648 [...] You can now replace libfoo by libusb-1.0. The file names are: - libusb-1.0.pc - libusb-1.0.so - libusb-1.0.so.0 - libusb-1.0.so.0.1.0 - libusbx-1.0.15.tar.bz2 The "1.0" in libusb-1.0.so is not related to the "1.0" in .so.0.1.0 and is not related to the "1.0" in libusbx-1.0.15. It is just a coincidence. For version 2.0 if the API we can decide to rename the POSIX library libusb-2.0 (or maybe libusb2 to avoid confusion with a release number). This would allow to have -dev (or -devel) packages installed at the same time for the 2 different API versions. Bye -- Dr. Ludovic Rousseau ------------------------------------------------------------------------------ Get 100% visibility into Java/.NET code with AppDynamics Lite It's a free troubleshooting tool designed for production Get down to code-level detail for bottlenecks, with <2% overhead. Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap2 _______________________________________________ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
