diff mbox series

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

Message ID ZwpIj9A0A5UaFFKl@tucnak
State New
Headers show
Series bootstrap: Fix genmatch build where system gcc defaults to -fPIE -pie | expand

Commit Message

Jakub Jelinek Oct. 12, 2024, 9:59 a.m. UTC 
Hi!

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.

Ok for trunk to unbreak trunk?

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.


	Jakub

Comments

Richard Biener Oct. 12, 2024, 11:45 a.m. UTC | #1 
> Am 12.10.2024 um 12:00 schrieb Jakub Jelinek <jakub@redhat.com>:
> 
> Hi!
> 
> 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.
> 
> Ok for trunk to unbreak trunk?

Ok

Richard 

> 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.
> 
> --- gcc/Makefile.in.jj    2024-10-12 10:50:41.054854533 +0200
> +++ gcc/Makefile.in    2024-10-12 11:47:03.126827883 +0200
> @@ -3145,6 +3145,11 @@ build/genmatch$(build_exeext): BUILD_LIB
> 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)
> 
>    Jakub
>
diff mbox series

Patch

--- gcc/Makefile.in.jj	2024-10-12 10:50:41.054854533 +0200
+++ gcc/Makefile.in	2024-10-12 11:47:03.126827883 +0200
@@ -3145,6 +3145,11 @@  build/genmatch$(build_exeext): BUILD_LIB
 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)