Cool VL Viewer forum

Hi Henri,

just tried to build from the 1.32.2.15 sources on Windows with VC2022.
I get link errors LNK2038 with the default configuration, due to some confusion with the LIBMT/LIBMD runtime libraries.

Like:
- open VS 2022 x64 command prompt
- unpack source
- run windows-build.bat
-> Build Fails

See attached build log file.

I also tried building 1.32.2.14/13/11 and they failed the same way.
I have built at least 1.32.2.6 successfully in the past (but cannot rebuild as the prebuilt libs are gone now, also needed to patch the new lua lib link into 11/13/14).

I would assume it breaks due to the new prebuilt libs used since 1.32.2.10, but i cannot verify.
It might also be some broken update to my Visual Studio 2022 tools, but i find that unlikely currently.

Maybe you have an idea why it breaks? Or can even reproduce it on your system?

I have no such issue building the viewer, but I would suspect one of the following causes:

Maybe, somehow, you pass a MD flag instead of a MT one. Perhaps are you trying to compile a "Debug" or "ReleaseWithDebugInfo" build: this is not supported for my viewer under Windows, because it would require the same type of Debug/ReleaseWithDebugInfo pre-built libraries to properly link with the viewer, and I don't bother to build those.

You could indeed be using an older VS2022 release than the one in use by LL to compile their pre-built libraries on github; this has been known to cause issues in the (recent) past, especially since Micro$oft updated their runtime libraries very recently and the new runtimes are therefore different.
See this opensource-dev mailing list thread.
I am currently using VS2022 v17.11.2 to compile the official Windows builds of the viewer.

Ok, i tried with VS2022 17.11.2 and 17.11.4, but will retry a build on a different machine i have access to.
As said, the build is just unpacking and compiling with default settings, no changes to any cmake files. But maybe something messed up some VS defaults on this machine.

I just had a look and in v1.32.2.10 the boost libraries got updated to v1.86 (from v1.85) and recompiled with a newer VS2022 version than the previous ones, which could explain it worked for you before v1.32.2.10: perhaps are you using some old VS2022 SDK ?

I can reproduce it on a clean machine building 1.32.2.15.

VS 2022, 17.10.4 and VS2022 17.11.4:

I grabbed the Windows 11 Developer Image VM, that has VS2022 17.10.4 preinstalled:

- https://developer.microsoft.com/en-us/w ... -machines/
- Installed cmake, 7zip

- Installed python 3.12.6 from the python.org msi
(the "winget install python" installs a working python, but the download_prebuilt.cmake fails to detect and use it properly)
- Needed to call one of the prebuilt https:// URLs for Amazon AWS once in MS Edge, as pythons urllib is too stupid to collect the correct CA certificates otherwise
(SSL Error, no local issuer certificate, basically windows only ask MS for the "trusted" certificates on first use with some special api that python does not call, but Edge/Chrome do call)..., might be better to just call "curl" on Windows now, as MS ships it by default these days..., maybe I'll find time for a patch.
- Unpack sources
- run "windows-build.bat"

Same error.

I updated the VS 2022 install to 17.11.4, but the error stayed the same. (deleted build-vs2022, restarted the build from scratch with a new shell to pick up any env changes).

Well, I just created a new Win11 23H2 (VirtualBox) VM, with a fresh VS 2022 (17.11.4) installation, and I could compile the viewer just fine on it... So, that's an issue on your side, I'm afraid.

Instead, use the Visual Studio setup utility (Community) to install VS 2022 on an existing or new Win11 VM, or on a bare-metal Win11 PC.

v17.10.4 is too old, and my guess is that your pre-installed VM got too old a Windows SDK, that did not get updated during the upgrade to 17.11.4.

Please, proceed as explained in linden/doc/WindowsBuildHowto.txt... It is best to install from the upstream official packages, for you will have the choice of what to install, where, and with what permissions (e.g. cmake and Python can be installed system-wide, which is best, or only for one user).
There could also be an issue with cmake not getting installed properly via winget and failing to find VS 2022 tools for cmake (that must be installed too, as specified in WindowsBuildHowto.txt).

Exactly... Avoid "winget" for anything non-Micro$oft !!!

I indeed got this error too, with the fresh install (not getting it on my usual build VM), and unlike you, Edge did nothing to "fix" it.
Instead, I changed linden/scripts/install.py to ignore certificates: add import ssl along the other imports at the start of the script, then edit line 160 to read:
This change will be part of next release.

Thanks for trying with a fresh install.

I think i found the issue.

Both systems that failed used the most recent CMake 3.30.3.
When i downgrade CMake to 3.29.8 (or the 2.29.5 bundled with Visual Studio), the build succeeds again.

