Build FAILED - Failed to download zlib

[smfloery]

Dear osgearth-Team, I wanted to build osgearth on Windows 10. I followed the documentation on http://docs.osgearth.org/en/latest/ by first installing using vcpkg:

vcpkg install osgearth:x64-windows

followed by building the SDK in order to use the application tools like osg_viewer. While installation with vcpkg worked without any problem I can't build the SDK as I encounter an error as soon as vcpkg tries to install zlib. After pulling the source from GitHub and running Cmake:

cmake -S osgearth -B build -G "Visual Studio 16 2019" -A Win64 -DCMAKE_BUILD_TYPE=RelWithDebInfo -DWIN32_USE_MP=ON -DCMAKE_INSTALL_PREFIX=C:\src\osgearth\ -DCMAKE_TOOLCHAIN_FILE=C:\src\vcpkg\scripts\buildsystems\vcpkg.cmake

with [installroot] and [vcpkgroot] changed to my local paths, I get the following error message:

...
...
Installing 7/142 zlib:x64-windows...
Building zlib[core]:x64-windows...
-- Installing port from location: C:\src\vcpkg\buildtrees\versioning_\versions\zlib\9c4edb1fabbd87dd236a200ba55eaf241cd8c8d0
    [DEBUG] Downloading https://www.zlib.net/zlib-1.2.12.tar.gz
    Error: Failed to download from mirror set:
    https://www.zlib.net/zlib-1.2.12.tar.gz: failed: status code 404

[DEBUG] D:\a\_work\1\s\src\vcpkg\base\downloads.cpp(766):
[DEBUG] Time in subprocesses: 0 us
[DEBUG] Time in parsing JSON: 67 us
[DEBUG] Time in JSON reader: 0 us
[DEBUG] Time in filesystem: 211 us
[DEBUG] Time in loading ports: 0 us
[DEBUG] Exiting after 919.2 ms (919051 us)

