Created attachment 488564 [details] build.log [ 5%] Building C object libobs/CMakeFiles/libobs.dir/graphics/axisang.c.o /var/tmp/portage/media-video/obs-studio-19.0.2/work/obs-studio-19.0.2/libobs/graphics/graphics-magick.c:5:31: fatal error: magick/MagickCore.h: No such file or directory #include <magick/MagickCore.h> If you replace the include path in graphics-magick.c: #include <magick/MagickCore.h> with #include <MagickCore/MagickCore.h> then it compiles fine. But in their forum, the suggest to drop the path part completely: https://webcache.googleusercontent.com/search?q=cache:WusKwIuJO2QJ:https://obsproject.com/mantis/print_bug_page.php%3Fbug_id%3D966+&cd=1&hl=de&ct=clnk&gl=de So I guess, this is an upstream problem and has to be fixed in a different way.
Hrm. I should have noticed this a lot earlier... Indeed, it looks like '#include <MagickCore/MagickCore.h>' makes the build much more happy-like (while '#include <MagickCore.h>' doesn't seem to do the magick for me). I suppose we could patch it for now, but I'll probably try to poke upstream about it soon as well. Thanks for the report!
The error is still present in media-video/obs-studio-20.0.1
(In reply to Vincent-Xavier JUMEL from comment #2) > The error is still present in media-video/obs-studio-20.0.1 However, the added patch enable compilation on media-video/obs-studio-20.0.1
Created attachment 490846 [details, diff] /etc/portage/patches/media-video/obs-studio/obs-studio-20.0.1.patch
It seems there might be a bit more to this than just fixing the header path. While looking for the cause for the issue, I noticed that with <cmake-3.9 and >=imagemagick-7 this feature gets silently disabled, and the header path change doesn't help with that. In fact, the change will make the build fail if building against '=media-gfx/imagemagick-6.9.9.9' for example.
As a bit of an update, with current stable cmake (3.7.2) and stable imagemagick (6.9.9.0) things look to be OK still, but for >=imagemagick-7, a more recent (or patched) cmake is needed. This is a different issue, leading to silently ignoring the request to use imagemagick, and to using FFMPEG_AVCODEC (instead if found). With >=imagemagick-7, the header location indeed changed, which brings us to this issue. I'll probably try to push the fix I have upstream, and/or implement some kind of fixes for us soon (unless someone else gets to it first).
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=8434e38d77c3d9b82292c822164a385d9244f8fc commit 8434e38d77c3d9b82292c822164a385d9244f8fc Author: Jimi Huotari <chiitoo@gentoo.org> AuthorDate: 2017-08-31 11:46:07 +0000 Commit: Patrice Clement <monsieurp@gentoo.org> CommitDate: 2017-10-11 21:04:12 +0000 media-video/obs-studio: fix build against ImageMagick 7. Since ImageMagick 7, the headers have been under a different directory, and the build with ImageMagick support will fail when the old path is used. This commit patches in detection for the version being used, while also choosing the path accordingly. Special thanks to Hu. Upstream Pull Request: https://github.com/jp9000/obs-studio/pull/1018 Closes: https://bugs.gentoo.org/627520 Closes: https://github.com/gentoo/gentoo/pull/5642 Package-Manager: Portage-2.3.8, Repoman-2.3.3 .../files/obs-studio-ImageMagick-header-path.patch | 70 ++++++++++++++++++++++ media-video/obs-studio/obs-studio-18.0.2.ebuild | 2 + media-video/obs-studio/obs-studio-19.0.2.ebuild | 2 + media-video/obs-studio/obs-studio-20.0.1.ebuild | 2 + 4 files changed, 76 insertions(+)
