mapnik 3.0.9-10 (nor -9) is no longer built with $RPM_OPT_FLAGS, see build logs and incomplete debuginfo. -8 did not have this problem.
I see nothing in http://pkgs.fedoraproject.org/cgit/rpms/mapnik.git/commit/?id=273d5e672be86246cfc942eb64c101a843e43343 that would cause the build flags to change (other than dropping the rpath from the link) so this seems to be a mystery. Maybe some change in another package has triggered it somehow?
I don't see any change in the flags in the logs between -8 and -9 in fact as best I can see none of the 3.x builds have been using the right flags.
Seeing that mapnik uses qt, I was from the start quite convinced that this was the result of bug 1279265 comment 13. But in skimming the commits and specfile I somehow missed the direct qmake-qt4 invocation in the specfile. So that is most likely part of the problem. However, I suppose there is more to it that might have been lurking there for a longer time, because the build does RPM_OPT_FLAGS tweaking with SConstruct, but apparently doing that doesn't affect the build in any way (the flags don't end up showing anywhere in the current build log). This should be investigated. (In reply to Tom Hughes from comment #2) > I don't see any change in the flags in the logs between -8 and -9 in fact as > best I can see none of the 3.x builds have been using the right flags. You seem to be right. Maybe the qmake thing has just been shadowing the issue until now.
Unfortunately it seems the builders can't cope when the compiler options are used - the x86 build died with: virtual memory exhausted: Operation not permitted scons: *** [src/renderer_common/process_group_symbolizer.os] Error 1 scons: building terminated because of errors.
fyi, you'll also want to replace the call to qmake-qt4 in the .spec to use %{qmake_qt4} macro
I've managed to build it with the right optimisation flags now, but I had to disable debug generation for the 32 bit platforms to avoid koji running out of memory. Upstream has already done some work to refactor the problem code so the compiler has an easier time with it so I'm hopeful that the next release will allow me to remove the bodge.
This bug appears to have been reported against 'rawhide' during the Fedora 24 development cycle. Changing version to '24'. More information and reason for this action is here: https://fedoraproject.org/wiki/Fedora_Program_Management/HouseKeeping/Fedora24#Rawhide_Rebase
I'm assuming/hoping this is fixed since, * Wed Mar 2 2016 Tom Hughes <tom> - 3.0.10-1 - Add upstream patch to reduce compile time memory usage - Re-enable debugging on x86 to stop koji running out of memory Feel free to re-open if that's not the case.
Yes, it should be fixed now, even if that changelog entry is semi-nonsensical...