The cross-gcc package is using %global srcdir gcc-%{version}-%{DATE} Source0: %{srcdir}.tar.xz %setup -q -n %{srcdir} -c cd %{srcdir} ... which worked fine until the last build when rpm 4.19.92 has been used. From the build.logs is clear that handling of %setup is completely different. See https://src.fedoraproject.org/rpms/cross-gcc/blob/rawhide/f/cross-gcc.spec#_270 for the spec file. ... Start: rpmbuild cross-gcc-14.1.1-1.fc41.1.src.rpm Building target platforms: aarch64 Building for target aarch64 setting SOURCE_DATE_EPOCH=1721174400 Executing(%mkbuilddir): /bin/sh -e /var/tmp/rpm-tmp.f1HpC5 + umask 022 + cd /builddir/build/BUILD/cross-gcc-14.1.1-build/gcc-14.1.1-20240508 /var/tmp/rpm-tmp.f1HpC5: line 33: cd: /builddir/build/BUILD/cross-gcc-14.1.1-build/gcc-14.1.1-20240508: No such file or directory compared to Building target platforms: x86_64 Building for target x86_64 setting SOURCE_DATE_EPOCH=1715558400 Executing(%prep): /bin/sh -e /var/tmp/rpm-tmp.QE22kf + umask 022 + cd /builddir/build/BUILD + cd /builddir/build/BUILD + rm -rf gcc-14.1.1-20240508 + /usr/bin/mkdir -p gcc-14.1.1-20240508 + cd gcc-14.1.1-20240508 + /usr/lib/rpm/rpmuncompress -x /builddir/build/SOURCES/gcc-14.1.1-20240508.tar.xz + STATUS=0 ... in the last successful build (https://koji.fedoraproject.org/koji/buildinfo?buildID=2451537) using rpm 4.19.1. Reproducible: Always
Most likely this: > %global builddir %{_builddir}/%{srcdir} %builddir is a rpm-defined macro in >= 4.20 and redefining it to something else will break stuff. Rename that to "mybuilddir" or something.
yes, renaming builddir solves the issue, thanks for the hint
Ack, thanks for confirming. Ideally you'd get a meaningful warning/error message when trying to override system macros of course - and you actually do for built-in macros (eg you can't override %define), but there's nothing like that for others at the moment.
Thanks, I was going to suggest something like that about emitting a warning in such cases, like for example the C/GCC preprocessor does about redefined macros.
Yup. Unlike C preprocessor macros, rpm macros are by design stackable and tons of functionality depends on that behavior, so we can't just error/warn on any macro redefinition. There'd need to be some "read-only" (or non-stackable) attribute that can be applied to some carefully selected macros. And now I remember there actually is a related ticket already: https://github.com/rpm-software-management/rpm/issues/2314