On 08/22/2016 04:10 PM, Julien Cristau wrote:
On Mon, Aug 22, 2016 at 14:18:51 -0700, Jason Ekstrand wrote:
On Mon, Aug 22, 2016 at 2:06 PM, Julien Cristau <jcris...@debian.org> wrote:
On Fri, Aug 19, 2016 at 09:04:14 -0700, Jason Ekstrand wrote:
Not providing a path allows the ICD to work on multi-arch systems but
breaks it if you install anywhere other than /usr/lib. Given that users
may be installing locally in .local or similar, we probably do want to
provide a filename. Distros can carry a revert of this commit if they
want
an intel_icd.json file without the path.
If a user is going to install stuff in .local, don't they have
LD_LIBRARY_PATH pointing there too?
Actually, no. The loader will look for ICD files in
.local/share/vulkan/icd.d and the ICD file will point to the right .so. It
should work out-of-the-box unless you either have a broken loader or we're
installing something wrong.
So somehow they're only building the vulkan driver but not libGL or
anything else? Still, I guess a bunch of people will need both a 32bit
and a 64bit version of the driver. How is the 64-bit
~/.local/share/vulkan/icd.d/intel_icd.json not going to clash with the
32-bit ~/.local/share/vulkan/icd.d/intel_icd.json? I'm just not seeing
how this solves the problem...
To recap the IRC discussion:
ld-linux.so will expand $LIB to lib or lib64 as appropriate.
Unfortunately, Debian patches glibc to make $LIB expand to the target
triple and there's no convenient way to figure out how $LIB expands at
build time.
So you can just put $LIB in your architecture-independent ICD file and
everything will work just fine, you just have to manually put the shared
libraries in the appropriate location for your distribution.
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
