Another relevant quote from Vincent Danjean, author of ocl-icd-libopencl1, in a bug report to Intel, because Intel were using libOpenCL.so as soname in their Linux SDK: https://software.intel.com/en-us/forums/topic/277598
"The Linux SDK for OpenCL provides the libOpenCL.so library with "libOpenCL.so" as soname. AMD, NVidia and the new free OpenCL ICD Loader ocl-icd[1] all use the "libOpenCL.so.1" soname. In order to ensure good binary portability in the long term for OpenCL applications, and in order to allow OpenCL applications compiled with Intel SDK to be run on Linux Platform with other OpenCL SDK installed (or even with the AMD ICD Loader but the Intel ICD), but also in order to allow the Intel OpenCL SDK to run a OpenCL programs compiled with another vendor SDK, it would be very pleasant that the library provided by the Linux Intel SDK has the " libOpenCL.so.1" soname. Of course, a libOpenCL.so symlink must still be provided in order to allow linkage." -----Ursprüngliche Nachricht----- Von: Michael Below [mailto:[email protected]] Gesendet: Montag, 6. Oktober 2014 14:20 An: 'parafin' Betreff: AW: [Darktable-users] OpenCL detected by clinfo, not detected by dt, ideas? Hi parafin, I think referencing a shared library without an ABI version is avoided with a reason. I don't see the need to introduce an exception for darktable. Like any other program, darktable might run into problems if a future libOpenCL.so.2 omits parts of the v1 ABI. The version is included in the SONAME to allow for a clean update process. Below I've found some quotes for this. Cheers Michael Here's a "best practices" document for shared libraries in the ELF format: http://plan99.net/~mike/writing-shared-libraries.html "Every ELF library has a soname, which is distinct from its file name. The soname is what the linker uses to identify the library. A good soname has the form "libxxx.so.y", where xxx is the name of your library and y is the major version. The minor version is not reflected in the soname. You can set the soname of your library using a linker switch." The Debian policy is reflecting this: https://www.debian.org/doc/debian-policy/ch-sharedlibs.html " A shared library is identified by the SONAME attribute stored in its dynamic section. When a binary is linked against a shared library, the SONAME of the shared library is recorded in the binary's NEEDED section so that the dynamic linker knows that library must be loaded at runtime. The shared library file's full name (which usually contains additional version information not needed in the SONAME) is therefore normally not referenced directly. Instead, the shared library is loaded by its SONAME, which exists on the file system as a symlink pointing to the full name of the shared library. This symlink must be provided by the package. Run-time shared libraries, Section 8.1 describes how to do this. [58] When linking a binary or another shared library against a shared library, the SONAME for that shared library is not yet known. Instead, the shared library is found by looking for a file matching the library name with .so appended. This file exists on the file system as a symlink pointing to the shared library. ... To determine the soversion, look at the SONAME of the library, stored in the ELF SONAME attribute. It is usually of the form name.so.major-version (for example, libz.so.1). The version part is the part which comes after .so., so in that example it is 1. The soname may instead be of the form name-major-version.so, such as libdb-5.1.so, in which case the name would be libdb and the version would be 5.1. ... Every time the shared library ABI changes in a way that may break binaries linked against older versions of the shared library, the SONAME of the library and the corresponding name for the binary package containing the runtime shared library should change. Normally, this means the SONAME should change any time an interface is removed from the shared library or the signature of an interface (the number of parameters or the types of parameters that it takes, for example) is changed. This practice is vital to allowing clean upgrades from older versions of the package and clean transitions between the old ABI and new ABI without having to upgrade every affected package simultaneously. " Wikipedia says: http://en.wikipedia.org/wiki/Soname "The soname is often used to provide version backwards-compatibility information. For instance, if versions 1.0 through 1.9 of the shared library libx provide identical interface, they would all have the same soname, e.g. libx.so.1. If the system only includes version 1.3 of that shared object, with filename libx.so.1.3, the soname field of the shared object tells the system that it can be used to fill the dependency for a binary which was originally compiled using version 1.2." -----Ursprüngliche Nachricht----- Von: parafin [mailto:[email protected]] Gesendet: Montag, 6. Oktober 2014 13:28 An: 'darktable-users' Betreff: Re: [Darktable-users] OpenCL detected by clinfo, not detected by dt, ideas? On Mon, 6 Oct 2014 12:26:05 +0200 "Michael Below" <[email protected]> wrote: > 2. And darktable doesn’t use the correct SONAME when it tries to load > libOpenCL.so instead of libOpenCL.so.1. This works only if > nvidia-cuda-toolkit (or, probably, any other OpenCL development package) is > installed, which provides the symlink from libOpenCL.so to libOpenCL.so.1. Opening libOpenCL.so is standart-de-facto, everyone does it. I couldn't find any official specification of which SONAME is canonical. If libOpenCL.so.1 should be used (and not libOpenCL.so.0 or libOpenCL.so.2) instead - where is that defined as correct? My point is that changing our code this way will fix this Debian issue, but might break some other setups. IMHO Debian should get over itself and consider libOpenCL as a special case - there are many vendors that provide this library and AFAIK no written rules how to do it. Compromise would be to try opening both these names, that might be a good idea, but will require a bit more changes to the code. ------------------------------------------------------------------------------ Slashdot TV. Videos for Nerds. Stuff that Matters. http://pubads.g.doubleclick.net/gampad/clk?id=160591471&iu=/4140/ostg.clktrk _______________________________________________ Darktable-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/darktable-users ------------------------------------------------------------------------------ Slashdot TV. Videos for Nerds. Stuff that Matters. http://pubads.g.doubleclick.net/gampad/clk?id=160591471&iu=/4140/ostg.clktrk _______________________________________________ Darktable-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/darktable-users ------------------------------------------------------------------------------ Slashdot TV. Videos for Nerds. Stuff that Matters. http://pubads.g.doubleclick.net/gampad/clk?id=160591471&iu=/4140/ostg.clktrk _______________________________________________ Darktable-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/darktable-users
