Ah, I thought they fixed it when I wrote my previous mail. If they
didn't, then my point isn't even theoretical.

On Mon, 6 Oct 2014 14:52:16 +0200
"Michael Below" <[email protected]> wrote:

> Hi parafin,
> 
> see my last mail with the quote from Vincent Danjean: NVidia, AMD and ocl-icd 
> agree that the current ABI is soversion=1. Intel doesn't include a soversion, 
> but their libOpenCL.so isn't legally redistributable anyway. So I think Intel 
> might need a workaround, not AMD, Nvidia & co.
> 
> Cheers
> Michael
> 
> 
> -----Ursprüngliche Nachricht-----
> Von: parafin [mailto:[email protected]] 
> Gesendet: Montag, 6. Oktober 2014 14:46
> An: 'darktable-users'
> Betreff: Re: [Darktable-users] WG: OpenCL detected by clinfo, not detected by 
> dt, ideas?
> 
> 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
> 
> 

------------------------------------------------------------------------------
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

Reply via email to