Would it be possible to use the 2.4 fork?
Have either you or mapnik tried to send changes to the fork upstream?
Alternately, would it be possible to apply mapnik's changes to the system agg package?

It seems like desmume, gnash, mapnik, and python-matplotlib are the only consumers of agg in Fedora.

I did talk to the Fedora maintainer for the agg package before filing this request and he was reluctant to switch to the 2.4 fork at the moment.

Equally while he was potentially open to taking some patches further review on my part suggested that there were a fair number of changes in the mapnik version that would make it tricky to establish exactly what the impact might be of carrying them all. The list of commits in question is:

https://github.com/mapnik/mapnik/commits/v2.1.0/deps/agg

some of them are both quite large and also quite significant - doing things like introducing a dependency on boost, for example:

https://github.com/mapnik/mapnik/commit/14d365d5724c3726d5cc9dc0d9adcea187ed2614#deps/agg

tomh, I'm considering carrying the mapnik patches, would you be willing to generate a patch/patches against 2.5 for the commits you need, so I can test?

I've been through all commits to the agg code in mapnik now, and built a git repo containing the necessary patches on top of a clean 2.4 tree, and then a rebased branch on top of 2.5, so the set of patches needed on top of 2.5 is here:

https://github.com/tomhughes/agg/commits/mapnik-2.5

There is one exception, which is the commit I mentioned before that adds a dependency on boost:

https://github.com/mapnik/mapnik/commit/14d365d5724c3726d5cc9dc0d9adcea187ed2614#deps/agg

That is not currently included in my patch set because, on closed inspection, it turns out that what it is actually dependent on is some boost extensions which, although in the boost repository, are not currently released as part of boost. Rather mapnik is carrying copies of those files, along with some other similar boost extensions for it's geojson plugin.

So the summary is that with the patches from my repository applied to agg, and with mapnik's geojson plugin and HSV transform support disabled, I can build mapnik 2.1 without any bundled code.

I made a patch from a diff of that vs include and src in 2.5 in rawhide, and it fails to build. Am I missing a step?

make[3]: Entering directory /home/limb/Desktop/mapnik/agg/agg-2.5/src/platform/X11' /bin/sh ../../../libtool --tag=CXX --mode=compile g++ -DHAVE_CONFIG_H -I. -I../../../include -I../../../include -I -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic -c -o libaggplatformX11_la-agg_platform_support.lotest -f 'agg_platform_support.cpp' || echo './'agg_platform_support.cpp libtool: compile: g++ -DHAVE_CONFIG_H -I. -I../../../include -I../../../include -I -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic -c agg_platform_support.cpp -fPIC -DPIC -o .libs/libaggplatformX11_la-agg_platform_support.o In file included from /usr/include/stdio.h:27:0, from agg_platform_support.cpp:25: /usr/include/features.h:330:4: warning: #warning _FORTIFY_SOURCE requires compiling with optimization (-O) [-Wcpp] agg_platform_support.cpp: In member function 'bool agg::platform_support::init(unsigned int, unsigned int, unsigned int)': agg_platform_support.cpp:583:70: warning: format '%x' expects argument of type 'unsigned int', but argument 3 has type 'long unsigned int' [-Wformat] agg_platform_support.cpp:583:70: warning: format '%x' expects argument of type 'unsigned int', but argument 4 has type 'long unsigned int' [-Wformat] agg_platform_support.cpp:583:70: warning: format '%x' expects argument of type 'unsigned int', but argument 5 has type 'long unsigned int' [-Wformat] /bin/sh ../../../libtool --tag=CXX --mode=link g++ -I../../../include -I -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic -version-info 2:4:0 -L@x_libraries@ -Wl,-z,relro -o libaggplatformX11.la -rpath /usr/lib64 libaggplatformX11_la-agg_platform_support.lo -lX11 ../../../libtool: line 6000: cd: @x_libraries@: No such file or directory libtool: link: cannot determine absolute directory name of@x_libraries@'

Well I had that when compiling directly due to the horridly out of date configure stuff. I had to pass --x-include and --x-libraries to configure. It worked OK building an rpm though.

Can give you a diff against the Fedora git if you want?

My patch so far.
agg-2.5-mapnik-th.patch

