bootstrap: Fix genmatch build where system gcc defaults to -fPIE -pie

Seems our buildbot is unhappy about my latest commit to link genmatch with
libcommon.a in order to support gcc_diag diagnostics in libcpp.

We have in gcc/configure.ac:
if test x$enable_host_shared = xyes; then
  PICFLAG=-fPIC
elif test x$enable_host_pie = xyes; then
  PICFLAG=-fPIE
elif test x$gcc_cv_c_no_fpie = xyes; then
  PICFLAG=-fno-PIE
else
  PICFLAG=
fi

if test x$enable_host_pie = xyes; then
  LD_PICFLAG=-pie
elif test x$gcc_cv_no_pie = xyes; then
  LD_PICFLAG=-no-pie
else
  LD_PICFLAG=
fi

if test x$enable_host_bind_now = xyes; then
  LD_PICFLAG="$LD_PICFLAG -Wl,-z,now"
fi

Now, for object files linked into cc1, cc1plus, xgcc etc. we carefully
arrange for them to be compiled with $(PICFLAG) and do the link with
$(LD_PICFLAG).
For the generator programs, we don't do anything like that, we simply
compile their objects without $(PICFLAG) and link without $(LD_PICFLAG).
It isn't that big deal, the generator programs runs once or a couple of
times during the build and that is it, we don't ship them and don't
care much if they are PIE or not.
Except that after my changes to link in libcommon.a into build/genmatch,
we now link -fno-PIE compiled objects into a binary which is linked with
default flags.  Our distro compiler just links a normal executable and
everything works fine (-fPIE/-pie is added through spec file snippet and
just added in rpm default flags), but seems the buildbot system gcc
defaults to -fPIE -pie instead and so building build/genmatch fails.

The following patch is a minimal fix for that, just add -no-pie when
linking build/genmatch, but don't add -pie.

If we wanted to start building even the build/gen* tools with $(PICFLAG)
and $(LD_PICFLAG), that would be much larger change.

2024-10-12  Jakub Jelinek  <jakub@redhat.com>

	* Makefile.in (LINKER_FOR_BUILD): Append -no-pie if it is in
	$(LD_PICFLAG) when building build/genmatch.