That's all good and well, and makes much sense, but my question was where can we find what exactly SOVERSION=1 means for libOpenCL? Is it guarantied that every vendor uses this version (and not 0 or 2)? I wasn't asking to make an exception for darktable, I was asking to make an exception for OpenCL.
On Mon, 6 Oct 2014 14:20:57 +0200 "Michael Below" <[email protected]> wrote: > > > -----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
