Created attachment 876263 [details] emerge --info output Setting the glslang flag causes the merge to fail during the abi_x86_32 configure stage. Build proceeds as usual without errors with USE=-glslang. Current USE="X alsa cpudetection dav1d doc encode gpl iconv lcms libdrm lv2 mp3 network opencl opengl openssl postproc pulseaudio sdl svg threads truetype vaapi vorbis vulkan x264 x265 xvid zlib" ABI_X86="32 64" Relevant portion of config.log: test_cc BEGIN /tmp/portage/media-video/ffmpeg-6.1/temp/ffconf.OyvtunbL/test.c 1 #include <glslang/Include/glslang_c_interface.h> 2 #include <stdint.h> 3 long check_glslang_initialize_process(void) { return (long) glslang_initialize_process; } 4 int main(void) { int ret = 0; 5 ret |= ((intptr_t)check_glslang_initialize_process) & 0xFFFF; 6 return ret; } END /tmp/portage/media-video/ffmpeg-6.1/temp/ffconf.OyvtunbL/test.c gcc -m32 -mfpmath=sse -D_ISOC99_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_POSIX_C_SOURCE=200112 -D_XOPEN_SOURCE=600 -DPIC -march=bdver2 -O2 -ftree-vectorize -fsched-pressure -march=bdver2 -std=c11 -fPIC -pthread -I/usr/include/lilv-0 -I/usr/include/serd-0 -I/usr/include/sord-0 -I/usr/include/sratom-0 -I/usr/include/libdrm -I/usr/include/freetype2 -I/usr/include/harfbuzz -I/usr/include/freetype2 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -c -o /tmp/portage/media-video/ffmpeg-6.1/temp/ffconf.OyvtunbL/test.o /tmp/portage/media-video/ffmpeg-6.1/temp/ffconf.OyvtunbL/test.c gcc -m32 -mfpmath=sse -Wl,--as-needed,-O2 -fuse-ld=lld -march=bdver2 -Wl,--as-needed -Wl,-z,noexecstack -o /tmp/portage/media-video/ffmpeg-6.1/temp/ffconf.OyvtunbL/test /tmp/portage/media-video/ffmpeg-6.1/temp/ffconf.OyvtunbL/test.o -lglslang -lMachineIndependent -lOSDependent -lHLSL -lOGLCompiler -lGenericCodeGen -lSPVRemapper -lSPIRV -lSPIRV-Tools-opt -lSPIRV-Tools -lpthread -lstdc++ -lm ld.lld: error: unable to find library -lSPIRV-Tools-opt ld.lld: error: unable to find library -lSPIRV-Tools collect2: error: ld returned 1 exit status require spirv_compiler glslang/Include/glslang_c_interface.h glslang_initialize_process -lglslang -lOSDependent -lHLSL -lOGLCompiler -lSPVRemapper -lSPIRV -lSPIRV-Tools-opt -lSPIRV-Tools -lpthread -lstdc++ -lm check_lib spirv_compiler glslang/Include/glslang_c_interface.h glslang_initialize_process -lglslang -lOSDependent -lHLSL -lOGLCompiler -lSPVRemapper -lSPIRV -lSPIRV-Tools-opt -lSPIRV-Tools -lpthread -lstdc++ -lm check_func_headers glslang/Include/glslang_c_interface.h glslang_initialize_process -lglslang -lOSDependent -lHLSL -lOGLCompiler -lSPVRemapper -lSPIRV -lSPIRV-Tools-opt -lSPIRV-Tools -lpthread -lstdc++ -lm test_ld cc -lglslang -lOSDependent -lHLSL -lOGLCompiler -lSPVRemapper -lSPIRV -lSPIRV-Tools-opt -lSPIRV-Tools -lpthread -lstdc++ -lm test_cc BEGIN /tmp/portage/media-video/ffmpeg-6.1/temp/ffconf.OyvtunbL/test.c 1 #include <glslang/Include/glslang_c_interface.h> 2 #include <stdint.h> 3 long check_glslang_initialize_process(void) { return (long) glslang_initialize_process; } 4 int main(void) { int ret = 0; 5 ret |= ((intptr_t)check_glslang_initialize_process) & 0xFFFF; 6 return ret; } END /tmp/portage/media-video/ffmpeg-6.1/temp/ffconf.OyvtunbL/test.c gcc -m32 -mfpmath=sse -D_ISOC99_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_POSIX_C_SOURCE=200112 -D_XOPEN_SOURCE=600 -DPIC -march=bdver2 -O2 -ftree-vectorize -fsched-pressure -march=bdver2 -std=c11 -fPIC -pthread -I/usr/include/lilv-0 -I/usr/include/serd-0 -I/usr/include/sord-0 -I/usr/include/sratom-0 -I/usr/include/libdrm -I/usr/include/freetype2 -I/usr/include/harfbuzz -I/usr/include/freetype2 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -c -o /tmp/portage/media-video/ffmpeg-6.1/temp/ffconf.OyvtunbL/test.o /tmp/portage/media-video/ffmpeg-6.1/temp/ffconf.OyvtunbL/test.c gcc -m32 -mfpmath=sse -Wl,--as-needed,-O2 -fuse-ld=lld -march=bdver2 -Wl,--as-needed -Wl,-z,noexecstack -o /tmp/portage/media-video/ffmpeg-6.1/temp/ffconf.OyvtunbL/test /tmp/portage/media-video/ffmpeg-6.1/temp/ffconf.OyvtunbL/test.o -lglslang -lOSDependent -lHLSL -lOGLCompiler -lSPVRemapper -lSPIRV -lSPIRV-Tools-opt -lSPIRV-Tools -lpthread -lstdc++ -lm ld.lld: error: unable to find library -lSPIRV-Tools-opt ld.lld: error: unable to find library -lSPIRV-Tools collect2: error: ld returned 1 exit status ERROR: spirv_compiler not found Did some digging, dev-util/spirv-tools was installed but only for ABI_X86_64. Rebuilt it for both 32 and 64 bits and merge proceeded normally with USE=glslang. I'm guessing a missing multilib dependency in the ebuild?
Please include the full build.log and in this case also the full config.log
Created attachment 876276 [details] emerge log
Created attachment 876277 [details] config.log
*** Bug 922449 has been marked as a duplicate of this bug. ***
Maybe it helps, I found this forum entry: https://www.linuxquestions.org/questions/slackware-14/regression-on-current-with-ffmpeg-4175728462/ And this ffmpeg mailing list entry: https://ffmpeg.org/pipermail/ffmpeg-devel/2024-January/319892.html I tried ffmpeg-9999 in hope that the patch is included (I did not check it; the build fails with the same error btw) and I noticed we don't have glslang 14 on gentoo, which is the version the mailing list entry talks about. So I tried to unmask glslang-9999 and got into a big web of masked vulkan and spirv packages and couldn't untangle it to try out if more recent software solves the problem. It ffmpeg worked with glslang-1.3.268, but that cannot be installed while simultaneously having llvm-17, because dev-util/spirv-llvm-translator-17.0.0-r2 requires glslang-1.3.275. An older ebuild of spirv-llvm-translator-17.0.0 (was it -r1?) worked with glslang-1.3.268 but was removed from the portage tree.
Thanks Mark, patch from https://ffmpeg.org/pipermail/ffmpeg-devel/2024-January/319892.html did work for me with ffmpeg-6.1.1-r2
That patch does the trick, thank you.
Created attachment 886244 [details, diff] patch from the ffmpeg ML please add the patch, it also works with (and is required for) -r4
had the same issue with ffmppeg-6.6.1-r5 and applied to /etc/portage/patches fixed the issue. this is pretty old surprised it hasn't been addressed
...and media-video/ffmpeg-6.1.1-r5 was somehow stabilized despite this...:sigh:... You could add bug 922333 to duplicates. The relevant upstream commit (only on 7.0 branch and later) is https://git.ffmpeg.org/gitweb/ffmpeg.git/commit/e43615fc2ab27d562ed7e087803f4a364a7d1175.
...however that commit is still incorrect, at least for Gentoo. MachineIndependent and GenericCodeGen are only built as separate libs when glslang isn't built as a shared library. ffmpeg upstream should be notified about this, if they're not aware yet (I don't see any more recent commits on this topic).
So, first of all, I can confirm the bug. Next, the bug persisted also with ffmpeg-6.1.1-r5, r6 and now r8. Finally, I fixed it by creating a patch (glslang.patch), putting it in the files dir, and adding a line in the ebuild to call it. With the patch, all versions compile and, so far, work quite well for me.
Created attachment 898462 [details] Ebuild for ffmpeg-6.1.1-r8 including the call to the patch (see comment 12)
Created attachment 898463 [details, diff] Patch called by the ebuild for ffmpeg-6.1.1-r8
I just noticed my patch is almost identical to the one first uploaded by Mark in January! Oops... :) Kudos to Mark, I guess.
Confirmed. shaderc is a reasonable substitute.
*** Bug 948874 has been marked as a duplicate of this bug. ***
(In reply to dE from comment #16) > Confirmed. shaderc is a reasonable substitute. On that note, in libplacebo been thinking to drop USE=glslang entirely (see bug #945783, albeit I haven't followed up on that yet) in favour of shaderc given glslang breaks things too often and had about enough of it (shaderc is also preferred upstream, using glslang directly was only a fallback). Arguably dropping it here too or masking could be an option to reduce maintenance burden, esp. for older ffmpeg branches which aren't keeping up.
I faced the same bug with media-video/ffmpeg-6.1.2. Still not fixed.
(In reply to Karlson2k from comment #19) > I faced the same bug with media-video/ffmpeg-6.1.2. > Still not fixed. I've heard rumors that shaderc is now favored upstream for stability (sorry don't have link). I have since switched over without issue. But yes IMHO this ticket should still be addressed media-video/ffmpeg -glslang shaderc
