.rodata + position indepent code problems when building with BUILD_SHARED_LIBS=ON

[eliasdaler]

When I build my project with BUILD_SHARED_LIBS=ON, I get the following linking error:

/usr/bin/ld: edbr/third_party/vk-bootstrap/libvk-bootstrap.a(VkBootstrap.cpp.o): relocation R_X86_64_32 against `.rodata' can not be used when making a shared object; recompile with -fPIC
/usr/bin/ld: failed to set dynamic section sizes: bad value
collect2: error: ld returned 1 exit status
ninja: build stopped: subcommand failed.

The following the problem:

set_target_properties(vk-bootstrap PROPERTIES
    POSITION_INDEPENDENT_CODE ON
)

However, this makes me think: why is vk-boostrap marked as STATIC? I've tried compiling it as a shared library on Linux and didn't run into any issues. (For Windows build, you'd probably need dllimport/dllexport declspecs everywhere, though)

So I think either STATIC should be dropped from the add_library call or POSITION_INDEPENDENT_CODE should be set by default (not sure if it'll break something).

[charles-lunarg]

vk-bootstrap is intended to be a static library due to the nature of the library being a small 'utility'. Having it be a separate shared-library isn't providing any real benefit in my opinion (performance & flexibility)

Is BUILD_SHARED_LIBS=ON a requirement for you?

[eliasdaler]

I'm okay with vk-boostrap itself being a static lib, but I want my other libraries to be shared (the linking is much faster for me).

So I guess add_library(STATIC) is okay, but then vk--boostrap should probably set POSITION_INDEPENDENT_CODE=ON when BUILD_SHARED_LIBS is ON.

[charles-lunarg]

Thats understandable, happy to take a PR to add it or create such a PR.

[charles-lunarg]

Looks like we had the same idea.

I took a slightly different approach, I wonder if there is any semantic different?

Happy to take your PR, just curious your opinion.

[charles-lunarg]

Ah looking into POSITION_INDEPENDENT_CODE more, it seems that a static library needs to have it enabled to be linked into a shared library, which makes sense but wasn't obvious.

Which is why I prefer my PR because then you can forcibly set whether vk-bootstrap enables PIC directly, rather than have to set BUILD_SHARED_LIBS first.

[charles-lunarg]

Thanks for working with me to get the library into a better state! Now I understand what that error message is referring two and should be better able to fix it (either automatically in the code or through dialoging with them, like this issue).