I think there's part of the ebuild missing to rename the non native abi binaries
(In reply to Mike Lothian from comment #0) > I think there's part of the ebuild missing to rename the non native abi > binaries This is the default, and normally correct, behavior of all multilib packages. Is there something special that requires vulkan-tools to be special?
There isn't much point it being a multilib package when enabling the flag makes no difference to the final files produced
Hi Mike, Are you planning to submit a pull request with proper multilib support in the near future? If not, I can work on it. Thanks, Sarnex
(In reply to Nick Sarnie from comment #3) > Are you planning to submit a pull request with proper multilib support in > the near future? > > If not, I can work on it. I'm guessing lack of a response is answer enough.
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=3f0f865797bbc1caaa7f94d65f2d2a7eaffd9cfd commit 3f0f865797bbc1caaa7f94d65f2d2a7eaffd9cfd Author: Nick Sarnie <sarnex@gentoo.org> AuthorDate: 2018-09-01 22:03:48 +0000 Commit: Nick Sarnie <sarnex@gentoo.org> CommitDate: 2018-09-01 22:56:42 +0000 dev-util/vulkan-tools: Also install 32-bit binaries in multiabi case Closes: https://bugs.gentoo.org/660760 Package-Manager: Portage-2.3.48, Repoman-2.3.10 .../vulkan-tools/vulkan-tools-1.1.77.0-r2.ebuild | 98 ++++++++++++++++++++++ dev-util/vulkan-tools/vulkan-tools-9999.ebuild | 13 ++- 2 files changed, 109 insertions(+), 2 deletions(-)
You should not assume that there are only 2 ABIs ("32" and "64"). In x86 family of architectures, there is also "x32". In MIPS, there is "n32", "n64" and "o32". My suggestion would be to rename all executables by including ${CHOST} in filenames, and to create symlinks pointing to main ABI (${CHOST} for main ABI is available as ${CHOST_default}). Example on multilib amd64 (ABI_X86="32 64 x32"): i686-pc-linux-gnu-cube i686-pc-linux-gnu-cubepp i686-pc-linux-gnu-vulkaninfo x86_64-pc-linux-gnu-cube x86_64-pc-linux-gnu-cubepp x86_64-pc-linux-gnu-vulkaninfo x86_64-pc-linux-gnux32-cube x86_64-pc-linux-gnux32-cubepp x86_64-pc-linux-gnux32-vulkaninfo cube -> x86_64-pc-linux-gnu-cube cubepp -> x86_64-pc-linux-gnu-cubepp vulkaninfo -> x86_64-pc-linux-gnu-vulkaninfo
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=bf3057af25a62b4b4f266d2ab04faba3579b7b3f commit bf3057af25a62b4b4f266d2ab04faba3579b7b3f Author: Nick Sarnie <sarnex@gentoo.org> AuthorDate: 2018-09-01 23:26:53 +0000 Commit: Nick Sarnie <sarnex@gentoo.org> CommitDate: 2018-09-01 23:27:38 +0000 dev-util/vulkan-tools: Consider CHOST in multilib binary names Bug: https://bugs.gentoo.org/660760 Package-Manager: Portage-2.3.48, Repoman-2.3.10 dev-util/vulkan-tools/vulkan-tools-1.1.77.0-r2.ebuild | 19 ++++++++----------- dev-util/vulkan-tools/vulkan-tools-9999.ebuild | 19 ++++++++----------- 2 files changed, 16 insertions(+), 22 deletions(-)
Thanks, I implemented that idea using MULTILIB_CHOST_TOOLS. Also fixed problems with different use combinations here: https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=db0cf685e4d6baa058fab7410041af755baec059
https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=6c296e5ea05304ef33ff4846c8f88cb459063e55
