Created attachment 882324 [details] gcc-full-lto env file I having problem compiling obs-studio since I change to the LLVM profile I gonna add in the attchments build log for: 1-Clang with lto 2-Clang without lto 3-Gcc (full toolchain) with lto 4-Gcc (full toolchain) without lto
(In reply to Gonçalo Negrier Duarte from comment #0) > Created attachment 882324 [details] > gcc-full-lto env file > > I having problem compiling obs-studio since I change to the LLVM profile I > gonna add in the attchments build log for: > 1-Clang with lto > 2-Clang without lto > 3-Gcc (full toolchain) with lto > 4-Gcc (full toolchain) without lto
Created attachment 882325 [details] gcc-full env file
Created attachment 882327 [details] 1-clang-lto.log
Created attachment 882328 [details] 2-clang_no_lto.log
(In reply to Gonçalo Negrier Duarte from comment #0) > Created attachment 882324 [details] > gcc-full-lto env file > > I having problem compiling obs-studio since I change to the LLVM profile I > gonna add in the attchments build log for: > 1-Clang with lto > 2-Clang without lto > 3-Gcc (full toolchain) with lto > 4-Gcc (full toolchain) without lto Also gonna add: 5-Gcc (only compiler) with lto 5-Gcc (only compiler) without lto
Created attachment 882330 [details] gcc-lto env file
Created attachment 882331 [details] gcc env fle
Created attachment 882333 [details] 1-clang-lto.log
Created attachment 882334 [details] 2-clang_no_lto.log
Created attachment 882335 [details] 3-gcc_full_lto.log
Created attachment 882336 [details] 3-gcc_full.log
Created attachment 882337 [details] 5-gcc_lto.log
Created attachment 882338 [details] 6-gcc_full.log
Created attachment 882339 [details] emerge_info.log
Ok posted all log files including emerge --info
I can reproduce this issue on an LLVM profile and add more information: This build failure seem to only happen with "browser" use flag, disabling it makes obs-studio compile again. In my case, I successfully built it with media-video/obs-studio-30.0.2::gentoo USE="alsa fdk nvenc pipewire pulseaudio python ssl truetype v4l websocket -browser -decklink -jack -lua (-mpegts) -qsv -speex -test -vlc -wayland" LUA_SINGLE_TARGET="luajit" PYTHON_SINGLE_TARGET="python3_11 -python3_10 -python3_12" Perhaps masking this use flag for the moment on LLVM profile?
More info: The bug happens because when using browser use flag the file cef_binary_5060_linux_x86_64_v3.tar.xz is extracted and it has precompiled libraries and a CMake system to compile against them. The problem is that it hardcodes CMAKE_CXX_* compiler variables to gcc ones (/usr/bin/c++, /usr/bin/ar, etc). Then, when trying to build obs-studio a mixture between c++/clang++ and between libstdc++ and libc++ happens, leading to these compiler errors. With current build system, it is not possible to support LLVM profile without a) Providing another precompiled cef_binary_5060_linux_x86_64_v3.tar.xz with clang/LLVM instead b) Deleting build directory and make it build along obs-studio without any precompiled stuff I would prefer b) but it seems also a thing of upstream so I think masking the use flag for LLVM profile is a better aproach to avoid compiler errors.
Yes I also tried yesterday with the browser useflag. And it seems its the CEF Wrapper provided by OBS. I don't know if OBS will allow to make CEF wrapper being compiled since they only accept changes that not break there flatpack build system. I could try to make it work in the ebuild but I dont know if that can break in the future
I looking at the build instruction is a pain to build this. It allow to create a ebuild that build cef and saves the binary on the system to use with the obs package. Or gentoo could start provided a distfile build for the llvm profile, but I dont know if that is a option.
It is even a more complicated because it does not even build with CLang without patching. I'd also suggest moving it to a separate package because it has its own build system and it would be a better approach than to build both projects in same ebuild
Created attachment 885756 [details] obs-studio-30.0.2.ebuild I've modified the ebuild to discard CEF binary build and build it before configure phase so it is available without problems for current build system.
Created attachment 885757 [details, diff] clang-update-deprecated-builtins.patch Patch needed for CEF to be compiled with a CLang compiler.
The build can be made only with cmake, because I was seeing this and was quite complex: https://bitbucket.org/chromiumembedded/cef/wiki/MasterBuildQuickStart
(In reply to Gonçalo Negrier Duarte from comment #23) > The build can be made only with cmake, because I was seeing this and was > quite complex: > https://bitbucket.org/chromiumembedded/cef/wiki/MasterBuildQuickStart In fact the ebuild uses cmake to build both: CEF first and OBS later
Ok I gonna try your ebuild to see if works on my machine, because I kinda need the obs browser plugin
Can confirm is working I think you can try make a PR to gentoo
Thank you for all the testing and such! I'll try to have a better look at this soon, but indeed, it would probably be best if it could be its own package, preferably with a dedicated maintainer since I don't have the time and/or energy to take up more work at this time (I'm generally not even using USE="browser" at all myself). I wonder if the clang patch could be upstreamed?
Ok I gonna give a look of I can do a separate ebuild for it and add as dependency to obs, I some times use the browser useflag.
(In reply to Chiitoo from comment #27) > Thank you for all the testing and such! > > I'll try to have a better look at this soon, but indeed, it would probably > be best if it could be its own package, preferably with a dedicated > maintainer since I don't have the time and/or energy to take up more work at > this time (I'm generally not even using USE="browser" at all myself). > > I wonder if the clang patch could be upstreamed? I wouldn't recommend to have it as a separated package because: 1) It is a static library only used (in portage) by obs 2) There are hardcoded paths in Findxxx.cmake script like looking specifically at a folder called $PATH/build so even if a separate package installs the .a library it will need to install it in $LIBDIR/xxx/build or patch the obs build system to indicate just given path (and maintain it)
Well if only obs needed is better to just use only on obs tho. David you can try do a PR and then we see what can be improved.
*just use it on obs ebuild
(In reply to David Carlos Manuelda from comment #29) > I wouldn't recommend to have it as a separated package because: > > 1) It is a static library only used (in portage) by obs > 2) There are hardcoded paths in Findxxx.cmake script like looking > specifically at a folder called $PATH/build so even if a separate package > installs the .a library it will need to install it in $LIBDIR/xxx/build or > patch the obs build system to indicate just given path (and maintain it) Well there are things like 'media-video/obs-v4l2sink' too, though that one might not actually be relevant any longer. Point being it's perhaps not an unusual things to do something like that. But yeah, I will ponder upon it in any case.
Created attachment 888334 [details] obs-studio-30.1.0.ebuild While it is being fixed I provide updated ebuild for version 30.1.0 in case someone needs it beforehand
Any progress on this? I am using LLVM/glibc profile and this happens.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=b9b76e67dd0ae654f5d09c7cf266b595875df929 commit b9b76e67dd0ae654f5d09c7cf266b595875df929 Author: Jimi Huotari <chiitoo@gentoo.org> AuthorDate: 2024-08-22 05:32:57 +0000 Commit: Jimi Huotari <chiitoo@gentoo.org> CommitDate: 2024-08-22 05:57:01 +0000 profiles/features/llvm: mask 'media-video/obs-studio[browser]' Fails to compile due to a bre-built binary. Bug: https://bugs.gentoo.org/922163 Signed-off-by: Jimi Huotari <chiitoo@gentoo.org> profiles/features/llvm/package.use.mask | 5 +++++ 1 file changed, 5 insertions(+)
Bump Any progress on this? Was trying to find out why the browser was masked and saw this issue from 10 months ago. Was hoping something was being done, but apparently there's no solution still
Note that the LLVM profiles are experimental.
