Megapahit's fork of the Second Life viewer. https://megapahit.org/viewer.git/atom?h=26.1.1 2025-10-03T06:47:36Z 2025-10-03T06:47:36Z Erik Kundiman erik@megapahit.org 2025-10-03T06:47:36Z urn:sha1:2abdef7a44de20b95bc88807add94feec2fc569a 2025-07-07T14:32:30Z Erik Kundiman erik@megapahit.org 2025-07-07T14:32:30Z urn:sha1:2c3bebeec7c7490b5f2f22ee542ba99aeebfcb19 The Debian version supported is 13 (trixie), because that's the version I could install on my M1, hence the Boost default version is 1.83 & we can use system's OpenJPEG 2.5.3. Somehow CMake's FindOpenGL wasn't effective, but we can get around this by setting the GL libraries paths when running cmake. Debian aarch64 suffers from the same problem Fedora aarch64 had when compiling libcurl, and it's assumed that it's Linux aarch64 thing. When trying to build ColladaDOM when building the viewer, it couldn't find Boost somehow, so building ColladaDOM is done in configuration stage instead. Upstream Variables.cmake is full of assumptions regarding architecture, and ARCH is used in many places already for Debian/Ubuntu, so we have to make sure ARCH is set with the correct value at the root level. Pipewire on trixie is also too new, so it's cancelled here. Some dependencies have the t64 suffixes on them, just like the currently supported Ubuntu (because I guess 24.04 *is*, based on trixie). The executable still crashes when launched on my M1, however, but we'll commit the progress so far for now. 2025-06-11T16:32:22Z Erik Kundiman erik@megapahit.org 2025-06-11T16:32:22Z urn:sha1:3908abc96cb742623b2945eb382ad72628b234a0 cURL is installed on arm64 cause there doesn't seem to be any easy way to build OpenSSL 1.1 for Windows arm64 (which LL's cURL fork depends on). 2025-05-27T02:01:21Z Erik Kundiman erik@megapahit.org 2025-05-27T02:01:21Z urn:sha1:7ecde89008f9ed39c357b606d3bc231ba4360ee2 I happen to be using just Git Bash for convenience for running the commands on the Windows build instructions, hence the build folder pattern to be ignored from the result of running `uname -s` there. The instructions omit the part where you install vcpkg and set the VCPKG_ROOT environment variable, cause it depends on where you install vcpkg to your liking, but the next commands will rely on that variable being set correctly. The CMake used here is MS VS 2022 Community Edition's one, since it will know where the C++ compiler is. $VCPKG_ROOT/downloads/tools/msys2/21caed2f81ec917b/mingw64/bin is where pkg-config.exe can be found. $VCPKG_ROOT/installed/`uname -m|sed 's/86_//'`-windows/tools/libxml2 is where xmllint.exe can be found (from libxml2[tools]). PKG_CONFIG_LIBDIR and PYTHON environment settings are pretty self-explanatory. The flags set on LL_BUILD are now for Visual C++ and not MinGW(64)'s GCC or Clang any more, and copied from most of the flags in the variables file from LL's build-variables repo. vcpkg's apr & apr-util packages don't seem to install their .pc files, hence the manual target_include/link_directories/libraries settings, relying on some automatically generated INTERNAL CMake variable called prefix_result. vcpkg's Boost needs the same treatment, plus some suffix. We still use LL's prebuilt libs for OpenSSL, libcurl and WebRTC. Actually too for ColladaDOM for now, but we prepare Windows ColladaDOM self-building for later. For GLM and Meshoptimizer too, it's just the checking that's skipped otherwise it would fail (but the vcpkg packages can be used). Visual C++ doesn't recognise the no-deprecated-declarations compile option. On Visual C++, the macro to denote x86-64 seems to be _M_X64 (if not added there, it would try to find sse2neon :)) We still aren't using Autobuild here for Windows either, hence the FALSE-d viewer_manifest.py based file bundling. 2025-05-13T02:48:20Z Erik Kundiman erik@megapahit.org 2025-05-13T02:48:20Z urn:sha1:793bdbf972eca4c032813d6e2c4ef4e79d1628eb to make it more flexible the next time a value in the if's parentheses gets changed again, and also to reduce duplicate pattern matches when grepping those CMake files with certain keywords. 2025-05-13T02:22:54Z Erik Kundiman erik@megapahit.org 2025-05-13T02:22:54Z urn:sha1:f5ab6e11f13699c03a696611f67f8384434130a1 but the fact that we keep on using as many system libraries as we can (and only resort to other sources in certain cases), hasn't changed, of course. Also stop having to set USE_AUTOBUILD_3P to OFF. Lines are reindented, and when a system library can be found for a dependency, then that should be the way. If later we find out that using some other way is better, than stick to that. So, one option at a time, whichever is best for the situation. GLEXT hasn't been used, and in order to be not having to hack its .cmake file, we bypass it and refer to GLH (which is still used) right away in LLWindow. CMake commands that need to be bypassed, if it's a one-liner then it's just commented out, but if it's multiple lines, then scope them with if (FALSE) to minimise difference. 2025-04-27T11:44:29Z Erik Kundiman erik@megapahit.org 2025-04-27T11:44:29Z urn:sha1:211f9a7ff5ea50a60d4b57a75d956ed419f426d3 Same as reason as previous commit, plus the moving of OpenSSL libs up 1 directory is still needed. 2025-04-25T13:29:15Z Erik Kundiman erik@megapahit.org 2025-04-25T13:29:15Z urn:sha1:f28dc513890043e7bc0968f1292f55ec7e8cd20a so that the C90 standard setting is not used when compiling other dependencies such as OpenJPEG. 2025-04-20T09:57:02Z Erik Kundiman erik@megapahit.org 2025-04-20T09:57:02Z urn:sha1:a5677bc0390e2c0db0c0b8d4353b7423c555894b getpwuid_r, which is declared in /usr/include/pwd.h, somehow is always missed by, at least the custom, libcurl compiling process. I tried defining __USE_POSIX so the getpwuid_r part in pwd.h is included, I also tried undefining HAVE_GETPWUID_R so the getpwuid_r part in curl/lib/netrc.c is skipped (respectively using -D and -U CPPFLAGS ENV setting in indra/cmake/CURL.cmake), with no success. So just force the getpwuid_r part in netrc.c to be skipped by substituting defined(HAVE_GETPWUID_R) with 0. 2025-04-19T12:21:46Z Erik Kundiman erik@megapahit.org 2025-04-19T12:21:46Z urn:sha1:ad9c801edb13568657c0964ebfb74257da6d9e00 Media plugins enabling not yet. OpenXR is disabled for now (it hasn't been used anyway). perl-FindBin is needed to be able to build OpenSSL on Fedora aarch64. Setting the C standard to 90 when building cURL is needed, otherwise it would fail at configure time with a misleading error of not finding link/run time requirements for dependencies (such as nghttp2 and zlib), at least on Fedora (and macOS too back then, I remember). GCC treated SSE2NEON warnings as errors on so many files, so -Wno-cpp is added globally. The same Linux CPU frequency calculation needs to be out of the x86 scope, otherwise the viewer would complain about not meeting the requirements at launch time.