Build failure for MSVC 2022 due to missing symbol _Thrd_sleep_for

[johnwason]

A build error is being caused by ompl on the windows-2022 build:

2024-03-08T06:21:55.5053089Z    Creating library ompl\tesseract_motion_planners_ompl.lib and object ompl\tesseract_motion_planners_ompl.exp
2024-03-08T06:21:55.5057406Z ompl.lib(PRM.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)
2024-03-08T06:21:55.5061053Z ompl.lib(SPARS.cpp.obj) : error LNK2001: unresolved external symbol _Thrd_sleep_for
2024-03-08T06:21:55.5062667Z ompl.lib(PlannerTerminationCondition.cpp.obj) : error LNK2001: unresolved external symbol _Thrd_sleep_for
2024-03-08T06:22:06.8790957Z ompl.lib(Planner.cpp.obj) : error LNK2001: unresolved external symbol _Thrd_sleep_for

@ooeygui suggested:

This looks like a toolchain version difference between the ompl build and tesseract. I suspect the github binary cache is using a newer visual studio toolchain. Try removing that? Or migrate the toolchain for tesseract forward? (although that may have nasty implications of users of tesseract)

I see what's going on. All Windows-2022 builds are failing, not just this change.

Ompl is built using mingw, but the rest of is built using visual studio. I'm trying to figure out why it is getting brought in.

-- Extracting source D:/a/tesseract_planning/tesseract_planning/vcpkg/downloads/ompl-ompl-1.5.1.tar.gz
-- Applying patch 0001_Export_targets.patch
-- Applying patch 0002_Fix_config.patch
-- Using source at D:/a/tesseract_planning/tesseract_planning/vcpkg/buildtrees/ompl/src/1.5.1-b7b5702eed.clean
-- Found external ninja('1.11.0').
-- Configuring x64-windows-release-rel
-- Building x64-windows-release-rel
-- Downloading https://mirror.msys2.org/mingw/mingw32/mingw-w64-i686-pkgconf-1~1.8.0-2-any.pkg.tar.zst;https://repo.msys2.org/mingw/mingw32/mingw-w64-i686-pkgconf-1~1.8.0-2-any.pkg.tar.zst;https://mirror.yandex.ru/mirrors/msys2/mingw/mingw32/mingw-w64-i686-pkgconf-1~1.8.0-2-any.pkg.tar.zst;https://mirrors.tuna.tsinghua.edu.cn/msys2/mingw/mingw32/mingw-w64-i686-pkgconf-1~1.8.0-2-any.pkg.tar.zst;https://mirrors.ustc.edu.cn/msys2/mingw/mingw32/mingw-w64-i686-pkgconf-1~1.8.0-2-any.pkg.tar.zst;https://mirror.selfnet.de/msys2/mingw/mingw32/mingw-w64-i686-pkgconf-1~1.8.0-2-any.pkg.tar.zst -> mingw-w64-i686-pkgconf-1~1.8.0-2-any.pkg.tar.zst...
-- Downloading https://mirror.msys2.org/msys/x86_64/msys2-runtime-3.4.6-1-x86_64.pkg.tar.zst;https://repo.msys2.org/msys/x86

[johnwason]

@ooeygui I rebuilt ompl using vcpkg locally and it looks like it is being built using msvc. I am not sure why it is downloading mingw but I don't think it is using it.

[johnwason]

This has been fixed somewhere upstream in the dependencies by somebody. I haven't seen any explanation or fix but it is working now.