cannot open file 'libboost_filesystem-vc140-mt-1_61.lib'

[springmeyer]

After merging #94 the build bot failed with:

2016-08-26 20:47:34 stdout  Release\obj\mapnik\..\..\src\/xml_tree.obj
2016-08-26 20:47:37 2016-08-26 20:47:36 stdout  2>LINK : fatal error LNK1104: cannot open file 'libboost_filesystem-vc140-mt-1_61.lib' [Z:\mb\windows-builds-64\packages\mapnik-master\mapnik-gyp\build\mapnik.vcxproj]
2016-08-26 20:47:37

@BergWerkGIS - any idea on this one?

[springmeyer]

Ah, maybe it needs to be [FASTBUILD=0] if deps changed? Will try that now...

[wilhelmberg]

@springmeyer yes, haven't updated the binary deps package yet. Was waiting on https://github.com/mapbox/windows-builds/pull/94 to be merged. Will update deps packages on Monday.

[wilhelmberg]

Binary deps packages updated.

Also created fresh SDKs as of today: 64bit: https://mapnik.s3.amazonaws.com/dist/dev/mapnik-win-sdk-v3.0.12-rc6-x64-14.0.7z 32bit: https://mapnik.s3.amazonaws.com/dist/dev/mapnik-win-sdk-v3.0.12-rc6-x86-14.0.7z

[springmeyer]

@BergWerkGIS thank you. For future reference can you add docs for how the binary deps package works? I'd like to ensure we have docs in the readme to answer questions like 1) when does the binary deps package need updated/when will things be broken if it is not updated, 2) will breakages be fixed by passing [FASTBUILD=0]?, 3) how can the binary deps be updated?

[wilhelmberg]

@springmeyer https://github.com/mapbox/windows-builds#creating-binary-mapnik-dependencies-packages-mapbox-specific

[springmeyer]

@BergWerkGIS Thank you. Going to re-open with one more question. I noticed mapnik master appveyor was also failing with this error fatal error LNK1104: cannot open file 'libboost_filesystem-vc140-mt-1_61.lib'. I think I fixed this by doing: https://github.com/mapnik/mapnik/commit/687af49f47448e32e522006212502d9c3d9dad0e (refs https://github.com/mapnik/mapnik/issues/3509). Now I see that lots of visual tests are still failing. They look related to text which makes me wonder if the binary deps really got freetype 2.6.5. Is it possible that an older freetype is still in use somehow?

[wilhelmberg]

@springmeyer FT looks right:

[artemp]

@BergWerkGIS - is it possible that while freetype2 is updated run-time still uses old DLL ? Could you verify mapnik.dll is linked to correct freetype2 via "Dependency Walker" (depends.exe), please ?