CMake Error at scripts/cmake/vcpkg_download_distfile.cmake:32 (message):

    Failed to download file with error: 1
    If you use a proxy, please check your proxy setting. Possible causes are:

    1. You are actually using an HTTP proxy, but setting HTTPS_PROXY variable
       to `https://address:port`. This is not correct, because `https://` prefix
       claims the proxy is an HTTPS proxy, while your proxy (v2ray, shadowsocksr
       , etc..) is an HTTP proxy. Try setting `http://address:port` to both
       HTTP_PROXY and HTTPS_PROXY instead.

    2. You are using Fiddler. Currently a bug (https://github.com/microsoft/vcpkg/issues/17752)
       will set HTTPS_PROXY to `https://fiddler_address:port` which lead to problem 1 above.
       Workaround is open Windows 10 Settings App, and search for Proxy Configuration page,
       Change `http=address:port;https=address:port` to `address`, and fill the port number.

    3. Your proxy's remote server is out of service.

    In future vcpkg releases, if you are using Windows, you no longer need to set
    HTTP(S)_PROXY environment variables. Vcpkg will simply apply Windows IE Proxy
    Settings set by your proxy software. See (https://github.com/microsoft/vcpkg-tool/pull/49)
    and (https://github.com/microsoft/vcpkg-tool/pull/77)

    Otherwise, please submit an issue at https://github.com/Microsoft/vcpkg/issues

So obviously zlib can't be installed. Interestingly when installing the SDK with vcpkg in the first place zlib is installed but with the port-version 2:

vcpkg install zlib:x64-windows
Computing installation plan...
The following packages are already installed:
    zlib[core]:x64-windows -> 1.2.12#2
zlib:x64-windows is already installed

Going to https://github.com/microsoft/vcpkg/issues?q=is%3Aissue+is%3Aopen+in%3Atitle+zlib shows that actually there has been a vcpkg update in order to pull zlib from GitHub rather from https://www.zlib.net/zlib-1.2.12.tar.gz -> zlib1212.tar.gz This explains why the initial installation with vcpkg works. As I'm unfortunately not very familiar with vcpkg and cmake I'm not sure how I could fix this locally by specifying the port-number in any of the CMake-Files? Or am I completely off as building the SDK is not necessary after installing it with vcpkg in order to build the command line tools and, on the long shot, use osgearth in Visual Studio?

Thank you very much for your time & help Sebastian

[jasonbeverage]

Hi Sebastian, I do see in this issue that people are having issues with zlib: https://github.com/microsoft/vcpkg/issues/27375, presumably b/c a source has moved. Sometimes managing vcpkg and it's dependencies can be a pain.

What version of vcpkg and osgearth are you trying to build?

Keep in mind that the version of osgearth that is installed with vcpkg is different than the current master osgearth and could have different dependencies with might be what is triggering the pulling down of the new zlib.

If you look at our github workflows you'll see we are using vcpkg with the git hash bb584d35bba70ca9f1ecaf09ad96ce5d1ff946f8. You might try that version of vcpkg. That works fine for our CI runs, although we are caching the dependencies so we won't run into issues if something broke downstream like zlib-1.2.12.tar.gz being removed from the web.

osgEarth is also now using the manifest mode of vcpkg by providing a vcpkg.json file. If you are going to build osgEarth yourself, you don't need to run vcpkg install osgearth, you can just build osgEarth by using a command line like what you posted and vcpkg will bring in all the dependencies: cmake -S osgearth -B build -G "Visual Studio 16 2019" -A Win64 -DCMAKE_BUILD_TYPE=RelWithDebInfo -DWIN32_USE_MP=ON -DCMAKE_INSTALL_PREFIX=C:\src\osgearth\ -DCMAKE_TOOLCHAIN_FILE=C:\src\vcpkg\scripts\buildsystems\vcpkg.cmake

So I would try: 1) Update your vcpkg to the latest version on github to get the fix for zlib. I'd just make a fresh checkout of vcpkg, don't update it in place. 2) Build osgEarth using manifest mode using the cmake command you are already using and don't run vcpkg install osgearth.

[jasonbeverage]

also, If you don't actually need to build osgearth from source and you are just trying to get the osgearth_viewer command line tools you can install osgearth via vcpkg with vcpkg install osgearth[tools]:x64-windows

[smfloery]

Dear Jason, thank you very much for your fast reply. I'm already using the newest version of vcpkg. To make sure that I don't have any old cached things lying around I also deleted everything from Appdata/local/vcpkg. Still, using the abovementioned Cmake command fails again as soon as zlib is installed whereas vcpkg install osgearth:x64-windows works. Furthermore, I can directly install zlib using vcpkg install zlib:x64-windows which now even installs version 1.2.13. Might it be the case that, when building osgearth from source, an older zlib version is somewhere defined as dependency?

Besides that, is there any disadvantage or limitation using vcpkg install osgearth:x64-windwos especially with the [tools] option to get the command line tools as well in contrast to building the SDK from source? Except not being completely up to date with the latest changes?

Thanks Sebastian

[jasonbeverage]

Unless you need the absolute latest and greatest osgEarth, just installing it with vcpkg install osgearth[tools]:x64-windows is perfectly fine instead of building it yourself. Meanwhile I'll try building osgEarth with the latest vcpkg and see if I run into the same issue.

[TheTastefulToastie]

I ran into this issue when compiling the osgEarth "3.3" branch on Windows x64.

@smfloery My quick workaround was to make a change to the file: [vcpkgroot]\buildtrees\versioning_\baselines\bb584d35bba70ca9f1ecaf09ad96ce5d1ff946f8 Find the lines containing:

"zlib": {
  "baseline": "1.2.12",
  "port-version": 0
},

and change the "port-version" to "2":

"zlib": {
  "baseline": "1.2.12",
  "port-version": 2
},

---

If you look at our github workflows you'll see we are using vcpkg with the git hash bb584d35bba70ca9f1ecaf09ad96ce5d1ff946f8

I might draw attention to the following comment on vcpkg best practice: https://github.com/microsoft/vcpkg/issues/27375#issuecomment-1291069993

I've been using only the tagged releases to minimize the chance for bugs to creep in. What's the recommended best practice?

Just keep the latest version.

---

we are caching the dependencies, so we won't run into issues if something broke downstream like zlib-1.2.12.tar.gz being removed from the web

It seems this is exactly what has happened, and how it slipped through testing.

[jasonbeverage]

I've updated our vcpkg.json and the github actions windows-x64 build to use a newer baseline and things are building nicely now!