VK_LOADER_DEBUG should report actual library loaded, not library attempted

[lunarpapillo]

We found a case on macOS where the loader reported, via VK_LOADER_DEBUG=all, that the repository build of libVkLayer_khronos_validation.dylib was loaded for a particular test run:

DRIVER | LAYER:   vkCreateDevice layer callstack setup to:
DRIVER | LAYER:      <Application>
DRIVER | LAYER:        ||
DRIVER | LAYER:      <Loader>
DRIVER | LAYER:        ||
LAYER:               VK_LAYER_KHRONOS_validation
LAYER:                       Type: Explicit
LAYER:                       Manifest: /Users/lunarg/.jenkins/mz3/Vulkan-ValidationLayers/build/layers/VkLayer_khronos_validation.json
LAYER:                       Library:  /Users/lunarg/.jenkins/mz3/Vulkan-ValidationLayers/build/layers/./libVkLayer_khronos_validation.dylib
LAYER:                 ||
DRIVER | LAYER:      <Device>

when the actual library loaded, according to DYLD_PRINT_LIBRARIES=1, was from /usr/local/lib:

dyld[71457]: <AFEA288A-BA17-36E2-BA23-60CDE2A98664> /usr/local/lib/libVkLayer_khronos_validation.dylib

This inconsistency is misleading and made it difficult to debug.

The library reported by the Vulkan loader should be the actual library loaded, not the library attempted.

See https://stackoverflow.com/questions/20481058/find-pathname-from-dlopen-handle-on-osx for information on the (sadly, quite complicated) process required to reliably get this information on a Mac.

[charles-lunarg]

I'm going to remove the bug label, because the loader is printing the path it used to load the library, and that is exactly it is suppose to do with the current implementation. It would be an enhancement to make the loader ask the dynamic linker the actual path to the library. And it doesn't help that I believe only on macOS is there this behavior that takes an absolute/relative path and completely ignores it, which is just unhelpful.

[charles-lunarg]

A quick search reveals that dladdr() exists on linux & macOS, so wouldn't be too difficult to get the path that was actually loaded. And a further search shows GetModuleFileNameA exists and is used by the loader (just not for this purpose).

So theoretically, there isn't too much stopping the 'real' path from being printed. It would be much nicer than the limited info that a system library path has, eg libfoo.so.