I noticed that package-notes causes different %{__global_ldflags} between %prep and %build. This is causing a build failure with openmsx for Fedora 36: https://koji.fedoraproject.org/koji/taskinfo?taskID=82623076 With the error being: /usr/bin/ld: cannot open linker script file /builddir/build/BUILD/.package_note-openmsx-16.0-5.fc36.x86_64.ld: No such file or directory The problem is that openmsx uses its own buildsystem written in python and openmsx.spec does the following to generate config files for a "rpm" flavor for openmsx in %setup: """ cat > build/flavour-rpm.mk << EOF # Opt flags. CXXFLAGS+=%{optflags} -DNDEBUG LINK_FLAGS+=%{__global_ldflags} # Dont strip exe, let rpm do it and save debug info OPENMSX_STRIP:=false CATAPULT_STRIP:=false EOF """ This results in the troublesome: /builddir/build/BUILD/.package_note-openmsx-16.0-5.fc36.x86_64.ld path making it into build/flavour-rpm.mk, where as during %build the file actually gets generated as: /builddir/build/BUILD/openmsx-16.0/.package_note-openmsx-16.0-5.fc36.x86_64.ld I assume the issue is %setup is setting the openmsx-16.0 part of the path and that this is not set when the macros in the %prep step get expanded. For now I've fixed this by just moving the above generation of build/flavour-rpm.mk to %build. But I still thought you should be aware of this issue. At a minimum this issue should be documented somewhere.
Yes, this is a well-known issue without a good solution so far. In particular this prompted a cleanup to move all calls from %configure from %prep to %build. But calling %configure in %prep is wrong for other reasons, while saving link flags like you'd like to do here is OK and should work. I'll keep this open for now. I think it'd be easiest to enhance rpm to provide %buildsubdir earlier, or something equivalent.
This bites every PostgreSQL extension packages that I'm building . Any progress so far? Thanks! Devrim
This should be fixed with the new approach in #2099999.
This should be resolved with the new approach used in F37+. We'll not be changing the implementation in F36 though, since that'd be likely to cause regressions.