If you know what version of a library you want to build against and you know the path to it you can link against it. The compilation and linking is no longer automatic because you have to specify your dependent library specifically, but you can put it anywhere you want and it won't conflict with a different version of the same name.
But that's my point: we should be able to get automatic linking. Different versions of the same library already don't conflict because the file names are different:
libncurses.so.4.0.1
libncurses.so.5.1.1
When you build your application, reference the .pc file for the library version you want. If the application does not support pkgconfig you could write a wrapper that parses it and provides the build/link options you desire.
True, I see what you're saying. It always seemed to me that custom pkconfigs for this case, that generate full paths to the libraries instead of -llibrary options, is a bandaid on not having automatic linking against a specific version.
i too hope one day all this will be automatic (though we still have to specify a version, and keep up to date on what version supports what, so its hardly automatic for the dev or packager). the real fix to me is to embed all relevant information in the binaries and let the dynamic linker figure out which one should be used at run time. compile time would merely embed what version was used to build the app. maybe this is already possible? i'm curious...
While that would be cool, it doesn't seem very pragmatic. I think I'd rather have control over exactly which version is chosen (where I can use implementation details in making a decision), rather than have it decide automatically based on claims expressed in the library metadata.
though we still have to specify a version, and keep up to date on what version supports what, so its hardly automatic for the dev or packager
I think the common case is for new development, you'd most likely develop against the most recent release version, but you don't need to keep up to date on which version supports what because you can continue to use the old versions with long-since compiled binaries as long as it can be installed along side the latest version. I think people and distros, in general, are too quick to remove older versions from being installed (or even available), which increases the on-going maintenance requirements of still popular binaries.
On the other hand, during transition periods, distros have been pretty good about this, like the libc5 vs libc6 transition, and by providing compat packages. But this has mainly been an issue with closed source abandonware (Skype for a long time was still using OSS and needed an ancient version of some audio libs).
But that's my point: we should be able to get automatic linking. Different versions of the same library already don't conflict because the file names are different:
When you build your application, reference the .pc file for the library version you want. If the application does not support pkgconfig you could write a wrapper that parses it and provides the build/link options you desire.True, I see what you're saying. It always seemed to me that custom pkconfigs for this case, that generate full paths to the libraries instead of -llibrary options, is a bandaid on not having automatic linking against a specific version.