[pulseaudio-discuss] webrtc: build failures on i386

Felipe Sateler fsateler at debian.org
Fri May 27 13:41:46 UTC 2016


On 27 May 2016 at 00:04, Arun Raghavan <arun at arunraghavan.net> wrote:
> Hey Felipe,
>
> On Thu, 26 May 2016, at 07:03 AM, Felipe Sateler wrote:
>> Hi,
>>
>> Turns out webrtc 0.2 does not work on most debian archs[1]. One part
>> is big-endian arches are not supported (already filed at [2]).
>
> I'll try to take a look at that shortly.
>
>> But the one that brings me here is that debian does not require i386
>> machines to have SSE, but xmmintrin.h requires that, and is
>> unconditionally used on i386. I don't know if webrtc can do runtime
>> detection to use said SSE code, (in which case the required sse flags
>> should be added to the compilation unit), or we (debian) should
>> disable SSE support in i386. It should also be possible to build a
>> sse-enabled variant and use the dynamic loader's support for
>> conditinal loading (although I'd prefer not to do that).
>>
>> What would be the best course of action?
>
> Looking at the code, they already do runtime detection, so if you build
> on a machine with SSE2 and intrinsics, you should be okay for this to
> run on any machine with or with SSE2.

Excellent. So no double building necessary :)

> Example of the code:
>
>   #if defined(WEBRTC_ARCH_X86_FAMILY)
>     if (WebRtc_GetCPUInfo(kSSE2)) {
>       WebRtcAec_InitAec_SSE2();
>     }
>   #endif
>
> Is there some reason you can't /build/ with SSE2 support on the
> compiler? Or were you suggesting that we needed to add  compiler flags
> to make this work?

My fear is that enabling SSE2 support globally for the library might
induce gcc to use SSE2 instructions in its generated code. See the
-msse section in the gcc manual[1]:

> In particular, the file containing the CPU detection code should be
> compiled without these options.

So, I think what is needed is to split sse-using functions to a
separate file and add -msse2 only to that file. However, I am not very
confident I understand this very well, so this may not be optimal
either.

[1] https://gcc.gnu.org/onlinedocs/gcc/x86-Options.html#x86-Options

-- 

Saludos,
Felipe Sateler


More information about the pulseaudio-discuss mailing list