Find Vulkan on 32 bit builds

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Find Vulkan on 32 bit builds

Saad Khattak
Hello,

When I run "find_package(VULKAN)" in a CMakeLists for a Visual Studio 2015 32-bit project, the ${Vulkan_LIBRARY} and ${Vulkan_LIBRARIES} variables both point to the "Bin" folder for the Vulkan installation instead of the "Bin32" folder.

I looked at the FindVulkan.cmake module and even put MESSAGE(STATUS ...) on the "elseif(CMAKE_SIZEOF_VOID_P EQUAL 4)" to see if I made a mistake setting up. The message does indeed print confirming that my pointer size is 4 and thus the current toolchain selected is 32 bit. 

What's perplexing is that when I do a MESSAGE(STATUS ${Vulkan_LIBRARY}) the path is:


D:/VulkanSDK/1.0.37.0/Bin/vulkan-1.lib


instead of


D:/VulkanSDK/1.0.37.0/Bin32/vulkan-1.lib


It makes no sense. Line 47 of FindVulkan.cmake has Bin32. Why is CMake ignoring 32?


--

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Find Vulkan on 32 bit builds

Andreas Naumann
Hello,
Am 08.01.2017 um 07:22 schrieb Saad Khattak:

> Hello,
>
> When I run "find_package(VULKAN)" in a CMakeLists for a Visual Studio
> 2015 32-bit project, the ${Vulkan_LIBRARY} and ${Vulkan_LIBRARIES}
> variables both point to the "Bin" folder for the Vulkan installation
> instead of the "Bin32" folder.
>
> I looked at the FindVulkan.cmake module and even put MESSAGE(STATUS
> ...) on the "elseif(CMAKE_SIZEOF_VOID_P EQUAL 4)" to see if I made a
> mistake setting up. The message does indeed print confirming that my
> pointer size is 4 and thus the current toolchain selected is 32 bit.
>
> What's perplexing is that when I do a MESSAGE(STATUS
> ${Vulkan_LIBRARY}) the path is:
>
>
> D:/VulkanSDK/1.0.37.0/Bin/vulkan-1.lib <http://1.0.37.0/Bin/vulkan-1.lib>
>
>
> instead of
>
>
> D:/VulkanSDK/1.0.37.0/Bin32/vulkan-1.lib
> <http://1.0.37.0/Bin32/vulkan-1.lib>
>
>
> It makes no sense. Line 47 of FindVulkan.cmake has Bin32. Why is CMake
> ignoring 32?
>
You should think the other way around: Why should cmake look in a
special directory, when it finds a library with an appropriate name
before this one?
This decision should be in the corresponding FindVulkan.cmake, i.e. the
corresponding find_library call should be constrained to
${VULKAN_DIR}/Bin32 in the 32bit case.
>
>

Regards,
Andreas
--

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Find Vulkan on 32 bit builds

Matthäus G. Chajdas
Hi,

the problem here is that the Vulkan SDK helpfully adds
D:/VulkanSDK/1.0.37.0/Bin into PATH, while the Vulkan module dutifully
searches Bin on x64 and Bin32 on x86. However, because /Bin is in the
PATH, and because the libraries for both architectures are named the
same, it will pick up the one from /Bin first (as the search order for
find_library is system paths first, and PATHS/HINTS variable second).

There's a couple of ways to fix this; for instance, on Windows I could
use NO_DEFAULT_PATH on the find_library call and that would resolve the
issue. The main reason why I haven't done this yet is because I think
that's a packaging bug in the Vulkan SDK side which I was going to
report there (I want to ask them to move the libraries into a lib/
subfolder, and ideally use different names for different architectures.)

For now the easiest workaround is to remove the path to the Vulkan SDK
from PATH; and I'll try to report this with the LunarG SDK and see how
far I get there. If this doesn't work out, I'll guess I'll have to
special-case the find_library call to ignore default paths on Windows &
32-bit only.

If this is a blocker for you, please file an issue and I'll fix it on
the CMake end before even starting the discussion with LunarG.

Cheers,
  Matthäus

Am 08.01.2017 um 14:36 schrieb Andreas Naumann:

