Nighly feedstock build failed about conda-forge-nightly-controller

[KiterLuc]

Thanks for looking at it @jdblischak. I think you are right... @dudoslav is looking right now as Theo is out this week.

[jdblischak]

Ok. In that case I propose adding it here in the nightly controller feedstock if possible instead of prematurely adding a dependency to the conda-forge recipe

[KiterLuc]

@dudoslav Can we open a PR with John's suggestion and see if it would fix the nightlies?

[dudoslav]

PR created:

#74

[github-actions]

Nightly feedstock build failure for TileDB-Py%20Feedstock%20Testing at https://dev.azure.com/TileDB-Inc/CI/_build?definitionId=5&_a=summary

[github-actions]

Nightly feedstock build failure for tiledbfeedstock_CI at https://dev.azure.com/TileDB-Inc/CI/_build?definitionId=4&_a=summary

[github-actions]

Nightly feedstock build failure for TileDB-Py%20Feedstock%20Testing at https://dev.azure.com/TileDB-Inc/CI/_build?definitionId=5&_a=summary

[github-actions]

Nightly feedstock build failure for tiledbfeedstock_CI at https://dev.azure.com/TileDB-Inc/CI/_build?definitionId=4&_a=summary

[github-actions]

Nightly feedstock build failure for TileDB-Py%20Feedstock%20Testing at https://dev.azure.com/TileDB-Inc/CI/_build?definitionId=5&_a=summary

[jdblischak]

The tiledb-feedstock nightly win-64 build started failing on Friday with the error below:

[256/349] Linking CXX shared library tiledb\tiledb.dll
FAILED: tiledb/tiledb.dll tiledb/tiledb.lib 
C:\Windows\system32\cmd.exe /C "cd . && %BUILD_PREFIX%\Library\bin\cmake.exe -E vs_link_dll --intdir=tiledb\CMakeFiles\tiledb.dir --rc=C:\PROGRA~2\WI3CF2~1\10\bin\100226~1.0\x64\rc.exe --mt=C:\PROGRA~2\WI3CF2~1\10\bin\100226~1.0\x64\mt.exe --manifests  -- C:\PROGRA~1\MICROS~2\2022\ENTERP~1\VC\Tools\MSVC\1429~1.301\bin\HostX64\x64\link.exe /nologo @CMakeFiles\tiledb.rsp  /out:tiledb\tiledb.dll /implib:tiledb\tiledb.lib /pdb:tiledb\tiledb.pdb /dll /version:0.0 /machine:x64 /INCREMENTAL:NO && cd ."
LINK: command "C:\PROGRA~1\MICROS~2\2022\ENTERP~1\VC\Tools\MSVC\1429~1.301\bin\HostX64\x64\link.exe /nologo @CMakeFiles\tiledb.rsp /out:tiledb\tiledb.dll /implib:tiledb\tiledb.lib /pdb:tiledb\tiledb.pdb /dll /version:0.0 /machine:x64 /INCREMENTAL:NO /MANIFEST:EMBED,ID=2" failed (exit code 1120) with the following output:
   Creating library tiledb\tiledb.lib and object tiledb\tiledb.exp
azure-identity.lib(azure_cli_credential.cpp.obj) : error LNK2019: unresolved external symbol _Thrd_sleep_for referenced in function "void __cdecl std::this_thread::sleep_for<__int64,struct std::ratio<1,1000> >(class std::chrono::duration<__int64,struct std::ratio<1,1000> > const &)" (??$sleep_for@_JU?$ratio@$00$0DOI@@std@@@this_thread@std@@YAXAEBV?$duration@_JU?$ratio@$00$0DOI@@std@@@chrono@1@@Z)
azure-core.lib(retry_policy.cpp.obj) : error LNK2001: unresolved external symbol _Thrd_sleep_for
azure-core.lib(url.cpp.obj) : error LNK2019: unresolved external symbol __std_find_trivial_1 referenced in function "char const * __cdecl std::_Find_unchecked<char const *,char>(char const *,char const * const,char const &)" (??$_Find_unchecked@PEBDD@std@@YAPEBDPEBDQEBDAEBD@Z)
azure-core.lib(win_http_transport.cpp.obj) : error LNK2001: unresolved external symbol __std_find_trivial_1
azure-core.lib(win_http_transport.cpp.obj) : error LNK2019: unresolved external symbol __std_find_trivial_2 referenced in function "wchar_t * __cdecl std::_Find_unchecked<wchar_t *,char>(wchar_t *,wchar_t * const,char const &)" (??$_Find_unchecked@PEA_WD@std@@YAPEA_WPEA_WQEA_WAEBD@Z)

