I checked out the project's branch from SVN. I want to manage the project locally with Git, so I'll be committing to the server using git-svn.
The installation caused me some trouble:
- After installing version 1_43 of boost in /usr/local and building boost.regex, libboost_regex was still linked to libicu version 42. I had libicu 44 in both /usr/local/lib and /usr/lib, but libicu 42 stil in /usr/lib. Even when I included -sICU_PATH=/usr/local when building with bjam it was still linked to the older version. I solved it removing libicu 42 from /usr/lib and leaving only version 44, but I'm sure this is not the correct way to solve this problem.
- The revision I checked out (1796) includes new code that implements some SVG features that are still in development. This revision had two bugs, which where solved by Herm (http://trac.mapnik.org/ticket/557), in files include/mapnik/svg/agg_svg_path_renderer.h (declaration of function 'arc_to' had parameter 'rx' twice | the second 'rx' should be 'ry') and agg/include/agg_rasterizer_scanline_aa.h (function 'abs' should be preceded with 'std::').
- When configuring the build with scons (python scons/scons.py configure) the following problem was solved by removing 'config.py' which (I think) acts as a cache where scons saves the options chosen (i.e. BOOST_LIBS, DEMO) of previous ran configurations:
Note: will build without these OPTIONAL dependencies:
- ociei (Oracle database library | configure with OCCI_LIBS & OCCI_INCLUDES | more info: http://trac.mapnik.org/wiki/OCCI)
- rasterlite
Problem encountered parsing mapnik version, falling back to [0, 8, 0]
- ociei (Oracle database library | configure with OCCI_LIBS & OCCI_INCLUDES | more info: http://trac.mapnik.org/wiki/OCCI)
- rasterlite
Problem encountered parsing mapnik version, falling back to [0, 8, 0]
- Finally, when I finished the installation, importing mapnik2 in python produced the following error, which I solved removing the input file plugins from /usr/local/lib/mapnik2/input [UPDATE: Running the build again installed correctly the input files and python doesn't show errors anymore when importing mapnik2 (it may have something to do with what's referred to here http://trac.mapnik.org/wiki/InstallationTroubleshooting under 'Input/Plugin 'file not found' output')]:
Problem loading plugin library: /usr/local/lib/mapnik2/input/ogr.input (libtool error: file not found)
Problem loading plugin library: /usr/local/lib/mapnik2/input/gdal.input (libtool error: file not found)
Problem loading plugin library: /usr/local/lib/mapnik2/input/gdal.input (libtool error: file not found)
Hello Carlos,
ReplyDeleteGreat job moving past these issues and documenting how you did it.
I'll comment on each of these issues as well, adding my 2 cents:
1) bjam and libboost_regex linking to icu. I think this is a bjam bug because /usr/local/lib should
be prioritized over a duplicate lib in /usr/lib, but I've certainly seen that this is not the case. Basically
which every path occurs first will be the one linked by ld. So it is up to the build system to try to
either control linking or allow the user to specify. I'm no expert with linking but I feel like I solved this
issue in Mapnik in a way that is working reasonably well, but explicitly sorting each path sent to ld
based on a user configurable priority matrix. You can see the initial commit here:
https://trac.mapnik.org/changeset/1649
2) The mapnik compile error in recent trunk - this was not occurring on mac osx (so I did not see it initially)
but I've committed Herm's fix, so things are working now :)
3) If you run into this 'Problem encountered parsing mapnik version' warning again, please grab
the 'config.log' and attach to a new ticket and assign to me. I think there is a subtle bug in our
use of SCons that is causing a permissions problem. The other possibility is that you needed to run
$ ldconfig after rebuilding libboost and without that the references to old boost libraries was causing
the problem.
4) Yes, this is a known problem, where old plugin libraries are binary-incompatible with newly
build versions of Mapnik, and cannot be loaded at runtime. One way to avoid this is to have the build system
remove all plugin libraries during install (before placing the newly built ones). Otherwise
this issue is bound to happen when the user requests different plugins to be built and old
ones are not overwritten.