dnl CF_PIC_HACK version: 1 updated: 2019/12/22 19:53:26
dnl -----------
dnl First noticed in 2016, some systems have gcc configured with
dnl --enable-default-pie, which breaks linking of applications which do not
dnl explicitly specify the -static or the -shared options.  The linker advises
dnl using -fPIC when compiling.  That "works", but entails a performance
dnl penalty, and the configure script has to determine this before making any
dnl feature tests.
dnl
dnl With Fedora, this check is only needed when building using the "hardening"
dnl flags.  Without those, the linker has different behavior.
dnl
dnl Some background:
dnl https://wiki.gentoo.org/wiki/Hardened/Toolchain
dnl https://gcc.gnu.org/ml/gcc-patches/2014-07/msg02231.html
dnl https://stackoverflow.com/questions/6093547/what-do-r-x86-64-32s-and-r-x86-64-64-relocation-mean
dnl https://unix.stackexchange.com/questions/89211/how-to-test-whether-a-linux-binary-was-compiled-as-position-independent-code
AC_DEFUN([CF_PIC_HACK],[
AC_CACHE_CHECK(if -fPIC option is needed in CFLAGS,cf_cv_pic_hack,[
cf_cv_pic_hack=unknown
if test "$GCC" = yes
then
	if readelf --version >/dev/null 2>/dev/null
	then
		cat >conftest.$ac_ext <<EOF
#line __oline__ "configure"
#include <stdio.h>
int main(void) { FILE *fp = fopen("hello", "w"); return (fp != 0); }
EOF
		if AC_TRY_EVAL(ac_compile) ; then
			cf_cv_pic_hack=no
			for cf_pie_relocs in `readelf --relocs conftest.$ac_cv_objext | awk '[$]3~/^R_/ && [$]5!~/^\.debug/{print [$]3}'`
			do
				case "x$cf_pie_relocs" in
				xR_X86_64_32|xR_X86_64_32S)
					CF_MSG_LOG(found $cf_pie_relocs)
					cf_cv_pic_hack=yes
					break
					;;
				esac
			done
		else
			CF_MSG_LOG(cannot compile test-program)
		fi
		rm -f conftest.$ac_ext conftest.$ac_cv_objext
	fi
fi
])

if test "x$cf_cv_pic_hack" = xyes
then
	CF_ADD_CFLAGS(-fPIC)
fi
])dnl
