Build generates PIC even for static library
This is a remanent from the old cmake file.
For static lib build, and given that we do not use the same intermediary object files for shared and static, the archive library should be built without -fPIC.
I think the sharp edge here is a wrapper DLL or shared object. For this use case, this could happen:
- CMake builds
libcryptopp.awithout-fPIC - User creates a shared object, uses
-fPIC - User shared object links to
libcryptopp.a
The user will experience relocation errors when linking their shared object with libcryptopp.a.
I think the same could happen if the user built an executable linked against libcryptopp.a, and used -fPIC or -fPIE for position independent code (Unix & Linux) or ASLR (Windows):
- CMake builds
libcryptopp.awithout-fPIC - User creates a program, uses
-fPICor-fPIE - User program links to
libcryptopp.a
See Wrapper DLL on the Crypto++ wiki. And see https://www.google.com/search?q=ld+relocation+error+'-fPIC' (and the slew of answers that say "rebuild with -fPIC").
It is probably worth mentioning...
used -fPIC or -fPIE for position independent code (Unix & Linux) or ASLR (Windows)
ASLR was introduced by Microsoft in Windows XP. Utilizing ASLR has been part of the secure coding guide since at least the year 2000.
Position independent code has been part of Unix & Linux for years also. It became a recommendation around 2010 for secure coding Unix & Linux. In 2012 Android adopted it.
It is very unfortunate CMake does not enable it by default given it has been a standard option for over 10 years. Code that does not use position independent code or ASLR will fail a security audit nowadays.
Hmm… from a hardening point of view it makes sense.
Anyway, the only reason I thought it should be removed is that some distros require that archive libs should be built with no -fPIC.
I will make a specific test case for using wrapper DLL and a test case for -fPIE executable and document the scenarios clearly in the code if we decide to keep/remove -fPIC/-fPIE.