Closed robUx4 closed 1 month ago
Hi,
Thanks for the PR. Seeing the nature of it, I'm curious as to why I haven't had problems without this before. Can you explain a bit what libraries libssp would need?
I also don't understand how it worked before for us. I got this issue when I enable Link Time Optimization (-flto). Then for some reason it required this library to be present to really probe what code is used and what code is not.
More background on how we picked this issue in VLC. We enable stack protection on all code we build. So libssp.a was linked with the DLL using libFLAC. But when enabling LTO libssp.a
was not detected properly and not used. Then our DLL using libFLAC wouldn't link anymore because it didn't know it needed libssp.a
.
This seems correct for CMake: there the static version of libssp is only used when working with mingw, and therefore the addition to pkg-config is only done for mingw. However, the autotools patch does it for all platforms, not just mingw. Also, in autotools that static linking isn't enfored for mingw either.
Now I'm not really sure what to do. Maybe forcing static linking of libssp is a bad thing altogether. Any ideas?
Libs.private
is only used when using pkg-config --static
so people using a dynamic library version will not be affected, even if you put the wrong value in there.
However for autotools it's true that -lssp
will be added even though it's probably not needed and may not even link properly.
I removed the autotools variant. XIPH_GCC_STACK_PROTECTOR
is actually testing linking works. It will fail because -lssp
is not used. To be able to use strong stack protection in this case, this macro needs to be modified and export what linker flags need to be used.
Thanks!
.a
files in MinGW don't list the other static libraries they depend on. We need to provide it through the pkg-config file.