> Hello,
> Am 08.01.2017 um 07:22 schrieb Saad Khattak:
>> Hello,
>>
>> When I run "find_package(VULKAN)" in a CMakeLists for a Visual Studio
>> 2015 32-bit project, the ${Vulkan_LIBRARY} and ${Vulkan_LIBRARIES}
>> variables both point to the "Bin" folder for the Vulkan installation
>> instead of the "Bin32" folder.
>>
>> I looked at the FindVulkan.cmake module and even put MESSAGE(STATUS
>> ...) on the "elseif(CMAKE_SIZEOF_VOID_P EQUAL 4)" to see if I made a
>> mistake setting up. The message does indeed print confirming that my
>> pointer size is 4 and thus the current toolchain selected is 32 bit.
>>
>> What's perplexing is that when I do a MESSAGE(STATUS
>> ${Vulkan_LIBRARY}) the path is:
>>
>>
>> D:/VulkanSDK/1.0.37.0/Bin/vulkan-1.lib <http://1.0.37.0/Bin/vulkan-1.lib>
>>
>>
>> instead of
>>
>>
>> D:/VulkanSDK/1.0.37.0/Bin32/vulkan-1.lib
>> <http://1.0.37.0/Bin32/vulkan-1.lib>
>>
>>
>> It makes no sense. Line 47 of FindVulkan.cmake has Bin32. Why is CMake
>> ignoring 32?
>>
> You should think the other way around: Why should cmake look in a
> special directory, when it finds a library with an appropriate name
> before this one?
> This decision should be in the corresponding FindVulkan.cmake, i.e. the
> corresponding find_library call should be constrained to
> ${VULKAN_DIR}/Bin32 in the 32bit case.
>>
>>
>
> Regards,
> Andreas

--

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Find Vulkan on 32 bit builds

Saad Khattak
That makes sense! Removing the variable from PATH does indeed fix the issue.

It is not a blocking issue for me.  

I agree that this is a Vulkan packaging issue. However, since you are looking for $ENV{VULKAN_SDK} in the find module and assuming it exists, then it 'should' override the other path? I do see what you are saying in that this now becomes a special case just because Vulkan SDK didn't package the libs properly.

Thanks Matthäus and Andreas for your help!

On Tue, Jan 10, 2017 at 10:38 AM Matthäus G. Chajdas <[hidden email]> wrote:
Hi,

the problem here is that the Vulkan SDK helpfully adds
D:/VulkanSDK/1.0.37.0/Bin into PATH, while the Vulkan module dutifully
searches Bin on x64 and Bin32 on x86. However, because /Bin is in the
PATH, and because the libraries for both architectures are named the
same, it will pick up the one from /Bin first (as the search order for
find_library is system paths first, and PATHS/HINTS variable second).

There's a couple of ways to fix this; for instance, on Windows I could
use NO_DEFAULT_PATH on the find_library call and that would resolve the
issue. The main reason why I haven't done this yet is because I think
that's a packaging bug in the Vulkan SDK side which I was going to
report there (I want to ask them to move the libraries into a lib/
subfolder, and ideally use different names for different architectures.)

For now the easiest workaround is to remove the path to the Vulkan SDK
from PATH; and I'll try to report this with the LunarG SDK and see how
far I get there. If this doesn't work out, I'll guess I'll have to
special-case the find_library call to ignore default paths on Windows &
32-bit only.

If this is a blocker for you, please file an issue and I'll fix it on
the CMake end before even starting the discussion with LunarG.

Cheers,
  Matthäus

Am 08.01.2017 um 14:36 schrieb Andreas Naumann:
> Hello,
> Am 08.01.2017 um 07:22 schrieb Saad Khattak:
>> Hello,
>>
>> When I run "find_package(VULKAN)" in a CMakeLists for a Visual Studio
>> 2015 32-bit project, the ${Vulkan_LIBRARY} and ${Vulkan_LIBRARIES}
>> variables both point to the "Bin" folder for the Vulkan installation
>> instead of the "Bin32" folder.
>>
>> I looked at the FindVulkan.cmake module and even put MESSAGE(STATUS
>> ...) on the "elseif(CMAKE_SIZEOF_VOID_P EQUAL 4)" to see if I made a
>> mistake setting up. The message does indeed print confirming that my
>> pointer size is 4 and thus the current toolchain selected is 32 bit.
>>
>> What's perplexing is that when I do a MESSAGE(STATUS
>> ${Vulkan_LIBRARY}) the path is:
>>
>>
>> D:/VulkanSDK/1.0.37.0/Bin/vulkan-1.lib <http://1.0.37.0/Bin/vulkan-1.lib>
>>
>>
>> instead of
>>
>>
>> D:/VulkanSDK/1.0.37.0/Bin32/vulkan-1.lib
>> <http://1.0.37.0/Bin32/vulkan-1.lib>
>>
>>
>> It makes no sense. Line 47 of FindVulkan.cmake has Bin32. Why is CMake
>> ignoring 32?
>>
> You should think the other way around: Why should cmake look in a
> special directory, when it finds a library with an appropriate name
> before this one?
> This decision should be in the corresponding FindVulkan.cmake, i.e. the
> corresponding find_library call should be constrained to
> ${VULKAN_DIR}/Bin32 in the 32bit case.
>>
>>
>
> Regards,
> Andreas


--

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Find Vulkan on 32 bit builds

Rolf Eike Beer
In reply to this post by Matthäus G. Chajdas
> There's a couple of ways to fix this; for instance, on Windows I could
> use NO_DEFAULT_PATH on the find_library call and that would resolve the
> issue. The main reason why I haven't done this yet is because I think
> that's a packaging bug in the Vulkan SDK side which I was going to
> report there (I want to ask them to move the libraries into a lib/
> subfolder, and ideally use different names for different
> architectures.)

