vcpkg failing on macOS about run-vcpkg

[lukka]

@vadi2 I took a quick look, but i think it is a good lead: the cache has been created in the past with a different version of the macOS GitHub environments, and the vcpkg executable is failing its execution on some missing binary dependency, i.e. dyld: Symbol not found: ___emutls_v._ZSt11__once_call.

The environment look brand new released on 10th Jan 2021.

Environment: macos-10.15
Version: 20210110.1
Included Software: https://github.com/actions/virtual-environments/blob/macOS-10.15/20210110.1/images/macos/macos-10.15-Readme.md

The solution is to change the key, so that the old cache is not used anymore, and vcpkg's executable is being rebuilt.

I think the action should include by default the version of the image, but I am not aware of any way to fetch it. We can keep this ticket open until i found a good solution to this problem.

[lukka]

Posting here below the link where I asked how to fetch the required data to append to the key in order to tie the cache to a given environment version. Probably the environment and the version would be good candidates (e.g Environment: macos-10.15 Version: 20201212.1), as I expect them to change on updates.

https://github.community/t/fetching-runner-and-environment-data-while-an-action-is-executing/155663

[vadi2]

Yep OK.

[woodruffw]

Thanks for keeping this open! I also experienced this on one of my builds; will report back when it's fixed.

Edit: Confirmed that a cache refresh fixes it for me.

[vadi2]

After changing the cache key, I am still running into the issue in newer PRs, this time with a different message:

  dyld: Symbol not found: __ZSt14__once_functor

I know the environments are deployed step by step (that's why there's the % meter on https://github.com/actions/virtual-environments), so either perhaps it was updated once again, breaking our builds, or an older build managed to save the cache.

[lukka]

@vadi2 could you provide a link to the failed workflow execution?

[vadi2]

https://github.com/Mudlet/Mudlet/runs/1713255489?check_suite_focus=true

[lukka]

@vadi2 In this run this key has been hit:

submodGitId=4b222f8d2653603b74fa5086cf0b02a1963d3911-args=262756201-os=-931134771-appendedKey=-820573572

Could we trace back where that key has been first created? i.e. in which run?

And yes, the macOS environment is not the very last one (released in Jan 2021), where clang has been bumped from version 11 to version 12, and here I assume we are hitting a ABI compatibility problem.

[vadi2]

Could we trace back where that key has been first created? i.e. in which run?

That would be hard because Github wipes the cache very often, so even if we keep the vcpkg submodule ID the same, it gets rebuilt every now and then anyway - and so it require a lot of clicking around to find.

[vadi2]

This is becoming a real issue because the action breaks very frequently now due to this and the only way to fix it is to change the cache key - not something everyone knows how to do or can (or should be). Could a fallback be added that if running vcpkg fails, it is rebuilt?

[lukka]

@vadi2 let me know the changes applied to run-vcpkg@v6 fix this issue for you. Feel free to reopen this ticket if it is not the case (the ticket has been closed automatically upon PR completion).