Bug 225401 – [LibWebRTC][WPE][GTK] do not use system installed vpx headers when building webrtc

• Status: RESOLVED
• Resolution: FIXED
• Component: Platform

[Yury Semikhatsky]

After https://commits.webkit.org/r276491 WPE build fails on Ubuntu 18.04 with the following error:


In file included from ../../../Source/ThirdParty/libwebrtc/Source/webrtc/modules/video_coding/codecs/vp9/vp9.cc:16:0:
../../../Source/ThirdParty/libwebrtc/Source/webrtc/modules/video_coding/codecs/vp9/vp9_impl.h:134:3: error: ‘vpx_svc_frame_drop_t’ does not name a type; did you mean ‘vpx_enc_frame_flags_t’?
   vpx_svc_frame_drop_t svc_drop_frame_;
   ^~~~~~~~~~~~~~~~~~~~
   vpx_enc_frame_flags_t


This is because #include "vpx/vp8cx.h" in vp9_impl.h gets the header from /usr/include/vpx/vp8cx.h (provided by libvpx-dev)
instead of WebKit/Source/ThirdParty/libwebrtc/Source/third_party/libvpx/source/libvpx/vpx/vp8cx.h. vp8cx.h on Ubuntu 18.04 [1]
is rather old and doesn't define vpx_svc_frame_drop_t structure so the build fails.



[1] https://packages.ubuntu.com/source/bionic/libvpx

[Yury Semikhatsky]

Created attachment 427787 [details]
Patch

[Yury Semikhatsky]

Created attachment 427788 [details]
Patch

[Philippe Normand]

Comment on attachment 427788 [details]
Patch

Thanks Yury! Sorry for the trouble :)

[EWS]

Committed r277036 (237349@main): <https://commits.webkit.org/237349@main>

All reviewed patches have been landed. Closing bug and clearing flags on attachment 427788 [details].

[Radar WebKit Bug Importer]

<rdar://problem/77572149>

[Philippe Normand]

For the record, this patch is actually wrong :( It might have fixed your build, but if you were running webrtc tests you would realise they're broken.

The WPE/GTK ports rely on external libvpx, so we cannot pull in the bundled libvpx headers without making sure the external libvpx is ABI compatible with the version bundled in libwebrtc.

See also https://bugs.webkit.org/show_bug.cgi?id=227172

I'm updating the Flatpak SDK to libvpx 1.10 and will from now on keep the version check of libvpx in cmake synchronized with the bundled version, that means WebKit builds enabling libwebrtc while the host has libvpx < 1.10, will fail during CMake configure step.

[Yury Semikhatsky]

(In reply to Philippe Normand from comment #6)
> The WPE/GTK ports rely on external libvpx, so we cannot pull in the bundled
> libvpx headers without making sure the external libvpx is ABI compatible
> with the version bundled in libwebrtc.

I see, this makes sense. I believe proper fix for jhbuild would be to pull corresponding version of libvpx sources.


> I'm updating the Flatpak SDK to libvpx 1.10 and will from now on keep the
> version check of libvpx in cmake synchronized with the bundled version, that
> means WebKit builds enabling libwebrtc while the host has libvpx < 1.10,
> will fail during CMake configure step.

Isn't this version distribution-specific? On Ubuntu 20.04 it is shipped as libvpx6 with current version being 1.8.2, will >=1.10 requirement break it? In any case, thanks for heads-up!

[Philippe Normand]

(In reply to Yury Semikhatsky from comment #7)
> (In reply to Philippe Normand from comment #6)
> > The WPE/GTK ports rely on external libvpx, so we cannot pull in the bundled
> > libvpx headers without making sure the external libvpx is ABI compatible
> > with the version bundled in libwebrtc.
> 
> I see, this makes sense. I believe proper fix for jhbuild would be to pull
> corresponding version of libvpx sources.
> 

Yes.

> 
> > I'm updating the Flatpak SDK to libvpx 1.10 and will from now on keep the
> > version check of libvpx in cmake synchronized with the bundled version, that
> > means WebKit builds enabling libwebrtc while the host has libvpx < 1.10,
> > will fail during CMake configure step.
> 
> Isn't this version distribution-specific? On Ubuntu 20.04 it is shipped as
> libvpx6 with current version being 1.8.2, will >=1.10 requirement break it?
> In any case, thanks for heads-up!

Maybe 1.8.2 is ABI compatible with some previous versions.