Ideally they would just provide CMake config files then…

Eike
--

--

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Find Vulkan on 32 bit builds

Matthäus G. Chajdas
In reply to this post by Saad Khattak
Hi,

I've filed a bug report with LunarG. The issue is here:
https://vulkan.lunarg.com/issue/view/587509589ab0fa2af19621ca

In the meantime, I'll prepare an update which can handle /lib, /lib32
and adds the NO_DEFAULT_PATH in case of 32-bit Windows. Thanks for the
report!

Cheers,
  Matthäus

Am 10.01.2017 um 17:11 schrieb Saad Khattak:

> That makes sense! Removing the variable from PATH does indeed fix the issue.
>
> It is not a blocking issue for me.  
>
> I agree that this is a Vulkan packaging issue. However, since you are
> looking for $ENV{VULKAN_SDK} in the find module and assuming it exists,
> then it 'should' override the other path? I do see what you are saying
> in that this now becomes a special case just because Vulkan SDK didn't
> package the libs properly.
>
> Thanks Matthäus and Andreas for your help!
>
> On Tue, Jan 10, 2017 at 10:38 AM Matthäus G. Chajdas <[hidden email]
> <mailto:[hidden email]>> wrote:
>
>     Hi,
>
>     the problem here is that the Vulkan SDK helpfully adds
>     D:/VulkanSDK/1.0.37.0/Bin <http://1.0.37.0/Bin> into PATH, while the
>     Vulkan module dutifully
>     searches Bin on x64 and Bin32 on x86. However, because /Bin is in the
>     PATH, and because the libraries for both architectures are named the
>     same, it will pick up the one from /Bin first (as the search order for
>     find_library is system paths first, and PATHS/HINTS variable second).
>
>     There's a couple of ways to fix this; for instance, on Windows I could
>     use NO_DEFAULT_PATH on the find_library call and that would resolve the
>     issue. The main reason why I haven't done this yet is because I think
>     that's a packaging bug in the Vulkan SDK side which I was going to
>     report there (I want to ask them to move the libraries into a lib/
>     subfolder, and ideally use different names for different architectures.)
>
>     For now the easiest workaround is to remove the path to the Vulkan SDK
>     from PATH; and I'll try to report this with the LunarG SDK and see how
>     far I get there. If this doesn't work out, I'll guess I'll have to
>     special-case the find_library call to ignore default paths on Windows &
>     32-bit only.
>
>     If this is a blocker for you, please file an issue and I'll fix it on
>     the CMake end before even starting the discussion with LunarG.
>
>     Cheers,
>       Matthäus
>
>     Am 08.01.2017 um 14:36 schrieb Andreas Naumann:
>     > Hello,
>     > Am 08.01.2017 um 07:22 schrieb Saad Khattak:
>     >> Hello,
>     >>
>     >> When I run "find_package(VULKAN)" in a CMakeLists for a Visual Studio
>     >> 2015 32-bit project, the ${Vulkan_LIBRARY} and ${Vulkan_LIBRARIES}
>     >> variables both point to the "Bin" folder for the Vulkan installation
>     >> instead of the "Bin32" folder.
>     >>
>     >> I looked at the FindVulkan.cmake module and even put MESSAGE(STATUS
>     >> ...) on the "elseif(CMAKE_SIZEOF_VOID_P EQUAL 4)" to see if I made a
>     >> mistake setting up. The message does indeed print confirming that my
>     >> pointer size is 4 and thus the current toolchain selected is 32 bit.
>     >>
>     >> What's perplexing is that when I do a MESSAGE(STATUS
>     >> ${Vulkan_LIBRARY}) the path is:
>     >>
>     >>
>     >> D:/VulkanSDK/1.0.37.0/Bin/vulkan-1.lib
>     <http://1.0.37.0/Bin/vulkan-1.lib> <http://1.0.37.0/Bin/vulkan-1.lib>
>     >>
>     >>
>     >> instead of
>     >>
>     >>
>     >> D:/VulkanSDK/1.0.37.0/Bin32/vulkan-1.lib
>     <http://1.0.37.0/Bin32/vulkan-1.lib>
>     >> <http://1.0.37.0/Bin32/vulkan-1.lib>
>     >>
>     >>
>     >> It makes no sense. Line 47 of FindVulkan.cmake has Bin32. Why is
>     CMake
>     >> ignoring 32?
>     >>
>     > You should think the other way around: Why should cmake look in a
>     > special directory, when it finds a library with an appropriate name
>     > before this one?
>     > This decision should be in the corresponding FindVulkan.cmake,
>     i.e. the
>     > corresponding find_library call should be constrained to
>     > ${VULKAN_DIR}/Bin32 in the 32bit case.
>     >>
>     >>
>     >
>     > Regards,
>     > Andreas
>

--

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake
Loading...