mavlink
Building from source fails on current master w/ GStreamer 1.26 on Linux
It fails like this:
~/Qt/6.8.3/gcc_64/bin/qt-cmake -B build -G Ninja -DCMAKE_BUILD_TYPE=Debug
........
-- Checking for module 'gstreamer-rtsp-1.0'
-- Found gstreamer-rtsp-1.0, version 1.26.0
-- Checking for module 'gstreamer-gl-egl-1.0'
-- Found gstreamer-gl-egl-1.0, version 1.26.0
-- Checking for module 'gstreamer-gl-wayland-1.0'
-- Found gstreamer-gl-wayland-1.0, version 1.26.0
-- Checking for module 'gstreamer-gl-x11-1.0'
-- Found gstreamer-gl-x11-1.0, version 1.26.0
-- Found GStreamer: (found suitable version "1.26.0", minimum required is "1.20") found components: Core Base Video Gl GlPrototypes Rtsp GlEgl GlWayland GlX11
-- CPM: Adding package [email protected] (1.26.2 to /home/andre/prog/qgroundcontrol/build/cpm_modules/gstreamer_good_plugins/3bf24ab9f5df6f52a7e3f74774ba46ccfeee555f)
/home/andre/prog/qgroundcontrol/build/cpm_modules/gstreamer_good_plugins/3bf24ab9f5df6f52a7e3f74774ba46ccfeee555f/ext/qt6/vertex.vert -> vertex.vert.qsb exposed as :/org/freedesktop/gstreamer/qml6/vertex.vert.qsb
/home/andre/prog/qgroundcontrol/build/cpm_modules/gstreamer_good_plugins/3bf24ab9f5df6f52a7e3f74774ba46ccfeee555f/ext/qt6/YUV_TRIPLANAR.frag -> YUV_TRIPLANAR.frag.qsb exposed as :/org/freedesktop/gstreamer/qml6/YUV_TRIPLANAR.frag.qsb
/home/andre/prog/qgroundcontrol/build/cpm_modules/gstreamer_good_plugins/3bf24ab9f5df6f52a7e3f74774ba46ccfeee555f/ext/qt6/RGBA.frag -> RGBA.frag.qsb exposed as :/org/freedesktop/gstreamer/qml6/RGBA.frag.qsb
/home/andre/prog/qgroundcontrol/build/cpm_modules/gstreamer_good_plugins/3bf24ab9f5df6f52a7e3f74774ba46ccfeee555f/ext/qt6/YUV_BIPLANAR.frag -> YUV_BIPLANAR.frag.qsb exposed as :/org/freedesktop/gstreamer/qml6/YUV_BIPLANAR.frag.qsb
CMake Error at /home/andre/Qt/6.8.3/gcc_64/lib/cmake/Qt6Core/Qt6CoreMacros.cmake:1843 (message):
The source file
'/home/andre/prog/qgroundcontrol/build/src/VideoManager/VideoReceiver/GStreamer/gstqml6gl/.qsb/RGBA.frag.qsb.external'
was specified with an absolute path and is used in a Qt resource. Please
set the QT_RESOURCE_ALIAS property on that source file to a relative path
to make the file properly accessible via the resource system.
Call Stack (most recent call first):
/home/andre/Qt/6.8.3/gcc_64/lib/cmake/Qt6Core/Qt6CoreMacros.cmake:2371 (__qt_get_relative_resource_path_for_file)
/home/andre/Qt/6.8.3/gcc_64/lib/cmake/Qt6Core/Qt6CoreMacros.cmake:406 (_qt_internal_process_resource)
/home/andre/Qt/6.8.3/gcc_64/lib/cmake/Qt6Core/Qt6CoreMacros.cmake:458 (qt6_add_resources)
CMakeLists.txt:549 (qt_add_resources)
I think this should only happen with GStreamer 1.26 right? Linux probably shouldn't be using 1.26, I only tested it with Android
After applying the fix, I get the following (Arch linux, Qt 6.8.3)
ninja: error: 'src/VideoManager/VideoReceiver/GStreamer/gstqml6gl/.qsb/RGBA.frag.qsb.external', needed by '.qt/rcc/qrc_qgcresources_cmake.cpp', missing and no known rule to make it
Any clues? 🙏
Yeah I noticed it's still an issue. Just don't use 1.26 for now I guess. I will try to fix in the next couple of days
It's also worth mentioning that when 1.26 becomes supported, we can do away with the CMake hackery for finding the library on macOS and instead simply use find_package(), since this version finally provides its own FindGStreamer.cmake.
It's also worth mentioning that when 1.26 becomes supported, we can do away with the CMake hackery for finding the library on macOS and instead simply use
find_package(), since this version finally provides its ownFindGStreamer.cmake.
I'll believe it when I see it :)
Unless this is a "works on my machine" situation, the following snippet configures and compiles without issue both on Arch (sudo pacman -S gstreamer gst-plugins-good) and macOS (brew install gstreamer):
main.c
#include <gst/gst.h>
int main(int argc, char* argv[]) {
gst_init(&argc, &argv);
gst_deinit();
}
CMakeLists.txt
cmake_minimum_required(VERSION 3.30)
project(CanWeFindGStreamer LANGUAGES C)
add_executable(dummy main.c)
# Necessary in my case, because otherwise Qt's FindGStreamer.cmake will be used.
list(APPEND CMAKE_MODULE_PATH /opt/homebrew/opt/gstreamer/share/cmake)
# GStreamer doesn't use COMPONENTS for whichever reason, instead
# you set this variable and targets will be created accordingly.
set(GSTREAMER_APIS gl rtsp)
find_package(GStreamer REQUIRED)
target_link_libraries(dummy PRIVATE
GStreamer::GStreamer
GStreamer::gl
GStreamer::rtsp
)
There might be stuff in your build pipeline I'm too novice to understand preventing this from happening, but I think it'd be nice if the project used find_package() as much as possible instead of CPM and bespoke find modules/installer shell scripts.
CPM calls find_package internally. The current setup is the most painless way to support all the different platforms with all the different external libraries we use. Otherwise cross-compiling, lack of software support for Arm platforms, and mobile support become extremely convoluted to handle. The only custom find module we are using is for gstreamer, and I already have it mostly set up to integrate with the FindGStreamer.cmake provided by GStreamer 1.26. I'd like to just build a minimal gstreamer (optionally) during the regular build process which would help tremendously, but I haven't gotten around to that.
"works on my machine" has always worked easily. Getting a DMG to build that works on a machine which does not already have GStreamer on it has always been a painful sequence of trial an error.
Ah, understandable, thanks for the info. I don't intend to act like an armchair general, just wanted to let y'all know that this is a thing now.
Also, good to know about CPM finding packages the "CMake way". I was afraid I'd have to re-download everything every time I did a fresh configure. 🤠 and cross-compiling is indeed a great way to lose your mind.
IDK about DMG magic, but that could could fix the issue for Linux - and be be used for Linux builds?
@lyorig CPM should already be caching all the dependencies, based on the QGC_CPM_SOURCE_CACHE CMake variable. But it's also set up in a way where you can do git submodules (or just local files) if you wanted and override the CPM dependency path such that it pulls from those files instead.
@AndKe If I remember right the Linux issue was just building the Qt plugin for GStreamer 1.26. We like to keep the required GStreamer version the same across platforms and I didn't want to force people to build GStreamer since the most recent Ubuntu LTS only has GStreamer 1.24. I'll look into the 1.26 stuff more soon.
@HTRamsey thanks, I do get that some distro/some LTS may use older version, but it is unusual to require a specific version of something like this, if we had this situation for everything, we would end up being compatible with only one specific release of one specific distro.
QGC has always recommended a certain GStreamer version. A certain version isn't 'required', it's just we don't guarantee other versions to work so it's up to the user to test it and resolve issues on their own. There's many reasons for this including plugin availability, API usage, having to build the GStreamer Qt plugin, bugs on certain versions, etc. If we let people use whatever then I'd have to test every version on every platform, adjust the code to tolerate an infinite many possibilities, and likely have a million more issue tickets to resolve.
Always welcome ready-made solutions in the form of PRs from people though.
but it is unusual to require a specific version of something like this
Everything with GStreamer is "unusual" since it takes 5 gallons of chicken blood thrown up in the air to get anything at all to work.
Understood. So you know the solution, is it the price of blood or the cleaning afterwards that causes the delay then?