| Age | Commit message (Collapse) | Author |
|---|
|
So CEF would stop complaining about missing libGLESv2.so on Linux.
Another link, which is for libvulkan.so.1.
System libEGL would break newer CEF so we're bundling it, it's not so
big. The JSON file is so we make sure we include everything a typical
system CEF would.
|
|
|
|
|
|
Arch's system CEF version is 147 so we choose Dullahan version 1.30.
|
|
Fedora's system CEF version is 146.0.11 so we choose the Dullahan
version that uses the next closest CEF version (146.0.12 and not
146.0.10), which is Dullahan 1.29 and not 1.28.
System libcef_dll is somehow distributed only in source form
(on Arch too), so in order to be able to link to it, we have to
compile it first, but its CMakeLists.txt is a sub one, incomplete,
so we use the solution of adding an empty macro:
https://www.magpcss.org/ceforum/viewtopic.php?f=6&t=17732
System CEF's library encapsulating folder that contains libcef.so,
hence needs to be add to runtime path.
|
|
This reverts commit 8f11eb47a617d3a1344a39ed37dd1de3b422fb0b.
|
|
For convenience, on x86-64 we choose the next closest version that has
prebuilt binary so we don't have to build (we could, I've tried and it
worked too). While on aarch64, we have to compile like before and we
choose the same Dullahan version too as on Windows and macOS, for this
parity branch with SLv's.
|
|
This includes files of WebRTC, Discord, VLC & CEF and their media
plugins & resources.
This is so they won't clash just in case some other packages install
files with the same names in system library directories.
Furthermore, this seems to prevent Dullahan/CEF from breaking in
general.
The path to this encapsulating folder needs to be added as a runtime
path to especially dullahan_host & libmedia_plugin_cef.so so they can
find libcef.so etc, also for the viewer to find libllwebrtc.so &
libdiscord_partner_sdk.so. And that's why `patchelf` needs to be made
sure it's installed.
|
|
and use PipeWire instead of PulseAudio for controlling web media
volume by default.
|
|
This reverts commit 2170cca3a9f205bc6dda9d1b084ff5c8821186c9.
|
|
This reverts commit b8cc57486f3c15fd40d3524204c7fc0db3b7b8d4.
|
|
This reverts commit 6c1ff2e4b9da8069b9da573f99b52df707e97e75.
|
|
I didn't see a quick way to replace libvlc_MediaPlayerTitleChanged,
though, so I guess there's no title notification yet for the platform
that uses VLC 4 (Gentoo will, so far). Will do this later.
|
|
It no longer exists in Dullahan 1.24, my old development system
must have had leftovers from Dullahan 1.14.
|
|
|
|
Effectively all Un*x distros now.
|
|
and remove unnecessary links, such as to graphics libraries.
CEF framework is still in the viewer bundle's Frameworks, with the
link in SLPlugin's, as moving it to SLPlugin's would cause it to
not work even though the media plugin gets loaded.
|
|
Somehow the absence of the variable declaration would break CEF
media plugin on Arch (just like it happened on openSUSE Tumbleweed)
when it's not even used any more anywhere else. It's a different
variable from the one whose absence broke CEF on Tumbleweed.
Apart from that, the package now explicitly pulls at-spi2-core, which
contains libatk-1.0.so.0, libatk-bridge-2.0.so.0 and libatspi.so.0 which
are linked by libmedia_plugin_cef.so. at-spi2-core may not necessarily
get pulled by some other package on a minimal fresh Arch installation.
|
|
|
|
|
|
Somehow the absence of the variable declaration would break CEF
media plugin on openSUSE Tumbleweed (and not on other supported
distros), when it's not even used any more anywhere else.
|
|
I've tried getting Dullahan 1.21 compiled with Spotify's CEF 139,
it did build, but the internal browser didn't work, so what would be the
point. I could have missed something, but we're sticking with Dullahan
1.14 on Linux for now.
|
|
Somehow now, at least on Debian & Ubuntu, when building the volume
catcher, using PulseAudio, it refers to g_main_context_default too.
|
|
|
|
|
|
linkage fixes
|
|
|
|
plugin accordingly to take account of Dullahan cache changes
|
|
sequence.
|
|
its own cache/cookies folder (previous commit). It also changes the Test Bookmarks page to a heavily updated one with new links and a filter/search mechanism
|
|
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.
|
|
it's own cache/cookie folder underneath the parent cef_cache folder. The whole cef_cache folder structure is purged at startup (before the parent being created at the first media instance creation)
|
|
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.
|
|
|
|
Put the necessary files into place.
But, none of them is working just yet.
|
|
Thank you Fritigern Gothly for noticing this lot of GPU/EGL and/or shader
related errors. After the Megapahit process have exited, she still saw the system
trying to find Vulkan libs in the Megapahit installation folder,
[0522/173723.156996:FATAL:gpu_init.cc(500)] Passthrough is not
supported, GL is angle, ANGLE is swiftshader
Warning: Couldn't load Vulkan. Searched
/usr/libexec/megapahit/libvk_swiftshader.so,
/usr/lib/x86_64-linux-gnu/libvk_swiftshader.so,
/usr/libexec/megapahit/libvk_swiftshader.so, libvk_swiftshader.so.
at operator() (../../third_party/dawn/src/dawn/nativWarning:
Couldn't load Vulkan. Searched
/usr/libexec/megapahit/libvk_swiftshader.so,
/usr/lib/x86_64-linux-gnu/libvk_swiftshadere/vulkan/BackendVk.cpp:299)
at Initialize
(../../third_party/dawn/src/dawn/native/vulkan/BackendVk.cpp:310)
at Create (..so, /usr/libexec/megapahit/libvk_swiftshader.so,
libvk_swiftshader.so.
at operator()
(../../third_party/dawn/src/dawn/nativ./../third_party/dawn/src/dawn/native/vulkan/BackendVk.cpp:266)
at operator()
(../../third_party/dawn/src/dawn/native/vulkane/vulkan/BackendVk.cpp:299)
at Initialize
(../../third_party/dawn/src/dawn/native/vulkan/BackendVk.cpp:310)
at Create (./BackendVk.cpp:521)
./../third_party/dawn/src/dawn/native/vulkan/BackendVk.cpp:266)
at operator()
(../../third_party/dawn/src/dawn/native/vulkan/BackendVk.cpp:521)
Warning: Couldn't load Vulkan. Searched
/usr/libexec/megapahit/libvk_swiftshader.so,
/usr/lib/x86_64-linux-gnu/libvk_swiftshader.so,
/usr/libexec/megapahit/libvk_swiftshader.so, libvk_swiftshader.so.
at operator()
(../../third_party/dawn/src/dawn/native/vulkan/BackendVk.cpp:299)
at Initialize
(../../third_party/dawn/src/dawn/native/vulkan/BackendVk.cpp:310)
at Create
(../../third_party/dawn/src/dawn/native/vulkan/BackendVk.cpp:266)
at operator()
(../../third_party/dawn/src/dawn/native/vulkan/BackendVk.cpp:521)
Since SwiftShader doesn't seem to be available on Linux distro repos, it's going
to have to be bundled and just placed in normal paths since it wouldn't
conflict, instead of having some SwiftShader system library being
pulled.
|
|
This reverts commit 3a36cdf6ebd9d2795bdcd14162f38df568d51796.
|
|
Shorter.
|
|
Pipewire in Portage has been upgraded from 1.2.7 to 1.4.2 recently.
Among our supported distros, Debian and Ubuntu are the only ones left
whose Pipewire versions are still 1.2.7, hence the changed logics.
|
|
since it's upgraded to 1.4.1 in Fedora 42 from stable 1.2.7 in Fedora
41, and there seem to be API changes and we're not ready for them yet.
|
|
Gentoo uses lib64, just like Fedora, and has libexec too.
The necessary step to install dependencies is part of the ebuild script
now (tracked in another repo, ebuild.git).
One thing I forgot to mention on the commit in that ebuild repo is,
unzip.h is provided on Gentoo only by minizip, and not minizip-ng cause
somehow the (minizip) "compat" USE flag couldn't be turned on somehow,
and there was no "minizip" (without -ng) package on Gentoo, but it was
achievable by setting the "minizip" USE flag on the zlib (again, without
-ng) package.
The queue header inclusion is needed cause its absence would cause the
compiling to fail on Portage (though it compiled when building the
viewer manually without Portage).
Also, using the prebuilt Meshoptimizer caused some linking errors when
using Portage (though, again, it linked when building the viewer
manually without Portage), hence Meshoptimizer is built from source as
part of the CMake configuration on Gentoo, differing from fellow Linux
distros.
Now Collada DOM, firstly the unpack destination directory is moved to
inside the build directory now, to make it uniform with other 3rd-party
files, just for less confusion. Secondly, since the patching that takes
effect is the one done by Portage, it would kill the process when there
are offending failed patchings (ones that generate .rej, reject files),
and they are the vcxproj patchings which aren't used anyway. Thirdly,
the hash checking on the downloaded file, that would fail anyway since
Portage doesn't allow any downloading that isn't part of the ebuild,
unfortunately has to be skipped so the emerge process wouldn't be killed
just because of it. Ebuild has its own sum checking (though this means
this particular file is not checked on other platforms, but other files
aren't checked either anyway yet).
Last but not least, the XDG Application category is removed because it's
considered deprecated by Portage, though not fatal, but the viewer is
already shown well in the Internet (Network) submenu anyway on unix
desktops.
|
|
since they upgraded to 1.4.1 from stable 1.2.7 and there seem to be API
changes and we're not ready for them yet.
|
|
and therefore LL's Collada DOM can be upgraded to something newer
than r4, and therefore PCRE can be no longer depended on.
Have to set the C++ standard so it doesn't use anything old, but
also it wasn't ready for something as new as C++20 yet, that's why
it's explicitly set to C++17.
Have to set the architecture too when you're cross-compiling,
it would use the native architecture.
|
|
since they upgraded to 1.3.83 from stable 1.2.7 and there seem to be API
changes and we're not ready for them yet.
|
|
|
|
Some builders might just have their installation somehow customised to
have both.
|
|
as in Arch, there's really no /usr/libexec.
|
|
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.
|
|
|
|
|
