Bug 1303289 - mapnik 3.0.9-10 not built with $RPM_OPT_FLAGS
Summary: mapnik 3.0.9-10 not built with $RPM_OPT_FLAGS
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: mapnik
Version: 24
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Tom Hughes
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks: DebugInfo 1279265
TreeView+ depends on / blocked
 
Reported: 2016-01-30 09:24 UTC by Ville Skyttä
Modified: 2016-04-15 15:44 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2016-04-15 15:35:45 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

Description Ville Skyttä 2016-01-30 09:24:30 UTC
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 10:17:08 UTC
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 10:51:12 UTC
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 10:57:30 UTC
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 12:28:32 UTC
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 15:25:13 UTC
fyi, you'll also want to replace the call to
qmake-qt4
in the .spec to use
%{qmake_qt4}
macro

Comment 6 Tom Hughes 2016-02-02 18:53:29 UTC
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 14:22:06 UTC
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

Comment 8 Rex Dieter 2016-04-15 15:35:45 UTC
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.

Comment 9 Tom Hughes 2016-04-15 15:44:00 UTC
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.