yocto-check-layer gives compliance error for meta-chromium layer

[nrpt-m]

As explained in: https://github.com/OSSystems/meta-browser/commit/2f5fe79935e1f5350f9e487625343a8f27b165d3 Chromium doesn't allow building with system libwayland anymore, and needs (a static version of) libffi to build its own libwayland.

Chromium-ozone-wayland build is looking for libffipic.a (static library) at linker stage therefore, a libffi%.bbappend in the meta-chromium layer was added. Yocto prefers to use shared libraries while building and preferred solution for patching deployed software.

//Also copy the PIC version of libffi.a to the sysroot, as Chromium needs it. // This is the same approach that Debian takes, which Chromium uses for its // sysroot: https://sources.debian.org/src/libffi/3.4.4-1/debian/rules/#L103 do_install:append() { install -m 0644 ${B}/.libs/libffi_convenience.a ${D}/${libdir}/libffi_pic.a }

This above command in libffi_%.bbappend causes yocto-check-layer compliance errors. If we move this command to main libffi recipe then, yocto-check-layer errors goes away. As Yocto prefers to use shared library and to resolve the yocto-check-layer compliance errors, we need to fix the build of chromium-ozone-wayand to not require libffi_pic.a ( a static library ).

Upstream References: https://chromium.googlesource.com/chromium/src/+/lkgr/build/config/linux/libffi/BUILD.gn https://chromium.googlesource.com/chromium/src/+/188513754c7ff05e7775e6cb2621ee006ebdbf6c

Can we try the below solution to fix the build of chromium-ozone-wayand to not require libffi_pic.a ( a static library ) : Source file: chromium-112.0.5615.165/build/config/linux/libffi/BUILD.gn In BUILD.gn file, make the variable use_system_libffi always "True" so that, build will always look/use the shared libffi library instead of static libffi_pic.a library and apply this as a patch to check if chromium builds fine with the shared libffi library itself.

[rwmacleod]

@nrpt-m Yes, I think this makes sense since the original issue that required libffi_pic.a was version skew of libffi.so and the Yocto environment should, by design, avoid that. If @MaxIhlenfeldt agrees, @nrpt-m will make the change and spend the time to test that and send a patch.

If we do need libffi_pic.a for some reason, then we'll have to move the change to the libffi recipe in oe-core, for all branches around the same time ideally, and then change meta-browser once that's merged. That'll be "fun" !

[MaxIhlenfeldt]

SGTM!

[rakuco]

In BUILD.gn file, make the variable use_system_libffi always "True" so that, build will always look/use the shared libffi library instead of static libffi_pic.a library and apply this as a patch to check if chromium builds fine with the shared libffi library itself.

Note that you don't need to patch BUILD.gn, this is just a matter of passing use_system_libffi=true to GN_ARGS. Upstream's rationale according to the comment in libffi's BUILD.gn is that it's easier to control the whole environment in ChromeOS and make sure there are no mismatches between libffi versions. I believe this is true with OE/Yocto as well (i.e. I expect any update or change to the libffi recipe to cause the Chromium recipe(s) to be rebuilt as well).

[nrpt-m]

use_system_libffi=true

@rakuco , will check and let you know if that works for me.

[nrpt-m]

@rakuco , @MaxIhlenfeldt , Have added "use_system_libffi=true" to GNARGS in chromium-ozone-wayland recipe and also removed the libffi%.bbappend. With these above changes now, chromium-ozone-wayland is using " libffi.so" (shared library) instead of libffi_pic.a (static library) and it's building fine.

Have created PR with above changes at https://github.com/OSSystems/meta-browser/pull/715 Chromium-ozone-wayland is building fine with these above changes but we haven't tested it in runtime so, could you test it or please let me know the steps to test it in runtime.