Build failure on 32 bit (Linux)

[Zamundaaa]

This is with version 1.4.341.0 on Fedora: https://bugs.kde.org/show_bug.cgi?id=520589

The errors we got are all about the spaceship operator, and disabling it fixes the build:

/usr/include/vulkan/vulkan_structs.hpp: In member function ‘std::strong_ordering vk::DisplayPropertiesKHR::operator<=>(const vk::DisplayPropertiesKHR&) const’:
/usr/include/vulkan/vulkan_structs.hpp:56600:31: error: no match for ‘operator<=>’ (operand types are ‘const vk::DisplayKHR’ and ‘const vk::DisplayKHR’)
56600 |       if ( auto cmp = display <=> rhs.display; cmp != 0 )
      |                       ~~~~~~~ ^~~ ~~~~~~~~~~~
      |                       |               |
      |                       |               const vk::DisplayKHR
      |                       const vk::DisplayKHR
  • there are 7 candidates
    /usr/include/vulkan/vulkan_structs.hpp:56600:31:
    56600 |       if ( auto cmp = display <=> rhs.display; cmp != 0 )
          |                       ~~~~~~~~^~~~~~~~~~~~~~~
    • candidate 1: ‘template<unsigned int N, unsigned int M> std::strong_ordering vk::operator<=>(const ArrayWrapper1D<char, N>&, const ArrayWrapper1D<char, M>&)’ (reversed)
      /usr/include/vulkan/vulkan.hpp:165:24:
        165 |   std::strong_ordering operator<=>( ArrayWrapper1D<char, N> const & lhs, ArrayWrapper1D<char, M> const & rhs ) VULKAN_HPP_NOEXCEPT
            |                        ^~~~~~~~
      • template argument deduction/substitution failed:
        •   ‘const vk::DisplayKHR’ is not derived from ‘const vk::ArrayWrapper1D<char, N>’
          /usr/include/vulkan/vulkan_structs.hpp:56600:39:
          56600 |       if ( auto cmp = display <=> rhs.display; cmp != 0 )
                |                                       ^~~~~~~
    • candidate 2: ‘template<unsigned int N> std::strong_ordering vk::operator<=>(const std::string&, const ArrayWrapper1D<char, N>&)’ (reversed)
      /usr/include/vulkan/vulkan.hpp:211:24:
        211 |   std::strong_ordering operator<=>( std::string const & lhs, ArrayWrapper1D<char, N> const & rhs ) VULKAN_HPP_NOEXCEPT
            |                        ^~~~~~~~
      • template argument deduction/substitution failed:
        •   ‘const vk::DisplayKHR’ is not derived from ‘const vk::ArrayWrapper1D<char, N>’
          /usr/include/vulkan/vulkan_structs.hpp:56600:39:
          56600 |       if ( auto cmp = display <=> rhs.display; cmp != 0 )
                |                                       ^~~~~~~
    • candidate 3: ‘template<unsigned int N> std::strong_ordering vk::operator<=>(const ArrayWrapper1D<char, N>&, const std::string&)’ (reversed)
      /usr/include/vulkan/vulkan.hpp:255:24:
        255 |   std::strong_ordering operator<=>( ArrayWrapper1D<char, N> const & lhs, std::string const & rhs ) VULKAN_HPP_NOEXCEPT
            |                        ^~~~~~~~
      • template argument deduction/substitution failed:
        •   ‘const vk::DisplayKHR’ is not derived from ‘const vk::ArrayWrapper1D<char, N>’
          /usr/include/vulkan/vulkan_structs.hpp:56600:39:
          56600 |       if ( auto cmp = display <=> rhs.display; cmp != 0 )
                |                                       ^~~~~~~
    • candidate 4: ‘operator<=>(int, int)’ (built-in)
      /usr/include/vulkan/vulkan_structs.hpp:56600:31:
      56600 |       if ( auto cmp = display <=> rhs.display; cmp != 0 )
            |                       ~~~~~~~~^~~~~~~~~~~~~~~
      • no known conversion for argument 2 from ‘const vk::DisplayKHR’ to ‘int’
    • candidate 5: ‘operator<=>(int, long long unsigned int)’ (built-in)
      • no known conversion for argument 2 from ‘const vk::DisplayKHR’ to ‘long long unsigned int’
    • candidate 6: ‘operator<=>(long long unsigned int, int)’ (built-in)
      • no known conversion for argument 2 from ‘const vk::DisplayKHR’ to ‘int’
    • candidate 7: ‘operator<=>(long long unsigned int, long long unsigned int)’ (built-in)
      • no known conversion for argument 2 from ‘const vk::DisplayKHR’ to ‘long long unsigned int’

