| Age | Commit message (Collapse) | Author |
|---|
|
OpenAL and LL's WebRTC now break CEF too just like on many other
supported distros.
Same as Ubuntu 24.04.2 when it comes to not yet compatible newer
Pipewire, but OpenJPEG 2.5.3 (unlike 24.04.2 which is still at 2.5.0).
The libminizip1 package name is also fixed here for Ubuntu.
|
|
When WebRTC was compiled with the viewer, we got this:
Fatal error in: ../webrtc/src/media/engine/adm_helpers.cc, line 39
last system error: 88
Check failed: 0 == adm->Init() (0 vs. -1)
Failed to initialize the ADM.
This commit hasn't included the additional preprocessor macro for the
platform in indra/newview/llvoiceclient.cpp yet, because there's no such
macro yet to distinguish such distro from any other GNU/Linux distro.
|
|
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.
|
|
Parsing failed on macOS' CMake (could be MacPorts, could be the version)
for some reason.
|
|
Crow Misia's libwebrtc-bin, the one we've been relying on for WebRTC
binaries, doesn't seem to be providing Windows arm64 binaries yet.
|
|
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.
|
|
Shorter.
|
|
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.
|
|
cause somehow WebRTC voice didn't work with LL's (Vivox still worked)..
Also with LL's, so many devices detected;
while with CM's, only built-in audio input device detected.
|
|
I've tried using FMOD instead, but CEF didn't work either.
At first I used crow-misia's WebRTC build but it would cause a
segmentation fault, but LL's build seems to break CEF.
Gotta find a way so CM's build doesn't crash the viewer.
PKGBUILD should be moved to indra/newview as an .in to be configured
by CMake for dynamic version numbers, and adjust the instruction
too to run makepkg -R from the folder where the generated PKGBUILD
will be.
|
|
Also simplify CMake-based dependency projects, the parameters that
have been set for the viewer seem to have been implied all this time
for the subprojects.
|
|
|
|
Now that it's only Debian and macOS x86-64 that are left safe to use
LL's WebRTC build, the logic is reversed.
|
|
Thanks to the Linux x86-64 WebRTC binary from Zenichi Amano (crow-misia).
https://megapahit.com/show_bug.cgi?id=64
Haven't been tested on openSUSE, but it should work.
|
|
on macOS arm64, the header directory.
|
|
|
|
It breaks CEF on these platforms.
|
|
for macOS arm64.
|
|
|
|
|
|
Still triggered by upstream autobuild.xml even though there is
actually no need to update on macOS arm64's side.
|
|
|
|
2024.06-atlasaurus
|
|
for when autobuild's not installed.
|
|
|
|
|
|
|
|
|
|
|
|
Also, start/stop recording depending on whether WebRTC has negotiated.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
