Bug 2401434

Created attachment 2108403 [details]
use CC instead HOSTCC for maketab

Built with all Fedora local flags applied correctly:
"gcc" instead "cc". And "-g -Wall -pedantic -Wcast-qual" were removed.


before:
cc -g -Wall -pedantic -Wcast-qual -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 maketab.c -o maketab

after:
gcc -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 maketab.c -o maketab

That's because maketab is a build-time utility, and is used in cross-compiles.
I haven't seen that aspect addressed in the macros (perhaps some specific suggestion would help).

In any case, the proper fix for this would be in the spec file (not a patch),
because the configure script provides options which can be used to solve the problem.

configure --help shows this:

Cross-compiling
  --with-build-cc=XXX     the build C compiler ($BUILD_CC)
  --with-build-cpp=XXX    the build C preprocessor ($BUILD_CPP)
  --with-build-cflags=XXX the build C compiler-flags ($BUILD_CFLAGS)
  --with-build-cppflags=XXX the build C preprocessor-flags ($BUILD_CPPFLAGS)
  --with-build-ldflags=XXX the build linker-flags ($BUILD_LDFLAGS)
  --with-build-libs=XXX   the build libraries (${BUILD_LIBS})

(In reply to Thomas E. Dickey from comment #4)
> In any case, the proper fix for this would be in the spec file (not a patch),
> because the configure script provides options which can be used to solve the
> problem.
> 
> configure --help shows this:
> 
> Cross-compiling
>   --with-build-cc=XXX     the build C compiler ($BUILD_CC)
>   --with-build-cpp=XXX    the build C preprocessor ($BUILD_CPP)
>   --with-build-cflags=XXX the build C compiler-flags ($BUILD_CFLAGS)
>   --with-build-cppflags=XXX the build C preprocessor-flags ($BUILD_CPPFLAGS)
>   --with-build-ldflags=XXX the build linker-flags ($BUILD_LDFLAGS)
>   --with-build-libs=XXX   the build libraries (${BUILD_LIBS})

sorry - I read "nawk" as "mawk" :-(

Created attachment 2108718 [details]
fix using the spec file

trivial fixes in the spec-file are easier to maintain

FEDORA-2026-1000f4ab4e (nawk-20251225-2.fc42) has been submitted as an update to Fedora 42.
https://bodhi.fedoraproject.org/updates/FEDORA-2026-1000f4ab4e

Thanks for the fix for this Thomas and thanks for reporting it Xose. I somehow missed this and only noticed this bug was open when I was upgrade to a new version of nawk. The new RPM has the fix for this in it.

FEDORA-2026-1000f4ab4e has been pushed to the Fedora 42 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2026-1000f4ab4e`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2026-1000f4ab4e

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

FEDORA-2026-1000f4ab4e (nawk-20251225-2.fc42) has been pushed to the Fedora 42 stable repository.
If problem still persists, please make note of it in this bug report.