[Buildroot] [RFC PATCH v2 14/30] package/libcef: New package

Michael Drake michael.drake at codethink.co.uk
Thu Nov 21 11:59:01 UTC 2019


Hi Arnout,

Thank you for all the feedback!

We've addressed most of your comments in v3 of the RFC.

For the rest, I'll respond inline below.


On 20/10/2019 00:55, Arnout Vandecappelle wrote:
> On 17/10/2019 17:29, Michael Drake wrote:

>> +
>> +LIBCEF_LICENSE = GPL-2.0 or LGPL-3.0 or GPL-3.0 or GPL-3.0 with exception
> 
>  I haven't checked, but I'd be surprised if a packages with such a *load of
> bundled dependencies only has those four licenses...

True, we took our inspiration from the qt5webengine package, which is
also based on the Chromium source tree, and already in Buildroot:

https://github.com/buildroot/buildroot/blob/master/package/qt5/qt5webengine/qt5webengine.mk#L20

Perhaps we need to generate a full list from the files listed in the
package/libcef/libcef.license-files.inc file?

>> +ifeq ($(BR2_TOOLCHAIN_EXTERNAL),y)
>> +# Tell clang where the external toolchain is and to use it
>> +LIBCEF_TARGET_CFLAGS += --gcc-toolchain=$(TOOLCHAIN_EXTERNAL_INSTALL_DIR) \
> 
>  Can you explain why this --gcc-toolchain is needed? It can find it in $PATH, no?

Without it, when building using an external toolchain, we see
linking errors:

[2852/24834] LINK ./chrome_sandbox
FAILED: chrome_sandbox
clang++ -Wl,--fatal-warnings -Wl,--build-id=sha1 -fPIC
-Wl,-z,noexecstack -Wl,-z,relro -Wl,-z,now -Wl,-z,defs -Wl,--as-needed
-fuse-ld=lld -Wl,--icf=all -Wl,--color-diagnostics -flto=thin
-Wl,--thinlto-jobs=8 -Wl,--thinlto-cache-dir=thinlto-cache
-Wl,--thinlto-cache-policy,cache_size=10\%:cache_size_bytes=10g:cache_size_files=100000
-Wl,--lto-O0 -fwhole-program-vtables -m64 -Wl,-O2 -Wl,--gc-sections
-Wl,--gdb-index -rdynamic -nostdlib++
--sysroot=../../../../host/x86_64-buildroot-linux-gnu/sysroot
-fsanitize=cfi-vcall -fsanitize=cfi-icall -pie -Wl,--disable-new-dtags
-Wno-unknown-warning-option --target=x86_64-tesla-linux-gnu -o
"./chrome_sandbox" -Wl,--start-group @"./chrome_sandbox.rsp"
-Wl,--end-group  -ldl -lpthread -lrt
ld.lld: error: cannot open crtbeginS.o: No such file or directory
ld.lld: error: unable to find library -lgcc
ld.lld: error: unable to find library -lgcc
ld.lld: error: cannot open crtendS.o: No such file or directory
clang-9: error: linker command failed with exit code 1 (use -v to see
invocation)

>> +define LIBCEF_EXTRACT_CMDS
>> +	# Extract Chromium source code
>> +	tar -C $(@D) \
>> +		--strip-components=1 \
>> +		-xf $(LIBCEF_DL_DIR)/chromium-$(LIBCEF_CHROMIUM_VERSION).tar.xz
>> +
>> +	# Extract CEF to cef dir inside Chromium source code
>> +	mkdir $(@D)/cef
>> +	tar -C $(@D)/cef \
>> +		--strip-components=1 \
>> +		-xf $(LIBCEF_DL_DIR)/libcef-$(LIBCEF_VERSION).tar.gz
> 
>  So Buildroot first extracts (with --strip-components=0) in the top directory,
> then chromium gets extracted next to it, and then we extract libcef again in a
> subdirectory... That sounds a bit like a roundabout approach, no?

Actually, I think defining LIBCEF_EXTRACT_CMDS replaces the default
Buildroot extraction commands.  We simply extract the Chromium source
into the top level libcef output directory, and then extract the
CEF source into a cef/ directory within that.  This is the source
tree layout that the CEF project requires.

Cheers,

Michael


More information about the buildroot mailing list