I would guess CMake messed up something when they reworked the VisualStudioGenerator (https://cmake.org/cmake/help/v3.30/release/3.30.html).
It seems the new version omits the /MD and /Gm-. The /Gm- is probably not relevant anymore (the option is deprecated), but the /MD seems relevant.

See this compile line for the two versions:

CMake 3.30.3
============

C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Tools\MSVC\14.41.34120\bin\HostX64\x64\CL.exe /c /IC:\devel\sl\cool\linden\indra\llcommon /IC:\devel\sl\cool\linden\indra\llplugin /IC:\devel\sl\cool\linden\indra\media_plugins\base /I"C:\devel\vcpkg\installed\x64-windows\include" /nologo /W2 /WX /diagnostics:column /MP /O2 /Oi /D _WINDLL /D _UNICODE /D UNICODE /D WIN32 /D _WINDOWS /D NDEBUG /D _SECURE_SCL=0 /D _HAS_ITERATOR_DEBUGGING=0 /D LL_WINDOWS=1 /D UNICODE /D _UNICODE /D WINVER=0x0601 /D _WIN32_WINNT=0x0601 /D LL_NETBIOS=1 /D APR_DECLARE_STATIC /D BOOST_ALL_NO_LIB /D "CMAKE_INTDIR=\"Release\"" /D voice_plugin_webrtc_EXPORTS /EHs /GS- /fp:fast /Zc:wchar_t /Zc:forScope /Zc:inline /GR /std:c++17 /Fo"voice_plugin_webrtc.dir\Release\\" /Fd"voice_plugin_webrtc.dir\Release\vc143.pdb" /external:W0 /Gd /TP /errorReport:queue /external:I "C:/devel/sl/cool/linden/indra/../include/apr-1" /external:I "C:/devel/sl/cool/linden/indra/../include" /c /Zc:threadSafeInit- C:\devel\sl\cool\linden\indra\media_plugins\webrtc\voice_plugin_webrtc.cpp

CMake 3.29.5
============

C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Tools\MSVC\14.41.34120\bin\HostX64\x64\CL.exe /c /IC:\devel\sl\cool\linden\indra\llcommon /IC:\devel\sl\cool\linden\indra\llplugin /IC:\devel\sl\cool\linden\indra\media_plugins\base /I"C:\devel\vcpkg\installed\x64-windows\include" /nologo /W2 /WX /diagnostics:column /MP /O2 /Oi /D _WINDLL /D _UNICODE /D UNICODE /D WIN32 /D _WINDOWS /D NDEBUG /D _SECURE_SCL=0 /D _HAS_ITERATOR_DEBUGGING=0 /D LL_WINDOWS=1 /D UNICODE /D _UNICODE /D WINVER=0x0601 /D _WIN32_WINNT=0x0601 /D LL_NETBIOS=1 /D APR_DECLARE_STATIC /D BOOST_ALL_NO_LIB /D "CMAKE_INTDIR=\"Release\"" /D voice_plugin_webrtc_EXPORTS /Gm- /EHs /MD /GS- /fp:fast /Zc:wchar_t /Zc:forScope /Zc:inline /GR /std:c++17 /Fo"voice_plugin_webrtc.dir\Release\\" /Fd"voice_plugin_webrtc.dir\Release\vc143.pdb" /external:W0 /Gd /TP /errorReport:queue /external:I "C:/devel/sl/cool/linden/indra/../include/apr-1" /external:I "C:/devel/sl/cool/linden/indra/../include" /c /Zc:threadSafeInit- C:\devel\sl\cool\linden\indra\media_plugins\webrtc\voice_plugin_webrtc.cpp

Regarding the "unverified download" for Python.
Thats probably overkill and will only fail on a fresh Windows install.

I wondered if the install.py logic could simply be replaced by the CMake FetchContent (https://cmake.org/cmake/help/latest/mod ... ntent.html ) tooling so this step doesn't need Python? This should also fix the certificate warning.

Indeed !
After updating cmake to v3.30.3 (*) on my own VM, the build failed...

Inserting this code line 386 of linden/indra/cmake/00-Common.cmake fixes it:
This workaround will be part of next release.

Well, it does not really matter; the pre-built libraries packages integrity is verified via their hash, anyway, meaning we don't really care about where they are fetched from, as long as they are genuine... So the HTTPS cert is of no concern whatsoever.

Not sure it's doable, especially since the Python script reads from install.xml, and also must deal with zstd-compressed tar files (not natively supported under Windows), with the files caching (so that you can also build while offline), etc...

---

(*) I was still using v3.28, for the Windows VM (including the new I made, since I simply picked up the installer file I kept from the last build system update I did), while I always have the latest cmake version on my Linux PC.