[Mesa-dev] [PATCH] anv: Give the installed intel_icd.json file an absolute path

[Emil Velikov]

On 23 August 2016 at 19:05, Nicholas Miell <nmiell at gmail.com> wrote:
> On 08/23/2016 02:07 AM, Emil Velikov wrote:
>>
>> Skimmed through the discussion and I'm not sure the above will be enough.
>>
>> Since the user is free to place json files in $HOME/.local ... this
>> implies that they may _not_ have access to /usr or /etc. Thus as they
>> install the file (to say $HOME/foo/lib) the Vulkan loader will not be
>> able to pick it up.
>
>
> Why not?
>
> Stick the 32-bit library in $HOME/foo/lib, the 64-bit library in
> $HOME/foo/lib64, set library_path to "/home/emil/foo/$LIB/lib_mygpu.so" in
> the $HOME/.local/share/vulkan/icd.d/mygpu.json file, and it should work,
> right?
>
Few reasons:
 - If you use $LIB you also need to provide for all arches supported
by your setup. otherwise the loader will for missing files (small
nitpick but still).
 - conflict of who provides the json file - is it the x86-64 or i386
package, both, neither etc.
 - the vulkan loader is based on the presumption that can be multiple
drivers on the system. Each one clearly distinguished and described in
it's own json. Thus as ABI changes (gets updated) we must mandate that
distributions and users update both 64 and 32bit packages at the same
time. Otherwise there will be a miss-match between the described ABI
in json and the actual one of the binary/ies.

>> In theory one should be able to have a varying .json (one with and one
>> without the path) although the heuristics will be fragile due to the
>> varying $LIB (like the case of Debian and derivatives) and $DESTDIR.
>>
>> So I see the following options:
>>  - new configure option - have to agree with Dave, please don't.
>> Furthermore we already have more than 50! of them.
>>  - fold the "w or w/o full path" under and existing option
>> (--enable-debug ?) - somewhat picky/fragile as well. Kind of OK for
>> short term solution.
>>  - use LD_LIBRARY_PATH - slightly annoying yet add once and forget
>> about it. OK-ish short term solution.
>>  - json update - the better long term solution imho.
>>
>> Json update:
>>  - the same file _cannot_ be provided by multiple packages
>
>
> RPM certainly allows this, as long as the packages that provide the file
> have the same name & version, different architectures, and the files are
> byte-identical. Sticking $LIB in the path instead of "lib" or "lib64" makes
> the files byte-identical.
>
>
Not everyone uses RPM, or even a package manager all together. In any
distro (mostly for source based ones) having one package overwrite
files of another package, is a serious no go. It may be allowed by
that's an exception of the general rule, requiring it's own list with
"ifs and buts".

Real world example: your distro ships the 64bit ICD, but not a 32bit
one. You build and install the latter yourself and as
  - you remove it (because of reasons) you end up breaking your 64bit setup
 -  or, you update the 64bit package and the contents of the json
change in a way that they don't reflect/describe your 32bit ICD.

So all in all, without separate json files each describing a separate
ICD, things are extremely easy to break.

-Emil