search

KhronosGroup / Vulkan-Headers

Vulkan header files and API registry
https://www.vulkan.org/
Other
829 stars 210 forks source link

Cross compilation broken #330

Closed sarnex closed 1 year ago

sarnex commented 1 year ago

After commit https://github.com/KhronosGroup/Vulkan-Headers/commit/b092b2fccc812453c1d0ec0a829eb8f34f174803, cross compilation is broken.

We need to revert https://github.com/KhronosGroup/Vulkan-Headers/commit/b092b2fccc812453c1d0ec0a829eb8f34f174803 in Gentoo to fix multi-ABI vulkan-loader build

If you compile vulkan-loader in -m32, it looks can't find the vulkan-headers cmake files because they are only installed into the default ABI directory (usually x86_64)

It sounds like the real fix is to also install the headers mentioned in https://github.com/KhronosGroup/Vulkan-Headers/pull/326 to an arch-independent directory like /usr/include, since everything in this repo appears to be arch-independent

sarnex commented 1 year ago

FYI: @tgurr @juan-lunarg

tgurr commented 1 year ago

FYI: @tgurr @juan-lunarg

I've no experience on how Gentoo handles multilib, but should't you be able to add your cmake-multilib magic like done for vulkan-loader to vulkan-headers as well to get what you need? On Exherbo for example there's no /usr/include per se as we have proper cross compilation installing headers on each arch into their respective include directory under prefix e.g. /usr/x86_64-pc-linux-gnu/include & /usr/i686-pc-linux-gnu/include and since this path is referenced in the cmake files we can't have just one file in /usr/share for multiple archs, like stated in https://github.com/KhronosGroup/Vulkan-Headers/pull/326.

Side note: In the nv-codec-headers package I mentioned in my initial pull request the Gentoo package also applies some workaround moving the pkg-config files to/usr/share: https://gitweb.gentoo.org/repo/gentoo.git/tree/media-libs/nv-codec-headers/nv-codec-headers-11.1.5.2.ebuild#n21

sarnex commented 1 year ago

@tgurr Thanks for the response.

Sure, from a technical perspective we can do that, but I don't think it's the right solution. We do that for the other vulkan packages because binaries are built, which is obviously arch dependent.

My understanding (and correct me if I'm wrong, this assumption is fundamental to my point) is that there are no arch-specific headers in vulkan-headers. My understanding is everything is arch independent.

If so, we should not install into arch-specific directories. If we do that, the same exact files are installed twice and take up twice the disk space and it takes twice the computation power to install/copy them for absolutely no benefit to users.

I don't know how Exherbo deals with arch-independant files, but /usr/include is widely used in the Linux ecosystem for arch independent code, so Exherbo must have a general solution for code put in /usr/include. Maybe the files are duplicated for Exherbo, but we shouldn't force that on everyone.

About nv-codec-headers, IMO the ebuild is working around an upstream bug, basically the equivalent of what this bug report is about.

juan-lunarg commented 1 year ago

My understanding (and correct me if I'm wrong, this assumption is fundamental to my point) is that there are no arch-specific headers in vulkan-headers. My understanding is everything is arch independent.

That is correct.

If so, we should not install into arch-specific directories. If we do that, the same exact files are installed twice and take up twice the disk space and it takes twice the computation power to install/copy them for absolutely no benefit to users.

Correct. CMake header only libraries that are arch-independent should only have to be installed once.

sarnex commented 1 year ago

Thanks, that PR will fix this issue for us.

johnzupin commented 1 year ago

PR #331 also fixed cross-compilation on Ubuntu distributions as well

juan-lunarg commented 1 year ago

Vulkan-Headers is also now consistent with spirv-headers: https://github.com/KhronosGroup/SPIRV-Headers/commit/eae955f0525724526fa602fd126623b9d84599fa