Any stable build combination?

[bmharper]

Hi, I've tried many variations today, trying to get this to build, but all of them fail, and all with different errors. I've tried several mapnik branches, including [master, v3.0.12, windows], and I've tried using FASTBUILD=0 and FASTBUILD=1, but all of those combinations end up with different errors - most of them compilation errors, but some of them linker errors. Is there a "known good" configuration that build on VS 2015 Update 3?

[wilhelmberg]

We currently discussing this issue (and evaluation of VS2017) over here: https://github.com/mapnik/mapnik/issues/3573

As of today "FASTBUILD=0" "MAPNIKBRANCH=v3.0.x" should compile with VS2015 Update3.

[bmharper]

Thanks, but with that combination, I still get the following errors:

mapnik-v3.0.x\mapnik-gyp\mapnik-sdk\include\boost/spirit/home/support/attributes.hpp (1036): error C2672: 'swap': no matching overloaded function found (compiling source file ..\..\src\image_filter_grammar.cpp

and

packages\mapnik-v3.0.x\mapnik-gyp\mapnik-sdk\include\boost/spirit/home/support/attributes.hpp (1036): error C2784: 'void boost::spirit::swap(boost::spirit::multi_pass<T,Policies> &,boost::spirit::multi_pass<T,Policies> &)': could not deduce template argument for 'boost::spirit::multi_pass<T,Policies> &' from 'mapnik::color' (compiling source file ..\.. \src\image_filter_grammar.cpp

[wilhelmberg]

Ah sorry, master is still missing the patch for [email protected]. Make a copy of boost-1_61.diff naming it boost-1_62.diff.

Then

• ~~clean.bat boost~~ EDIT: delete directory packages\boost
• scripts\build_boost.bat
• scripts\build_mapnik.bat

That should work.

[bmharper]

Thanks, that worked! I did need to manually apply the patch (ie "clean boost" && build_boost didn't cause it to be reapplied). Anyway - I think it would be very useful to have some kind of "last known good state", but I'm not sure where exactly you'd place that information.

[wilhelmberg]

Great!

I think it would be very useful to have some kind of "last known good state"

Yes, we've been thinking about how to achieve that a lot. Normally master should be in such a state.

[bmharper]

So.. mapnik builds successfully, but when trying to build the C++ demo (rundemo.cpp), I get linker errors that I can't understand. Basically, it looks as though the linker is unable to find any symbols defined inside mapnik.lib, despite everything appearing to be correct. An example of a symbol that's not found is:

rundemo.obj : error LNK2001: unresolved external symbol "private: static enum mapnik::logger::severity_type mapnik::logger::severity_level_" (?severity_level_@logger@mapnik@@0W4severity_type@12@A)

I have done various things:

1. Ensure that the C++ compilation settings are exactly as specified by mapnik-config.bat
2. Use dumpbin /exports mapnik.lib, to ensure that these symbols are exported from mapnik.lib (they are indeed exported)
3. Use dumpbin /headers mapnik.lib, to ensure that the lib file is an x64 lib file, consistent with the project settings of rundemo.cpp
4. Follow the instructions and use gyp to build rundemo.cpp - same result.

As a test, adding or removing mapnik.lib from the list of linker input libraries makes no difference - I still end up with the same number of missing symbols (about 50 of them).

Has anybody seen this before? I'm wondering if it's a bug in the VC linker, because as far as I can tell, everything here lines up as it should.

[bmharper]

UPDATE: It works! I needed to wipe all build outputs and start from a clean slate, and then those mysterious linker errors disappeared.

The following procedure worked for me:

1. Clone mapnik-windows-builds, and checkout master (I'm on revision 785e8e02eef26db64cbe8a22d667e0e34e4a601c)
2. copy patches\boost-1_61.diff patches\boost-1_62.diff
3. settings "FASTBUILD=0" "MAPNIKBRANCH=v3.0.x"
4. scripts\build. I got an ICE (Internal Compiler Error) here on first build.
5. Run scripts\build again. On the second run, the build succeeded.
6. Output files are packaged inside bin\mapnik-win-sdk-v3.0.12-53-g7ce68e2-x64-14.0.7z

[bmharper]

I'd just like to add for posterity, that a key thing I was missing previously was to #define _WINDOWS. Without that, you get mysterious linker errors.

[ojbgame]

@bmharper Which file should #define _WINDOWS add to?

[bmharper]

@ojbgame It must be defined in all of your own C++ files that #include <mapnik.h>.

[ojbgame]

@bmharper Thanks. It works.

[wilhelmberg]

Curious why an additional #define _WINDOWS is needed. It's defined here in mapnik-gyp. Going to investigate during the next weeks.