I've put a diff against Fedora git representing how I rebuilt the agg rpm for my tests at http://download.compton.nu/tmp/agg.patch

Thanks, github n00b. :) I'll see how it goes and let you know.

While I'm being needy, could you do the same for rawhide mapnik vs. your most recent update preparations against this agg? :)))))

Sure. I've put it up at http://download.compton.nu/tmp/agg.patch.

Found it at http://download.compton.nu/tmp/mapnik.patch, I'll check it out. Thanks!

So I took your patches to agg and mapnik, built them, installed them, and then built and installed gnash and python-matplotib. Based on the minimal testing I did, nothing seems to have broken. My only residual concern is whether the changes break compatibility in any way, and whether bumping the soname might be justified. Thoughts from anyone?

You could give abi-compliance-checker a try.

I don't think any of the patches will change the ABI but I might be wrong... Mostly they add new classes or non-virtual functions.

I suppose technically even adding functions is cause for an soname bump because, for example, mapnik wouldn't work with an older version that was missing the new functions?

Yeah, I agree. I'll look into how to bump it, I'm thinking 2.0.4=>2.0.4.1.

Replying to [comment:15 tomh]:

I suppose technically even adding functions is cause for an soname bump because,
No. Adding functions is not a reason to change SONAMES. Removing and changing functions are.

You can use a linker script to mark the new symbols with a specific version. See alsa-lib or glibc packages to see how it is done.

Ok, so since I've been swamped lately have have not had the cycles to figure out how to elegantly bump the soname, unless someone objects, I intend to commit and build the whole pile without a bumped soname on Monday. It'll be rawhide only, so I can't imagine the ramifications being significant, but better now, early in the f20 cycle.

Agg is updated, and gnash, mapnik and python-matplotlib are updated in git, but I forgot the mapnik patches with made the chain-build barf, so I'll re-rebuild those three when rawhide remashes.

More fun. gnash failed due to a missing includes, fixing that up. python-matplotlib failed due to texlive not having been rebuilt for the new gd, so I kicked that off. mapnik failed with what look like Boost errors, tomh, can you look at this one?

http://kojipkgs.fedoraproject.org//work/tasks/1260/5491260/build.log

Of course, then, texlive failed. jnovy, can you have a look?

http://kojipkgs.fedoraproject.org//work/tasks/2170/5492170/build.log

Replying to [comment:21 limb]:

More fun. gnash failed due to a missing includes, fixing that up. python-matplotlib failed due to texlive not having been rebuilt for the new gd, so I kicked that off. mapnik failed with what look like Boost errors, tomh, can you look at this one?

http://kojipkgs.fedoraproject.org//work/tasks/1260/5491260/build.log

I think the mapnik thing may be an issue with the boost packages in rawhide.. I took this file:

{{{

include <boost/regex.hpp>

include <boost/regex/icu.hpp>

}}}

and preprocessed it with "g++ -E x.cpp" on F18 and when you look at the output boost::uint64_t (which indirectly defines the second parameter of that function) is "unsigned long" but on rawhide it is "unsigned long long" instead.

That in itself would be fine, except that the boost_regex-mt.so library seems to have been built with the "unsigned long" definition.

I have raised https://bugzilla.redhat.com/show_bug.cgi?id=977098 with a simple test case for the boost problem.

The boost bug is now fixed and a new build is in rawhide, so we are good to have another go. However, mapnik 2.2 has now been released, so I have prepared a new set of patches...

First up is an update of the agg patches - this fixes a bug in one of the previous ones and adds four new ones extracted from the mapnik 2.2 source. A patch against the agg packaging git is at:

http://download.compton.nu/tmp/agg.patch

There is also a patch against mapnik packagaing git to update it to 2.2 at:

http://download.compton.nu/tmp/mapnik.patch

Using these I have just successfully built mapnik in rawhide.

agg patch applied and built. You might consider applying to be an agg-comaintainer, for rawhide at least. I'll leave updating mapnik to you.

I see texlive has been build, so I'll rebuild python-matplotlib.

python-matplotlib is done. So when you update mapnik (after rawhide remashes), this can be closed.

The mapnik rebuild is currently blocked waiting for gdal to be rebuilt against the new poppler...

As suggested I will apply for comaintainer on agg.

Mapnik 2.2 is now built into rawhide.