[M2-TE]

The linked bug report mentions that the issue boils down to this section in vulkan_core.h:

#ifndef VK_USE_64_BIT_PTR_DEFINES
    #if defined(__LP64__) || defined(_WIN64) || (defined(__x86_64__) && !defined(__ILP32__) ) || defined(_M_X64) || defined(__ia64) || defined (_M_IA64) || defined(__aarch64__) || defined(__powerpc64__) || (defined(__riscv) && __riscv_xlen == 64)
        #define VK_USE_64_BIT_PTR_DEFINES 1
    #else
        #define VK_USE_64_BIT_PTR_DEFINES 0
    #endif
#endif
[...]
#ifndef VK_DEFINE_NON_DISPATCHABLE_HANDLE
    #if (VK_USE_64_BIT_PTR_DEFINES==1)
        #define VK_DEFINE_NON_DISPATCHABLE_HANDLE(object) typedef struct object##_T *object;
    #else
        #define VK_DEFINE_NON_DISPATCHABLE_HANDLE(object) typedef uint64_t object;
    #endif
#endif

where handle types like as VkDisplayKHR are defined as such:

VK_DEFINE_NON_DISPATCHABLE_HANDLE(VkDisplayKHR)

There is also the lack of the explicit spaceship operator in the list of "candidates" that should be defined in vulkan_handles.hpp:

template <typename T, typename std::enable_if<isVulkanHandleType<T>::value, int>::type = 0>
auto operator<=>( T const & lhs, T const & rhs )
{
  return static_cast<typename T::NativeType>( lhs ) <=> static_cast<typename T::NativeType>( rhs );
}

where NativeType will be VkDisplayKHR for example.

All in all, it is probably the std::enable_if that disables the spaceship operator for vk::DisplayKHR and others. I don't currently have a good setup for 32-bit linux builds and CI here only has Windows runners for 32-bit tests (which do actually succeed). Could you test whether the std::enable_if really does cause the issue? Or test manually setting VK_USE_64_BIT_PTR_DEFINES to either 0 or 1?

[sharadhr]

I don't currently have a good setup for 32-bit linux builds

Run

sudo apt-get install gcc-multilib g++-multilib

and pass -m32 to CFLAGS, CXXFLAGS, and LDFLAGS. Also set --target=i686-linux-gnu in CFLAGS and CXXFLAGS.

Probably best to set up a CMake toolchain file for this, given it is 'cross-compiling'.

[M2-TE]

Hm, couldn't reproduce the issue when compiling for a 32-bit target using either gcc or clang. The former also does not recognize --target=i686-linux-gnu, but the resulting binary for both was 32 bits. Will try compiling Kwin 6.90.0, as perhaps some flag combination is causing the issue.

[sharadhr]

The former also does not recognize --target=i686-linux-gnu

Ah, yes, sorry; that is a Clang-specific flag.

[theHamsta]

sudo apt-get install gcc-multilib g++-multilib

Probably easiest to set up the using the compiler aliases CC=i686-linux-gnu-gcc-15/CXX=i686-linux-gnu-g++-15 from apt install {g++,gcc}-<version>-i686-linux-gnu. This will also need a 32bit libvulkan build for the samples (I'm getting an error even with VULKAN_HPP_DISPATCH_LOADER_DYNAMIC=ON)

I could not repro with the build from our repo.

[Zamundaaa]

Could you test whether the std::enable_if really does cause the issue? Or test manually setting VK_USE_64_BIT_PTR_DEFINES to either 0 or 1?

I can try sometime next week. The 32 bit build failure wasn't on any dev system, but in the packaging builds of Fedora.

Will try compiling Kwin 6.90.0, as perhaps some flag combination is causing the issue.

KWin sets the options VULKAN_HPP_NO_EXCEPTIONS=1 VULKAN_HPP_ASSERT_ON_RESULT=void