On 2013.06.01 12:57, Ludovic Rousseau wrote: > 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 if you have two incompatible versions of the API, despite the fact that the .so.x(.y) runtimes can coexist nicely in that scenario, you're screwed in terms of .so and .pc because there are no provisions there for concurrent incompatible APIs. I still kind of want to say that it defeats the whole purpose of having coexisting incompatible runtime ABI/APIs with the same basename, since you're pretty much forced to rename the library if you want app developers to have the possibility of choosing their preferred API (without reinstalling and monitoring dev packages). > 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. Which seems to mean that you must have a libfoo-dev and libfooNEWAPI-dev as soon as you break the API, and, since you will want to keep the runtime names in check with the dev names (else it will become confusing fast) you will likely end up with: - libfoo.pc - libfoo.so.0.1.0 - libfoo.so.0 - libfoo.so - libfooNEWAPI.pc - libfooNEWAPI.so.1.x.y - libfooNEWAPI.so.1 - libfooNEWAPI.so Or you might actually end up with libfooNEWAPI.so.0 (it's supposed to be a separate library anyway as far as the OS is concerned), and thus I'm not sure what's the point of the so.[n+1] mechanism. That is, unless the idea was that nobody would develop against the old API when there's a new one, which, as we've seen with libusb 0.1, is not exactly realistic. So, unless I'm still missing something, I have to say that POSIX still seems to fall a bit short in terms of avoiding manual suffixing of its libraries on API breakage. And I could add that the above doesn't do much in terms of convincing that going 1.2 everywhere would be an absolute NO_GO on POSIX. But since I don't expect to rally much support for 1.2 everywhere, I guess I (and everybody else) will have to make do with sticking to 1.0... Regards, /Pete ------------------------------------------------------------------------------ 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
