On Mon, 22 Jan 2024, Lynne wrote:
Jan 22, 2024, 07:52 by ffmpeg-devel@ffmpeg.org:
Since glslang 14.0.0, OGLCompiler and HLSL stub libraries have been
fully removed from the build.
This fixes the configuration by detecting if the stub libraries are
still present (glslang releases before version 14.0.0).
ffbuild/config.log:
/usr/lib/gcc/x86_64-pc-linux-gnu/13/../../../../x86_64-pc-linux-gnu/bin/ld:
cannot find -lOSDependent: No such file or directory
/usr/lib/gcc/x86_64-pc-linux-gnu/13/../../../../x86_64-pc-linux-gnu/bin/ld:
cannot find -lHLSL: No such file or directory
/usr/lib/gcc/x86_64-pc-linux-gnu/13/../../../../x86_64-pc-linux-gnu/bin/ld:
cannot find -lOGLCompiler: No such file or directory
Addresses https://trac.ffmpeg.org/ticket/10713
See https://bugs.gentoo.org/show_bug.cgi?id=918989
Should fix https://ffmpeg.org/pipermail/ffmpeg-devel/2023-August/313666.html
Signed-off-by: Matthew White <mehw.is...@inventati.org>
---
configure | 23 +++++++++++++++++++++--
1 file changed, 21 insertions(+), 2 deletions(-)
diff --git a/configure b/configure
index c8ae0a061d..abff488dc0 100755
--- a/configure
+++ b/configure
@@ -2626,6 +2626,7 @@ CMDLINE_SET="
ignore_tests
install
ld
+ libglslang_ldflags
ln_s
logfile
malloc_prefix
@@ -6652,6 +6653,24 @@ if enabled_all libglslang libshaderc; then
die "ERROR: libshaderc and libglslang are mutually exclusive, if in doubt, disable
libglslang"
fi
+if enabled libglslang; then
+ if [ -x "$(command -v glslang)" ]; then
+ # https://github.com/KhronosGroup/glslang
+ # commit 6be56e45e574b375d759b89dad35f780bbd4792f: Remove
`OGLCompiler` and `HLSL` stub libraries from build
+ # StandAlone/StandAlone.cpp:
"SpirvGeneratorVersion:GLSLANG_VERSION_MAJOR.GLSLANG_VERSION_MINOR.GLSLANG_VERSION_PATCH
GLSLANG_VERSION_FLAVOR"
+ glslang_version="$(glslang -dumpversion)"
+ glslang_major="${glslang_version%%.*}"
+ glslang_major="${glslang_major#*:}"
+ if test ${glslang_major} -le 13; then
+ libglslang_ldflags=" -lOSDependent -lHLSL -lOGLCompiler"
+ elif ! [[ ${glslang_major} =~ ^[0-9]+$ ]]; then
+ die "ERROR: glslang's computed major version isn't a number:
'${glslang_major}'"
+ fi
+ else
+ die "ERROR: glslang binary not found, impossible to determine installed
glslang's version"
+ fi
+fi
+
check_cpp_condition winrt windows.h
"!WINAPI_FAMILY_PARTITION(WINAPI_PARTITION_DESKTOP)"
if ! disabled w32threads && ! enabled pthreads; then
@@ -6771,10 +6790,10 @@ enabled libfreetype && require_pkg_config libfreetype
freetype2 "ft2build.
enabled libfribidi && require_pkg_config libfribidi fribidi fribidi.h
fribidi_version_info
enabled libharfbuzz && require_pkg_config libharfbuzz harfbuzz hb.h
hb_buffer_create
enabled libglslang && { check_lib spirv_compiler
glslang/Include/glslang_c_interface.h glslang_initialize_process \
- -lglslang -lMachineIndependent -lOSDependent
-lHLSL -lOGLCompiler -lGenericCodeGen \
+ -lglslang -lMachineIndependent
"${libglslang_ldflags}" -lGenericCodeGen \
-lSPVRemapper -lSPIRV -lSPIRV-Tools-opt -lSPIRV-Tools -lpthread -lstdc++ -lm ||
require spirv_compiler glslang/Include/glslang_c_interface.h
glslang_initialize_process \
- -lglslang -lOSDependent -lHLSL -lOGLCompiler \
+ -lglslang "${libglslang_ldflags}" \
-lSPVRemapper -lSPIRV -lSPIRV-Tools-opt -lSPIRV-Tools -lpthread -lstdc++ -lm; }
enabled libgme && { check_pkg_config libgme libgme gme/gme.h
gme_new_emu ||
require libgme gme/gme.h gme_new_emu -lgme -lstdc++; }
--
2.43.0
This is very very cursed. Fitting for the public API of the world's
fifth worst library. Debian is stuck on version 13, so the majority of
users are still stuck on version 13. Debian ships a pkg-config file, but
of course it's incorrect, if you try to compile against it. Oh, and
libshaderc in Debian ships with a bug such that it segfaults on init, so
it's not like you can avoid that. And that package's pkg-config file got
broken in the past.
I think this is fine for now. I'll let it be discussed for a few more
days before merging it.
I think breaking cross compilation with glslang is pretty bad. Apparently
VLC doesn't enable glslang in their ffmpeg builds though, but I would
expect that some does.
Wouldn't it just be possible to test whether linkins succeeds with one set
of libraries, and if not, try with the other set, and pick whichever set
works with the library at hand? That would be way much simpler than this
patch, and also work for cross compilation.
// Martin
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
