Declaring vk*() symbols at global scope is illegal about volk HOT 5 CLOSED

In C++ this can be namespaced away but in C it can't. I can probably change this to use namespace volk + using namespace volk for C++, but this will make compilation awkward.

OTOH I don't see why this would be a problem, unless you link to libvulkan.so - which defeats the purpose of this library. Is there a practical case where this would break something?

from volk.

I've had cases where the loader would find the symbols in the application rather than its own symbols creating infinite loops when calling certain things (something like LD_PRELOAD). It might be safe if dynamic visibility is forced to hidden or similar.

This happened even if you dlopen()-ed libvulkan.so and only used it for vkGetInstanceProcAddr.

from volk.

Yeah - that's a good point. I was thinking of symbol visibility but forgot to actually do something about it. Pushed a change to fix it. I'll keep this issue open for a bit since I'd like to actually test this library on Linux :) (it works on Windows and Android).

I'll also think about making this library C++ to avoid violating the spec; I don't see a good way to keep this C and stay compliant (although the change I submitted should hopefully make the non-compliance not a problem in practice)

from volk.

This seems to work for Linux; I'll assume for the time being the practical problem is solved and that "library symbols" might refer to exported/visible symbols only and close this :)

from volk.

FWIW one other issue I found when using volk is that the symbols defined by volk conflict with symbols defined by vulkan.h. This is not a problem if both are included in the same translation unit - volk.h will check that the usage is correct - but it is a problem if there's some translation unit that includes only vulkan.h, which is potentially problematic. Now, it does mean that even if this usage was safe, the application would have to link to vulkan.dll/so which is not a great idea, but still it can be an issue.

from volk.