obs-studio
obs-studio copied to clipboard
Fail to build for powerpc (VSX instruction are for at least powerpc7)
Operating System Info
Other
Other OS
Linux ppc64
OBS Studio Version
29.0.0
OBS Studio Version (Other)
29.0.1
OBS Studio Log URL
Nothing
OBS Studio Crash Log URL
No response
Expected Behavior
Should build fine as in 29.0.0
Current Behavior
Fail to build with
/usr/include/simde/x86/sse2.h:2648:7: error: ‘__builtin_vsx_float2_v2df’ requires the ‘-mcpu=power8’ and ‘-mvsx’ options
2648 | r_.altivec_f32 = vec_float2(a_.altivec_f64, vec_splats(0.0));
| ^~
/usr/include/simde/x86/sse2.h:2648:7: note: overloaded builtin ‘__builtin_vec_float2’ is implemented by builtin ‘__builtin_vsx_float2_v2df’
[2/460] Building C object libobs-opengl/CMakeFiles/libobs-opengl.dir/gl-shaderparser.c.o
Steps to Reproduce
- ./cmake
- make
Anything else we should know?
No response
This looks like an issue in the simde project that we use for arm/non-x86. However we dont support ppc/arm on linux, users of these platforms would need to see if simde has support and potentially update it/file bugs there and send any fixes our way.
If you were able to build with 29.0.0, then a bisect (or even better, a patch/PR) would be appreciated, since I'm pretty sure none of the regular contributors have any PPC hardware.
This commit 7da9a2f0d33677c1921c1ee3e76ab4ee3701e712 introduce the -mvsx GCC option @pkubaj We need your advice
That commit dates back to OBS Studio 26, so that cannot have caused breakage between OBS Studio 29.0.0 and 29.0.1.
Should build fine as in 29.0.0
This indicates that you were able to build OBS Studio 29.0.0.
Frankly I don't know, CPU detection seems to have changed between 29.0.0 and 29.0.1 for powerpc Close this bug if you want I patch my Debian package for that.
We (in FreeBSD) also started seeing similar simde-related errors, it's probably because simde wasn't used before for SSE translation. I will test whether reverting my patch fixes the build.
We (in FreeBSD) also started seeing similar simde-related errors, it's probably because simde wasn't used before for SSE translation. I will test whether reverting my patch fixes the build.
If this is BSD-specific, and if 29.0.0 builds fine, then I would recommend checking the diff from 29.0.0 to 29.0.1 to see if one of the commits that loosened ifdef/define checks to include BSDs exposed this.
Today I did a 29.0.0 rebuild and I see the same problem with 29.0.1 Also under Debian 29.0.0 powerpcel64 build fine https://buildd.debian.org/status/package.php?p=obs-studio&suite=sid
I was mistaken, the simde-related issue was about obs-waveform:
In file included from /wrkdirs/usr/ports/multimedia/obs-waveform/work/waveform-1.5.0/src/source.cpp:20:
In file included from /wrkdirs/usr/ports/multimedia/obs-waveform/work/waveform-1.5.0/src/source.hpp:26:
In file included from /wrkdirs/usr/ports/multimedia/obs-waveform/work/waveform-1.5.0/src/membuf.hpp:28:
In file included from /wrkdirs/usr/ports/multimedia/obs-waveform/work/waveform-1.5.0/src/aligned_mem.hpp:20:
In file included from /usr/lib/clang/13.0.0/include/emmintrin.h:13:
In file included from /usr/lib/clang/13.0.0/include/xmmintrin.h:13:
/usr/lib/clang/13.0.0/include/mmintrin.h:159:19: error: use of undeclared identifier '__builtin_ia32_packssdw'
return (__m64)__builtin_ia32_packssdw((__v2si)__m1, (__v2si)__m2);
^
/usr/lib/clang/13.0.0/include/mmintrin.h:187:1: error: redefinition of 'simde_mm_packs_pu16'
_mm_packs_pu16(__m64 __m1, __m64 __m2)
^
/usr/local/include/obs/util/simde/x86/mmx.h:1069:30: note: expanded from macro '_mm_packs_pu16'
#define _mm_packs_pu16(a, b) simde_mm_packs_pu16(a, b)
^
/usr/local/include/obs/util/simde/x86/mmx.h:1008:12: note: previous definition is here
simde__m64 simde_mm_packs_pu16(simde__m64 a, simde__m64 b)
^
obs-studio itself builds fine both without my patch and with it (on powerpc64), so I guess it's ok to revert it.
I guess it's ok to revert it
Please open a Pull Request reverting the patch in question if that is indeed the solution.
Today I did a 29.0.0 rebuild and I see the same problem with 29.0.1 Also under Debian 29.0.0 powerpcel64 build fine https://buildd.debian.org/status/package.php?p=obs-studio&suite=sid
I keep seeing comments that 29.0.0 has the same problem as 29.0.1, but also that 29.0.0 builds fine. I'd like some clarification on what version of OBS fails to build in what configuration, and what the last known buildable version of OBS was on that configuration.
Please provide "yes" or "no" answers to 1 and 2.
- Does OBS Studio 29.0.0 build on Debian "powerpcel64"?
- Does OBS Studio 29.0.1 build on Debian "powerpcel64"?
If yes to both, please explain clearly in what configuration OBS does not build and please specify the OBS version. Please also confirm the last known version of OBS to build on that configuration.
The URL provided lists the architecture in question as "ppc64el", which does not match any possible combination of the regex provided in https://github.com/obsproject/obs-studio/commit/7da9a2f0d33677c1921c1ee3e76ab4ee3701e712. We will currently match any of the following:
- powerpc64
- powerpc64le
- ppc64
- ppc64le
Note that we will not match "ppc64el".
I am not familiar with the various ppc64 architectures, so I do not know what is "expected" here or what the correct fix would be.
Today I did a 29.0.0 rebuild and I see the same problem with 29.0.1 Also under Debian 29.0.0 powerpcel64 build fine https://buildd.debian.org/status/package.php?p=obs-studio&suite=sid
I keep seeing comments that 29.0.0 has the same problem as 29.0.1, but also that 29.0.0 builds fine. I'd like some clarification on what version of OBS fails to build in what configuration, and what the last known buildable version of OBS was on that configuration.
Please provide "yes" or "no" answers to 1 and 2.
1. Does OBS Studio 29.0.0 build on Debian "powerpcel64"?
YES
2. Does OBS Studio 29.0.1 build on Debian "powerpcel64"?
Not yet packaged
Here we are talking about powerpc architecture under Linux not mips64el or ppc64
We only really officially support x86 and ARM right now.
How did you even get into a situation where you're trying to build OBS on powerpc architecture?
In Debian we still have powerpc packages in ports section https://www.debian.org/ports/powerpc/
PPC support in OBS was added for POWER9 workstations (i.e. ppc64le
), it's not expected to run or even compile on older PPC architectures, especially not the long-obsolete 32 bit ones.
Then close this bug.
Today I did a 29.0.0 rebuild and I see the same problem with 29.0.1 Also under Debian 29.0.0 powerpcel64 build fine https://buildd.debian.org/status/package.php?p=obs-studio&suite=sid
I keep seeing comments that 29.0.0 has the same problem as 29.0.1, but also that 29.0.0 builds fine. I'd like some clarification on what version of OBS fails to build in what configuration, and what the last known buildable version of OBS was on that configuration.
Please provide "yes" or "no" answers to 1 and 2.
- Does OBS Studio 29.0.0 build on Debian "powerpcel64"?
- Does OBS Studio 29.0.1 build on Debian "powerpcel64"?
If yes to both, please explain clearly in what configuration OBS does not build and please specify the OBS version. Please also confirm the last known version of OBS to build on that configuration.
The URL provided lists the architecture in question as "ppc64el", which does not match any possible combination of the regex provided in 7da9a2f. We will currently match any of the following:
- powerpc64
- powerpc64le
- ppc64
- ppc64le
Note that we will not match "ppc64el".
I am not familiar with the various ppc64 architectures, so I do not know what is "expected" here or what the correct fix would be.
@RytoEX Well, the commit is obviously wrong, since it forces VSX instructions unconditionally.
PPC support in OBS was added for POWER9 workstations (i.e.
ppc64le
), it's not expected to run or even compile on older PPC architectures, especially not the long-obsolete 32 bit ones.
@derrod Then there should be a check to use the flag on ppc64* specifically.
For a note, POWER9 are bi-endian, not little-endian.
@derrod Then there should be a check to use the flag on ppc64* specifically.
Why would there need to be a check? Other ppc architectures aren't supported so the build should fail.
Edit: With the latest update to our build system PPC is actually no longer supported. A PR to restore support for POWER9 and later may be acceptable if it's simple, though I cannot speak on behalf of our Linux and build-system maintainers.
@derrod If something is known not to work, then it should be explicitly checked for and a message displayed to the user. (For example, if the code is written without any awareness of BE platforms existing, and cannot work on BE.) If you do not know if something works or not, there is no need to break it by introducing wrong code. Also, wrong code is just wrong, regardless of whether it happens to affect any users at present moment.