| Age | Commit message (Collapse) | Author |
|---|
|
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.
|
|
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.
|
|
This reverts commit 2170cca3a9f205bc6dda9d1b084ff5c8821186c9.
|
|
This reverts commit b8cc57486f3c15fd40d3524204c7fc0db3b7b8d4.
|
|
This reverts commit 6c1ff2e4b9da8069b9da573f99b52df707e97e75.
|
|
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 now, at least on Debian & Ubuntu, when building the volume
catcher, using PulseAudio, it refers to g_main_context_default too.
|
|
|
|
|
|
linkage fixes
|
|
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.
|
|
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.
|
|
|
|
|
|
System 2.5.2 caused too much rainbow in DeltaFPS. For now, the OpenJPEG
listed in autobuild.xml is 2.5.0. However, LL has recently got 2.5.2
too in their OpenJPEG fork repo, but we switch to that once it's the
one listed in autobuild.xml.
Reverting to the now maintained LL 3p-openjpeg should fix the texture
thrashing problem https://megapahit.com/show_bug.cgi?id=1 starting
from DeltaFPS.
|
|
2024.08-DeltaFPS
|
|
JsonCpp isn't used any more and Boost is linked statically now, so
SLPlugin doesn't need to link to any Boost dynamic libraries upwards
(which are of an older version and are there because they're still
needed by Collada DOM).
I suspect links to non-existent files have been the cause of why
Gatekeeper just wouldn't identify the developer despite the fact
that Apple notarisation service would still accept the bundle and
various Apple's integrity (command-line) tools would still validate
the bundle too.
This commit also removes unnecessary linkage changes for the media
plugins.
|
|
|
|
packages (#2250)
Rebuild expat, apr, meshoptimizer, ogg_vorbis, libjpeg-turbo for symbol fixes
|
|
since the app links to Meshoptimizer statically now on macOS.
|
|
This reverts commit 9268fdd5b99bb8e426e7c1232916dfd909039f96.
|
|
on macOS and at least the one directly. Collada DOM's Boost dependency
is still 1.76 in MacPorts' case, and that's why we still have Boost
filesystem and system dylibs in Frameworks. On the other hand, the
viewer codebase now really depends on newer Boost, in my case I can
use MacPorts' 1.81. I had to switch to static because Boost 1.81
filesystem crashed for not finding the implementation of something
declared using BOOST_FORCEINLINE in boost/filesystem/path.hpp.
I think I know why, now. Cause the filesystem dylib that eventually
got installed was the 1.76 one depended on by Collada DOM, so there
was a conflict, there. For now the temporary MacPorts solution for
this is to install boost181 with -no_static variant (notice the "-"
there, so the static libraries are built and installed too). The
rest is so hack-ish, I had to manually recreate Boost links pointing
to 1.81 ones, only the ones needed, and for the libraries, only the
static ones.
|
|
|
|
Root project finally renamed to Megapahit, which has a nice effect of
CPack: - Run preinstall target for: Megapahit
CPack: - Install project: Megapahit []
but it's really because CPack Bundle file couldn't be renamed via
CPACK_PACKAGE_NAME like on DEB, RPM, and FREEBSD.
CPack determines its own destination root folder, which is Resources
(I didn't find a way to set it to Contents).
fixup_bundle is now run on the .app deep inside CPack staging folders
so that the dependency copies will be included in the DMG.
|
|
|
|
but set CMAKE_INSTALL_PREFIX to newview/Megapahit.app/Contents.
|
|
Explanation just like previous commit.
There's a reference fix that doesn't seem to be valid any more.
First of all, the path leading to CEF framework would be wrong,
and secondly, the plugin doesn't seem to link to CEF.
|
|
|
|
Except for SLPlugin since there's already a custom command for it.
|
