Use dl handle for libva's vaTerminate rather than actual function

[chewi]

Description

libva is supposed to be optional. Building currently fails with an unresolved symbol if it is missing.

Type of Change

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• Dependency update (updates to dependencies)
• Documentation update (changes to documentation)
• Repository update (changes to repository files, e.g. .github/...)

Checklist

• My code follows the style guidelines of this project
• I have performed a self-review of my own code
• I have commented my code, particularly in hard-to-understand areas
• I have added or updated the in code docstring/documentation-blocks for new or existing methods/components

Branch Updates

LizardByte requires that branches be up-to-date before merging. This means that after any PR is merged, this branch
must be updated before it can be merged. You must also
Allow edits from maintainers.

• I want maintainers to keep my branch updated

[CLAassistant]

All committers have signed the CLA.

[ReenigneArcher]

libva is supposed to be optional

How did you come to that conclusion?

[chewi]

libva is supposed to be optional

How did you come to that conclusion?

If it was mandatory, you wouldn't load it with dlopen. 🙂 I've been packaging Sunshine for Gentoo Linux (more on than later) where do we our own ffmpeg build, and that can optionally be done without VAAPI support. I have successfully built and run Sunshine without any VAAPI support at all.

[ReenigneArcher]

our own ffmpeg build

Please include these patches, if you're not already. https://github.com/LizardByte/build-deps/tree/master/ffmpeg_patches

without VAAPI support

If you're building without vaapi support... then cmake should probably just be modified to not include the vaapi.cpp source. That's what we do for cuda, drm, wayland, x11

cuda:
https://github.com/LizardByte/Sunshine/blob/nightly/cmake/compile_definitions/linux.cmake#L15-L99

drm:

Sunshine/cmake/compile_definitions/linux.cmake

Lines 101 to 119 in a6ffeb4

	# drm
	if(${SUNSHINE_ENABLE_DRM})
	find_package(LIBDRM)
	find_package(LIBCAP)
	else()
	set(LIBDRM_FOUND OFF)
	set(LIBCAP_FOUND OFF)
	endif()
	if(LIBDRM_FOUND AND LIBCAP_FOUND)
	add_compile_definitions(SUNSHINE_BUILD_DRM)
	include_directories(SYSTEM ${LIBDRM_INCLUDE_DIRS} ${LIBCAP_INCLUDE_DIRS})
	list(APPEND PLATFORM_LIBRARIES ${LIBDRM_LIBRARIES} ${LIBCAP_LIBRARIES})
	list(APPEND PLATFORM_TARGET_FILES src/platform/linux/kmsgrab.cpp)
	list(APPEND SUNSHINE_DEFINITIONS EGL_NO_X11=1)
	elseif(NOT LIBDRM_FOUND)
	message(WARNING "Missing libdrm")
	elseif(NOT LIBDRM_FOUND)
	message(WARNING "Missing libcap")
	endif()

wayland:

Sunshine/cmake/compile_definitions/linux.cmake

Lines 121 to 143 in a6ffeb4

	# wayland
	if(${SUNSHINE_ENABLE_WAYLAND})
	find_package(Wayland)
	else()
	set(WAYLAND_FOUND OFF)
	endif()
	if(WAYLAND_FOUND)
	add_compile_definitions(SUNSHINE_BUILD_WAYLAND)
	GEN_WAYLAND("wayland-protocols" "unstable/xdg-output" xdg-output-unstable-v1)
	GEN_WAYLAND("wlr-protocols" "unstable" wlr-export-dmabuf-unstable-v1)
	include_directories(
	SYSTEM
	${WAYLAND_INCLUDE_DIRS}
	${CMAKE_BINARY_DIR}/generated-src
	)
	list(APPEND PLATFORM_LIBRARIES ${WAYLAND_LIBRARIES})
	list(APPEND PLATFORM_TARGET_FILES
	src/platform/linux/wlgrab.cpp
	src/platform/linux/wayland.cpp)
	endif()

x11:

Sunshine/cmake/compile_definitions/linux.cmake

Lines 145 to 156 in a6ffeb4

	# x11
	if(${SUNSHINE_ENABLE_X11})
	find_package(X11)
	else()
	set(X11_FOUND OFF)
	endif()
	if(X11_FOUND)
	add_compile_definitions(SUNSHINE_BUILD_X11)
	include_directories(SYSTEM ${X11_INCLUDE_DIR})
	list(APPEND PLATFORM_LIBRARIES ${X11_LIBRARIES})
	list(APPEND PLATFORM_TARGET_FILES src/platform/linux/x11grab.cpp)
	endif()

[cgutman]

I think this fix makes sense to take to allow builds that were compiled with VAAPI to be able to run without it present at runtime. It's a niche use case, but if the fix is just changing a single function call, I don't see any problem with it.

For builds without VAAPI, I agree with @ReenigneArcher that we should just not compile any of the VAAPI stuff in at all.

[ReenigneArcher]

I'll merge this then, and work on a second PR to allow disabling vaapi with a cmake flag.