[gcc r15-4290] bootstrap: Fix genmatch build where system gcc defaults to -fPIE -pie

[Jakub Jelinek via Gcc-cvs]

https://gcc.gnu.org/g:5cf85a2fa38115b3fff2d0d7cd0770bef10f439b

commit r15-4290-g5cf85a2fa38115b3fff2d0d7cd0770bef10f439b
Author: Jakub Jelinek <ja...@redhat.com>
Date:   Sat Oct 12 13:47:45 2024 +0200

    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  <ja...@redhat.com>
    
            * Makefile.in (LINKER_FOR_BUILD): Append -no-pie if it is in
            $(LD_PICFLAG) when building build/genmatch.

Diff:
---
 gcc/Makefile.in | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/gcc/Makefile.in b/gcc/Makefile.in
index 38bdb7667c93..b7735908de7a 100644
--- a/gcc/Makefile.in
+++ b/gcc/Makefile.in
@@ -3145,6 +3145,11 @@ build/genmatch$(build_exeext): BUILD_LIBDEPS += 
$(LIBINTL_DEP) $(LIBICONV_DEP)
 build/genmatch$(build_exeext): BUILD_LIBS += $(LIBINTL) $(LIBICONV)
 endif
 
+# genmatch links in libcommon.a, which could have been compiled with
+# $(PICFLAG) set to -fno-PIE.  Make sure to link genmatch with -no-pie
+# in that case.
+build/genmatch$(build_exeext): LINKER_FOR_BUILD += $(findstring 
-no-pie,$(LD_PICFLAG))
+
 build/genmatch$(build_exeext) : $(BUILD_CPPLIB) \
   build/vec.o build/hash-table.o build/sort.o libcommon.a \
   $(LIBBACKTRACE)