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.
@kiwichris Since this blocks my GSoC work on adding Debian and FreeBSD support, how should I proceed with the packaging architecture now, or should I wait for fixes to the flag injection issue?
This is specific to rpmbuild so I am not sure how it relates to the other platforms?
Should I just continue my work on those platforms(i.e Debian and FreeBSD) then? Or should I first solve rpmbuild issues?
Also should I just remove -Werror=format-security wherever I encounter it in Debian or FreeBSD packaging?
-O2 -flto=auto -ffat-lto-objects -fexceptions -g -grecord-gcc-switches -pipe -Wall -Wno-complain-wrong-lang -Werror=format-security -Wp,-U_FORTIFY_SOURCE,-D_FORTIFY_SOURCE=3 -Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -march=x86-64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -mtls-dialect=gnu2 -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer
These are the optional flags enabled by rpm.
I suggest having a quick look to see if you can override these defaults. I would see if rpmbuild can dump the settings. If they are in a specific %define see if you can override it? Maybe a command line option exists to handle this?
And yes also work on the FreeBSD and Debian packages.
After removing -Werror=format-security, the build proceeds further but fails during the RTEMS kernel build for aarch64/k26. It appears rpmbuild is still injecting host compiler environment variables into Waf.
During configure, Waf reports:
Environment variable set : CC
Environment variable set : CFLAGS
Environment variable set : CXX
Environment variable set : CXXFLAGS
and also:
Checking for program 'gcc, cc' : gcc
Checking for program 'g++, c++' : g++
even though the RTEMS cross-toolchain is correctly detected:
aarch64-rtems7-gcc
aarch64-rtems7-g++
Build then fails with:
cc1: error: unrecognized command-line option ‘-mno-outline-atomics’
cc1: error: unrecognized command-line option ‘-mfix-cortex-a53-835769’
cc1: error: unrecognized command-line option ‘-mfix-cortex-a53-843419’
cc1: error: bad value ‘cortex-a53’ for ‘-mtune=’ switch
cc1: note: valid arguments to ‘-mtune=’ switch are: nocona core2 nehalem corei7 westmere sandybridge corei7-avx ivybridge core-avx-i haswell core-avx2 broadwell skylake skylake-avx512 cannonlake icelake-client rocketlake icelake-server cascadelake tigerlake cooperlake sapphirerapids emeraldrapids alderlake raptorlake meteorlake graniterapids graniterapids-d arrowlake arrowlake-s lunarlake pantherlake diamondrapids wildcatlake novalake bonnell atom silvermont slm goldmont goldmont-plus tremont gracemont sierraforest grandridge clearwaterforest intel x86-64 eden-x2 nano nano-1000 nano-2000 nano-3000 nano-x2 eden-x4 nano-x4 lujiazui yongfeng shijidadao k8 k8-sse3 opteron opteron-sse3 athlon64 athlon64-sse3 athlon-fx amdfam10 barcelona bdver1 bdver2 bdver3 bdver4 znver1 znver2 znver3 znver4 znver5 znver6 btver1 btver2 generic native
which suggests the host x86_64 GCC is being invoked with AArch64-specific flags (-mfix-cortex-a53-*, -mno-outline-atomics, -mtune=cortex-a53). It looks like rpmbuild is still leaking into %optflags / host architecture flags into the RTEMS cross-build environment.
Here is the full log.
I feel building tarballs directly via waf and then packaging them using distro-specific packagers would be a better choice. I suspect the same issue may happen in the FreeBSD packaging pipeline as well. What do you think?
This is great investigative work 
It does look like the env variables are leaking?
Can you clear them in the spec template file deployment uses to create the spec files?
I have tried doing that but the result is no different. RSB starts using host’s compilers even if I unset CC CFLAGS CXX CXXFLAGS RPM_OPT_FLAGS etc.
The command:
rpmbuild --showrc
should show you all the macros. Does that help show the issue?
FIXED!
rpmbuild was automatically injecting -march=x86_64, which caused the issue I mentioned in my last message. Unsetting the flags alone was not enough.
However,
%global _auto_set_build_flags 0
combined with:
%build
unset CC
unset CXX
unset CFLAGS
unset CXXFLAGS
unset CPPFLAGS
unset LDFLAGS
unset RPM_OPT_FLAGS
unset FFLAGS
unset FCFLAGS
unset AR
unset AS
unset LD
fixed the issue completely.
This introduced another problem, though: intermediate build files were being placed in /tmp, which is mounted as tmpfs (RAM) on my system (Fedora 44). I eventually ran out of free space during compilation.
❯ quota -s
Disk quotas for user me (uid 1000):
Filesystem space quota limit grace files quota limit grace
tmpfs 88K 6275M 6275M 2 0 0
tmpfs 888M 6275M 6275M 522 0 0
The compilation somehow exceeded 6275MB quota on RAM.
To fix this, I redirected TMP and related variables to a local directory on my SSD which has plethora of free storage:
export TMPDIR=%{rsb_work_path}/build/tmp
export TMP=%{rsb_work_path}/build/tmp
export TEMP=%{rsb_work_path}/build/tmp
I would probably move these to the shared abstraction wrapper (rtems-pkg) if possible
Here is the build output.
Well done on getting the build to work. Can you please make a MR for the RTEMS Deployment repo with the changes?
Is management of /tmp something we should do? I see that as an admin property for the host doing the building however I am happy to be guided on this?
