EQMG/Acid

Ubuntu: Linker issue when linking against a system installed libSPIRV

warrantyvoids opened this issue · 5 comments

When building on linux (Ubuntu 18.04), libAcid.so fails to link against any of the test programs.

The error message says:
../../../../lib/libAcid.so: undefined reference to glslang::TPoolAllocator::allocate(unsigned long)' ../../../../lib/libAcid.so: undefined reference to glslang::TPoolAllocator::push()'
../../../../lib/libAcid.so: undefined reference to glslang::TProgram::~TProgram()' ../../../../lib/libAcid.so: undefined reference to glslang::GetKhronosToolId()'
.... (ommitted for brevity) ....

So, I will make a PR for this. But I might need somebody to confirm I don't break things on other platforms.

This seems to be caused by the fact that these symbols are defined in libglslang, not libSPIRV. However, libglsl is a transitive dependency of libSPIRV. I assume this works when libSPIRV is not found, the sources are fetched and are build locally, due to CMake correctly concluding that libglsl is needed as well.

From what I have seen on Linux system Glslang/SPIRV libs appear to not function properly on runtime either, besides the linking errors #29 also occurs. I'll test what you change in your PR on my Windows and macOS systems.

Hmm, they seem to (mostly) work here. Both from building from sources as well as linking against system libs.

For now, I don't have CTest running properly, as I'm still facing some other problems to run the test programs (mostly that I need to specify LD_LIBRARY_PATH). For now, TestPBR and TestPhysics do not run properly (consistently) on my machine with the system-wide install, but the other test programs do. However, I do see some serious warnings of shaders, do I assume those are to blame here.

(FYI: When they don't run properly, the seems to be no updates pushed to the screen. Perhaps something is either wrong in the presenting or dispatched to the wrong queue. I will investigate after this I think)

Okay, the problems with TestPBR and TestPhysics seem to be caused by GLSLang always returning that uniforms are not write-only. This seems to be vaguely related to #29, but since I'm running v2019.2, I can't directly reproduce that one.