I have been trying to build an RPM package on Fedora 44 using the following command:
rpmbuild -bb out/amd/amd-kria-k26.spec
RSB fails while building aarch64-rtems7-gcc-15.2.0-newlib-a7c61498-x86_64-linux-gnu-1.
Here is the log file.
Surprisingly, this only happens when RSB is invoked by rpmbuild from the given spec file with these arguments:
--prefix=/opt/rtems/7 --bset-tar-file --trace --log=out/amd/amd-kria-k26.txt --no-install amd/amd-kria-k26
However, using ./waf --target=amd/amd-kria-k26 successfully builds a tar package in the tar/ directory.
What gcc version does Fedora 44 have?
Does the log for the way that works include a -std= argument when compiling this file?
If you change the defaults.mc file to specify gnu++14 instead of gnu++17 does it work?
I don’t know why it would be different between the two ways of building. @kiwichris needs to answer that.
GCC version: 16.1.1
From the log of the working build:
Command Line: /home/me/Code/RTEMS/src/rsb/source-builder/sb-set-builder --prefix=/opt/rtems/7 --bset-tar-file --trace --log=out/amd/amd-kria-k26.txt --no-install amd/amd-kria-k26
The command line is the same for both the working and non-working cases.
And yes the working way’s log include a -std= argument for almost every compiler call.
Changing gnu++17 to gnu++14 in defaults.mc causes packages such as dtc to fail to compile.
I wonder if rpmbuild puts something in the environment that effects the build? I am lost for a reason the build works on the command and fails when running rpmbuild.
I found that when rpmbuild invokes RSB,
-Werror=format-security flag is enabled while compiling aarch64-rtems7-gcc-15.2.0-newlib-a7c61498-x86_64-linux-gnu-1. However that is not the case with RSB getting invoked via ./waf --target=amd/amd-kria-k26.
../../../gcc-15.2.0/libcpp/macro.cc: In member function 'vaopt_state::update_type vaopt_state::update(const cpp_token*)':
../../../gcc-15.2.0/libcpp/macro.cc:185:26: error: format not a string literal and no format arguments [-Werror=format-security]
185 | cpp_error_at (m_pfile, CPP_DL_ERROR, token->src_loc,
| ~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
186 | vaopt_paste_error);
| ~~~~~~~~~~~~~~~~~~
../../../gcc-15.2.0/libcpp/macro.cc:214:34: error: format not a string literal and no format arguments [-Werror=format-security]
214 | cpp_error_at (m_pfile, CPP_DL_ERROR, token->src_loc,
| ~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
215 | vaopt_paste_error);
| ~~~~~~~~~~~~~~~~~~
checking whether fgetc_unlocked is declared... yes
../../../gcc-15.2.0/libcpp/macro.cc: In function 'cpp_macro* create_iso_definition(cpp_reader*)':
../../../gcc-15.2.0/libcpp/macro.cc:3811:25: error: format not a string literal and no format arguments [-Werror=format-security]
3811 | cpp_error (pfile, CPP_DL_ERROR, paste_op_error_msg);
| ~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
../../../gcc-15.2.0/libcpp/macro.cc:3826:25: error: format not a string literal and no format arguments [-Werror=format-security]
3826 | cpp_error (pfile, CPP_DL_ERROR, paste_op_error_msg);
| ~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Invoking rsb from commandline also succeeds.
Both rpmbuild and dpkg-buildpackage inject flags like -Werror=format-security into the environment.
Clearing the flags in debian/rules fixes Debian completely, but doing the same thing in RPM’s %build block backfires. Stripping those variables confuses Waf’s compiler resolution; it ends up losing track of the target toolchain and tries to compile the AArch64 kernel using the host’s native gcc.
Can’t we use waf to build tar archives and use rpmbuild and dpkg-buildpackage to just package it? That would allow the actual compilation to be done without any distro-dependent shenanigans.
the best solution would be for us to build with -Werror=format-security and fix those build failures. @JoelSherrill ?
Since this is in GCC’s libcpp, I would think it should at least get reported and I am sure they would appreciate a fix.
I’d be prone to disable werror if there is a configure option for that.
I have wondered if we will ultimately need different -std= settings for individual packages. dtc appears to need newer than gnu++14. @kiwichris How would we set the -std just for that? Would it impact other packages?
I think finding what is injecting the flags that make deployment builds different from manual RSB builds is the first task. It isn’t good that they differ.
I think both paths are valid. We should look to support the flag however making it part of this effort seems out of scope.