scripts\package_libosmium_deps fails, trying to build libtiff

[bdiscoe]

Today on a Win7 machine with MSVC 2015, following the instructions on (https://github.com/osmcode/libosmium/wiki/Building-Libosmium) about "Building on Windows"
I gave these commands:

git clone https://github.com/mapbox/windows-builds.git
cd windows-builds
settings.bat
scripts\build_libosmium_deps
scripts\package_libosmium_deps

It proceeded very well, until it was trying to build libtiff (which is a little surprising, because libosmium does not need libtiff for anything, AFAIK). Below is the output preceding the error. Is this a known problem? Why is libtiff even being built?

    cl /nologo /Ox /MD /EHsc /W3 /D_CRT_SECURE_NO_DEPRECATE -I. -IC:\APIs\mapbox\windows-builds\packages/libjpegturbo -IC:\APIs\mapbox\windows-builds\packages/zlib  -DJPEG_SUPPORT -DOJPEG_SUPPORT -DZIP_SUPPORT -DAVOID_WIN32_FILEIO -DCHECK_JPEG_YCBCR_SUBSAMPLING -DDEFAULT_EXTRASAMPLE_AS_ALPHA -DSTRIPCHOP_DEFAULT=TIFF_STRIPCHOP -DSTRIP_SIZE_DEFAULT=8192 -DLOGLUV_SUPPORT -DNEXT_SUPPORT -DTHUNDER_SUPPORT -DLZW_SUPPORT -DPACKBITS_SUPPORT -DCCITT_SUPPORT -DTIF_PLATFORM_CONSOLE -DFILLODER_LSB2MSB  /c tif_stream.cxx

tif_stream.cxx
lib /nologo /out:libtiff.lib tif_aux.obj tif_close.obj tif_codec.obj tif_color.obj tif_compress.obj tif_dir.obj tif_dirinfo.obj tif_dirread.obj tif_dirwrite.obj tif_dumpmode.obj tif_error.obj tif_extension.obj tif_fax3.obj tif_fax3sm.obj tif_getimage.obj tif_jbig.obj tif_jpeg.obj tif_jpeg_12.ob
j tif_ojpeg.obj tif_flush.obj tif_luv.obj tif_lzw.obj tif_next.obj tif_open.obj tif_packbits.obj tif_pixarlog.obj tif_predict.obj tif_print.obj tif_read.obj tif_stream.obj tif_swab.obj tif_strip.obj tif_thunder.obj tif_tile.obj tif_version.obj tif_warning.obj tif_write.obj tif_zip.obj tif_unix.obj
C:\APIs\mapbox\windows-builds\packages/libjpegturbo/build/sharedlib/Release/jpeg.lib C:\APIs\mapbox\windows-builds\packages/zlib/zlib.lib
link /nologo /debug /dll /def:libtiff.def /out:libtiff.dll /implib:libtiff_i.lib tif_aux.obj tif_close.obj tif_codec.obj tif_color.obj tif_compress.obj tif_dir.obj tif_dirinfo.obj tif_dirread.obj tif_dirwrite.obj tif_dumpmode.obj tif_error.obj tif_extension.obj tif_fax3.obj tif_fax3sm.obj tif_getimage.obj tif_jbig.obj tif_jpeg.obj tif_jpeg_12.obj tif_ojpeg.obj tif_flush.obj tif_luv.obj tif_lzw.obj tif_next.obj tif_open.obj tif_packbits.obj tif_pixarlog.obj tif_predict.obj tif_print.obj tif_read.obj tif_stream.obj ti
f_swab.obj tif_strip.obj tif_thunder.obj tif_tile.obj tif_version.obj tif_warning.obj tif_write.obj tif_zip.obj tif_unix.obj C:\APIs\mapbox\windows-builds\packages/libjpegturbo/build/sharedlib/Release/jpeg.lib C:\APIs\mapbox\windows-builds\packages/zlib/zlib.lib
/usr/bin/link: extra operand '/dll'
Try '/usr/bin/link --help' for more information.
NMAKE : fatal error U1077: '"C:\Program Files\Git\usr\bin\link.EXE"' : return code '0x1'
Stop.
NMAKE : fatal error U1077: '"C:\Program Files (x86)\Visual Studio 14.0\VC\BIN\nmake.EXE"' : return code '0x2'
Stop.

```
ERRORLEVEL: 2
~~~~~~~~~~~~~~~~~~~ DONE C:\APIs\mapbox\windows-builds\scripts\build_tiff.bat ~~
```

[wilhelmberg]

Why is libtiff even being built?

libosmium needs gdal for its tests and how we've setup the gdal build (gdal also needed for mapnik builds) it needs libtiff.

---

I've tried a clean libosmium build twice and it worked for me without problems.

I suppose that your %PATH% has been changed after calling settings.bat, as link.exe of git seems to be used instead of VS's link:

NMAKE : fatal error U1077: '"C:\Program Files\Git\usr\bin\link.EXE"' : return code '0x1'

Does this help?

[bdiscoe]

Thanks for looking into it. My %PATH% is not getting changed after calling settings.bat. Is it getting changed BY settings.bat. When I open my standard MSVC build console, VS's link is on the path. Then I run settings.bat, which prepends the following to my PATH:

C:\APIs\mapbox\windows-builds\tmp-bin\make;C:\APIs\mapbox\windows-builds\tmp-bin;C:\APIs\mapbox\windows-builds\tmp-bin\ddt\x64;C:\APIs\mapbox\windows-builds\tmp-bin\7zip\x64;C:\APIs\mapbox\windows-builds\tmp-bin\ragel\x64;C:\APIs\mapbox\windows-builds\tmp-bin\gnu-win-tools;C:\APIs\mapbox\windows-builds\tmp-bin\nasm-2.11.08;C:\APIs\mapbox\windows-builds\tmp-bin\cmake-3.1.0-win32-x86\bin;C:\Python27\Scripts;C:\Python27;C:\Windows\System32\WindowsPowershell\v1.0;C:\Program Files\Git\usr\bin;C:\Program Files\Git\bin;

Notice how "C:\Program Files\Git\usr\bin" is there, so it is naturally found before VS's link.

Is this a bug with settings.bat? I really dislike Git and never have it on my path, ever; I only installed Git because this project required it. Does it really put Git's link on the path, then fail when Git's link is used?

[wilhelmberg]

When I open my standard MSVC build console, VS's link is on the path. Then I run settings.bat, which prepends the following to my PATH

settings.bat is designed to be called from a normal console. Not a VS console.
The VS environment is also setup by settings.bat here after adding git to %PATH%.

If you've installed VS into the default location you should be good to go.
Otherwise change the path to vcvarsall.bat in settings.bat linked above.

never have it on my path, ever;

Me neither. That's why it gets explicitly set for these scripts.

Working now?

[bdiscoe]

I did try it a regular shell first, and got:
'msbuild' is not recognized as an internal or external command, [...]
which is why I was trying from a VS shell (where it gets much farther...)
Looking into settings.bat, I see it does assume the installed VS folder is
"C:\Program Files (x86)\Microsoft Visual Studio 14.0"
But mine (which I presumed was the default location? Don't recall changing it) is:
"C:\Program Files (x86)\Visual Studio 14.0"

I edited the two places in settings.bat and now it seems to be working! (Still building.) Thanks!

I do strongly suggest that settings.bat checks to see if VS is really where it thinks it is, and fatal error out if it is not. Right now it seems to proceed silently, only to encounter that unrelated failure later.

As for libosmium "needing gdal for its tests", libosmium is header-only and many of its 'dependencies' are actually /very/ optional... I really just wanted to build libosmium (I already build GDAL, PROJ, GEOS etc. separately) so it's a bit frustrating that these can't be turned off ... or is there an option for that anywhere?

[wilhelmberg]

I really just wanted to build libosmium (I already build GDAL, PROJ, GEOS etc. separately) so it's a bit frustrating that these can't be turned off ... or is there an option for that anywhere?

Sorry for the inconvenience, but within windows-builds: no.

Maybe you want to mimic libosmium's appveyor.yml in a batch file you create by yourself.
This pulls down a binary package of all dependencies.

I do strongly suggest that settings.bat checks to see if VS is really where it thinks it is

Will do that.