tiledb\tiledb.dll : fatal error LNK1120: 3 unresolved externals

[257/349] Building CXX object tiledb\sm\array_schema\CMakeFiles\attribute.dir\attribute.cc.obj

[258/349] Building CXX object tiledb\sm\array\CMakeFiles\array.dir\array_directory.cc.obj

ninja: build stopped: subcommand failed.

ninja: build stopped: subcommand failed.

[jdblischak]

The tiledb-py-feedstock failures starting Friday and are simply the win-64 builds failing due to the lack of the libtiledb nightly conda binaries

[jdblischak]

I assume this is due to the new dependency on azure-identity-cpp from @teo-tsirpanis's PR TileDB-Inc/TileDB#4126 which was merged Friday in TileDB-Inc/TileDB@ceee95e

[jdblischak]

I know the solution. We need to add azure-identity-cpp to the host requirements and then create an empty overlay port for vckpg, just like in conda-forge/tiledb-feedstock#242

However, my question is about timing. The nightlies will continue to fail until this is done. How soon until this change is released? In other words, is it worth adding this new dependency to the conda recipe prematurely to fix the nightlies, or should we just wait until the next libtiledb release? Alternatively we could update the nightly scripts in this repo to add the dependency and port overlay until they make it upstream. We've done similar nightly patches in the past, eg #50

[KiterLuc]

@jdblischak We still have 2+ week before we ship. I think we should add it now.

[teo-tsirpanis]

We still need to add azure-identity-cpp but the undefined symbols seem unrelated on first glance. Maybe it's the same issue as TileDB-Inc/TileDB#4759? I see only Windows fails so it's very likely that.

[jdblischak]

Maybe it's the same issue as TileDB-Inc/TileDB#4759? I see only Windows fails so it's very likely that.

@teo-tsirpanis thanks for the insights! We'll start by adding azure-identity-cpp with #71. If it still fails, how should we proceed? The conda-forge recipe already uses Ninja for the build

[teo-tsirpanis]

We should tell CMake to use the latest MSVC toolchain. TileDB is using a custom GitHub action before configuring; I am not sure how to do it here, this might require a wider conda-forge discussion.

[jdblischak]

We should tell CMake to use the latest MSVC toolchain.

Ok, it looks like this could be possible.

Here is the discussion (conda-forge/conda-forge.github.io#1732) and PR (conda-forge/conda-forge-pinning-feedstock#3167) that led to the update from vs2017 to vs2019.

Note that win-arm64 is already pinned to vs2022 (conda-forge/conda-forge-pinning-feedstock#4415).

Also it appears that using vs2022 is already possible for individual conda-forge feedstocks (conda-forge/conda-forge.github.io#1878). This post (conda-forge/conda-forge.github.io#1956) nicely describes the hesitation about bumping the global pin for all of conda-forge

So if the nightly build fails again tonight, we need to update the controller feedstock to add the following lines to tiledb-feedstock/recipe/conda_build_config.yaml:

cxx_compiler:  # [win]
  - vs2022     # [win]

Though IIUC, this will require all downstream projects that link against libtiledb to also update their compilers from vs2019 to vs2022

[jdblischak]

And here is the official documentation on how to use vs2022 in a feedstock: https://conda-forge.org/docs/maintainer/knowledge_base/#using-vs2022

[github-actions]

Nightly feedstock build failure for tiledbfeedstock_CI at https://dev.azure.com/TileDB-Inc/CI/_build?definitionId=4&_a=summary

[github-actions]

Nightly feedstock build failure for TileDB-Py%20Feedstock%20Testing at https://dev.azure.com/TileDB-Inc/CI/_build?definitionId=5&_a=summary

[ihnorton]

Though IIUC, this will require all downstream projects that link against libtiledb to also update their compilers from vs2019 to vs2022

@jdblischak is there a migration plan that you are aware of?

[jdblischak]

I'm testing vs2022 on my feedstock fork

https://github.com/jdblischak/tiledb-feedstock/tree/nightly-build-vs2022
https://dev.azure.com/jdblischak/feedstock-builds/_build/results?buildId=722&view=results

[jdblischak]

I'm testing vs2022 on my feedstock fork

I confirmed the win-64 nightly on my fork built successfully (all the builds later failed during the upload step because my fork has my personal anaconda.org token, which then fails to upload to the tiledb channel)

I'm closing this as fixed

[jdblischak]

is there a migration plan that you are aware of?

@ihnorton No, so I opened an Issue to ask conda-forge/conda-forge.github.io#2138