Failed test: pie test Test results: \n Hardened: cpp: FAIL: pie test because not built with '-Wl'-pie' (gcc/clang) or '-buildmode pie' (go) \n Hardened: cpp: FAIL: bind-now test because not linked with -Wl'-z'now \n Hardened: cc1: FAIL: pie test because not built with '-Wl'-pie' (gcc/clang) or '-buildmode pie' (go) \n Hardened: cc1: FAIL: bind-now test because not linked with -Wl'-z'now Applicable RPMs: cpp-11.2.1-7.4.el9.ppc64le.rpm; cpp-11.2.1-7.4.el9.s390x.rpm; cpp-11.2.1-7.4.el9.x86_64.rpm; gcc-11.2.1-7.4.el9.ppc64le.rpm; gcc-11.2.1-7.4.el9.s390x.rpm; gcc-11.2.1-7.4.el9.x86_64.rpm; gcc-c++-11.2.1-7.4.el9.ppc64le.rpm; gcc-c++-11.2.1-7.4.el9.s390x.rpm; gcc-c++-11.2.1-7.4.el9.x86_64.rpm; gcc-gfortran-11.2.1-7.4.el9.ppc64le.rpm; gcc-gfortran-11.2.1-7.4.el9.s390x.rpm; gcc-gfortran-11.2.1-7.4.el9.x86_64.rpm; gcc-offload-nvptx-11.2.1-7.4.el9.ppc64le.rpm; gcc-offload-nvptx-11.2.1-7.4.el9.x86_64.rpm; libgccjit-11.2.1-7.4.el9.i686.rpm; libgccjit-11.2.1-7.4.el9.ppc64le.rpm; libgccjit-11.2.1-7.4.el9.s390x.rpm; libgccjit-11.2.1-7.4.el9.x86_64.rpm; libstdc++-devel-11.2.1-7.4.el9.i686.rpm; libstdc++-devel-11.2.1-7.4.el9.ppc64le.rpm; libstdc++-devel-11.2.1-7.4.el9.s390x.rpm; libstdc++-devel-11.2.1-7.4.el9.x86_64.rpm; libtsan-11.2.1-7.4.el9.x86_64.rpm Recommendation: Please fix the build system for the package or else add a skip of tests to the rpminspect.yaml file. For more details please see https://sourceware.org/annobin/annobin.html/Test-pie.html and https://sourceware.org/annobin/annobin.html/Waiving-Hardened-Results.html#Waiving-Hardened-Results. Why this bug was filed: All packages in RHEL 9 built with gcc (g++, etc.) are required to use a common set of flags provided by the distribution. These flags turn on important security and performance features so it is critical that any package that lacks these flags be repaired. A scanning tool named annocheck, part of the annobin package, was used to scan RHEL 9 packages. This BZ was created because binary packages of this component with the mentioned NVRs were not built with the requisite flags for one or more RHEL 9 architectures. How to reproduce the failure: You could try running annocheck locally against your builds: https://developers.redhat.com/blog/2019/02/04/annocheck-examining-the-contents-of-binary-files. Annocheck resources: * annobin documentation: https://sourceware.org/annobin/annobin.html/index.html * annocheck on the customer portal: https://access.redhat.com/documentation/en-us/red_hat_developer_toolset/9/html/user_guide/chap-annobin Contacts: * Instant messaging: #tools on IRC * Email: use tools for generic questions. Otherwise, use go-tools and llvm-clang-list for Go and Clang/LLVM specific questions. * annobin-annocheck maintainer: Nick Clifton (nickc)
*** Bug 2044918 has been marked as a duplicate of this bug. ***
Ug. It looks like this is the problem: gcc/Makefile.in: # We don't want to compile the compilers with -fPIE, it make PCH fail. COMPILER += $(NO_PIE_CFLAGS) # Link with -no-pie since we compile the compiler with -fno-PIE. LINKER += $(NO_PIE_FLAG) the PCH note is no longer true (on trunk, anyway). I'll try --enable-default-pie. Thanks for noticing.
(In reply to Marek Polacek from comment #5) > Ug. It looks like this is the problem: > > gcc/Makefile.in: > # We don't want to compile the compilers with -fPIE, it make PCH fail. > COMPILER += $(NO_PIE_CFLAGS) > > # Link with -no-pie since we compile the compiler with -fno-PIE. > LINKER += $(NO_PIE_FLAG) > > the PCH note is no longer true (on trunk, anyway). > > I'll try --enable-default-pie. This is (of course) not an option here. I've tried sed -i 's/ @NO_PIE_FLAG@//' gcc/Makefile.in sed -i 's/ @NO_PIE_CFLAGS@//' gcc/Makefile.in but that still doesn't produce PIE binaries. Not sure what to do here.
Not going to be ready today.
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory (new packages: gcc), and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHBA-2022:3966