Bug 1303289 - mapnik 3.0.9-10 not built with $RPM_OPT_FLAGS
mapnik 3.0.9-10 not built with $RPM_OPT_FLAGS
Product: Fedora
Classification: Fedora
Component: mapnik (Show other bugs)
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Tom Hughes
Fedora Extras Quality Assurance
Depends On:
Blocks: DebugInfo 1279265
  Show dependency treegraph
Reported: 2016-01-30 04:24 EST by Ville Skyttä
Modified: 2016-04-15 11:44 EDT (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2016-04-15 11:35:45 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Ville Skyttä 2016-01-30 04:24:30 EST
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.
Comment 1 Tom Hughes 2016-01-30 05:17:08 EST
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?
Comment 2 Tom Hughes 2016-01-30 05:51:12 EST
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.
Comment 3 Ville Skyttä 2016-01-30 05:57:30 EST
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.
Comment 4 Tom Hughes 2016-01-30 07:28:32 EST
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.
Comment 5 Rex Dieter 2016-01-30 10:25:13 EST
fyi, you'll also want to replace the call to
in the .spec to use
Comment 6 Tom Hughes 2016-02-02 13:53:29 EST
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.
Comment 7 Jan Kurik 2016-02-24 09:22:06 EST
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:
Comment 8 Rex Dieter 2016-04-15 11:35:45 EDT
I'm assuming/hoping this is fixed since,

* Wed Mar  2 2016 Tom Hughes <tom@compton.nu> - 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.
Comment 9 Tom Hughes 2016-04-15 11:44:00 EDT
Yes, it should be fixed now, even if that changelog entry is semi-nonsensical...

Note You need to log in before you can comment on or make changes to this bug.