Building chromium 116 with musl libc failed

[ibenhassen]

Hi ,

We would like to build chromium-ozone-wayland with musl libc instead of glibc but we got an issue in the last step related to mksnapshot cross build:

`[58810/61094] "python3" "../../build/toolchain/gcc_link_wrapper.py" --output="./mksnapshot" -- arm-hdl-linux-musleabi-clang++ -target arm-hdl-linux-musleabi -mfpu=neon -mfloat-abi=hard -mcpu=cortex-a7 -mlittle-endian -Qunused-arguments --sysroot=/home/ibenhassen/projects/EG4/eg4-chromium-musl/build/tmp-musl/work/cortexa7t2hf-neon-mx7d-hdl-linux-musleabi/chromium-ozone-wayland/116.0.5845.179-r0-hdl1/recipe-sysroot -pie -fuse-ld=lld -Wl,--fatal-warnings -Wl,--build-id=sha1 -fPIC -Wl,-z,noexecstack -Wl,-z,relro -Wl,-z,now -Wl,--icf=all -Wl,--color-diagnostics -Wl,-mllvm,-instcombine-lower-dbg-declare=0 -flto=thin -Wl,--thinlto-jobs=96 -Wl,--thinlto-cache-dir=thinlto-cache -Wl,--thinlto-cache-policy=cache_size=10%:cache_size_bytes=40g:cache_size_files=100000 -Wl,-mllvm,-import-instr-limit=30 -fwhole-program-vtables -march=armv7-a -Wl,--undefined-version -Wl,--no-call-graph-profile-sort -rdynamic -Wl,-z,defs -Wl,--as-needed -Wl,--lto-O0 -pie -Wl,--disable-new-dtags -Wl,-O2 -Wl,--gc-sections -Wl,-O1 -Wl,--hash-style=gnu -Wl,--as-needed -stdlib=libc++ -lexecinfo -o "./mksnapshot" -Wl,--start-group @"./mksnapshot.rsp" -Wl,--end-group -latomic -ldl -lpthread -lrt

Currently 1 running tasks (2027 of 2027) 99% |######################################################################################################################################################################################################################################## |
0: chromium-ozone-wayland-116.0.5845.179-r0-hdl1 do_compile (pid 3584303) 96%`

Any help please or idea to fix that?

Thanks and best regards

[rakuco]

The actual error occurred earlier than that, you can probably find it if you grep for "error: " in the logs.

With that said, musl support usually depends on @kraj finding time to update the patches we carry (we do not update them automatically with the rest of the version updates). This probably hasn't happened for M116 yet.

[ibenhassen]

No error has been found after doing grep for error: .

For this raison , I thought it is strange that the build crashes at 96% . I've built ozone-wayland with glibc and it built fine.

which musl version needs to used please? and maybe I can try with M112 ?

[ibenhassen]

@kraj I got this log with M112:
[54911/57120] python3 "../../build/toolchain/gcc_link_wrapper.py" --output="./chromedriver.unstripped" -- arm-hdl-linux-musleabi-clang++ -target arm-hdl-linux-musleabi -mfpu=neon -mfloat-abi=hard -mcpu=cortex-a7 -rtlib=compiler-rt --unwindlib=libgcc -stdlib=libc++ -mlittle-endian -Qunused-arguments --sysroot=/home/ibenhassen/projects/EG4/eg4-musl/build-musl-/tmp-musl/work/cortexa7t2hf-neon-mx7d-hdl-linux-musleabi/chromium-ozone-wayland/112.0.5615.165-r0-hdl1/recipe-sysroot -fuse-ld=lld -Wl,--fatal-warnings -Wl,--build-id=sha1 -fPIC -Wl,-z,noexecstack -Wl,-z,relro -Wl,-z,now -Wl,--icf=all -Wl,--color-diagnostics -Wl,-mllvm,-instcombine-lower-dbg-declare=0 -flto=thin -Wl,--thinlto-jobs=96 -Wl,--thinlto-cache-dir=thinlto-cache -Wl,--thinlto-cache-policy=cache_size=10\%:cache_size_bytes=40g:cache_size_files=100000 -Wl,-mllvm,-import-instr-limit=30 -fwhole-program-vtables -march=armv7-a -Wl,--undefined-version -Wl,--no-call-graph-profile-sort -Wl,-O2 -Wl,--gc-sections -rdynamic -Wl,-z,defs -Wl,--as-needed -Wl,--lto-O0 -pie -Wl,--disable-new-dtags -Wl,-O1 -Wl,--hash-style=gnu -Wl,--as-needed -lexecinfo -o "./chromedriver.unstripped" -Wl,--start-group @"./chromedriver.unstripped.rsp" -Wl,--end-group -latomic -ldl -lpthread -lrt -lgmodule-2.0 -lgobject-2.0 -lgthread-2.0 -lglib-2.0 -lsmime3 -lnss3 -lsoftokn3 -lnssutil3 -lplds4 -lplc4 -lnspr4 -lresolv -lgio-2.0 -ljpeg -lm -lz -lexpat -luuid -ldrm -lxkbcommon -ldbus-1

the build is blocked there , could you please tell me if I missed a depends or anything else?

[kraj]

@ibenhassen I think it could be the clang-14 running into infinite loop of some sort. Does it build for glibc on dunfell for you on same host ? I usually use rolling releases which are based on master so I am not using dunfell for regular testing.

[ibenhassen]

@kraj Yes it does, and I started to build with musl in the same host with docker,
it crashes when it ran the gcc_link_wrapper for linking the mksnapshot as can see from my shared log .

How could we check if clang-14 is running into infinite loop ? and if it does , did you plan to make some changes into it?

[kraj]

I dont have a good enough information here to help you. Are you enabling lto by any change ? if so maybe disabling it could help

maybe change

GN_ARGS += 'max_jobs_per_link="${@oe.utils.parallel_make_argument(d, '%d')}"' to
GN_ARGS += 'max_jobs_per_link="10"' or some smaller value and see if that makes difference

[ibenhassen]

@kraj I will check that tomorrow and let you updated , Thank you for your help

[ibenhassen]

Hi @kraj ,

I've tried by making those changes:

`diff --git a/meta-chromium/recipes-browser/chromium/chromium-gn.inc b/meta-chromium/recipes-browser/chromium/chromium-gn.inc
index 7d076fe..9752843 100644
--- a/meta-chromium/recipes-browser/chromium/chromium-gn.inc
+++ b/meta-chromium/recipes-browser/chromium/chromium-gn.inc
@@ -191,7 +191,7 @@ GN_ARGS += 'host_pkg_config="pkg-config-native"'
GN_ARGS += "is_debug=false is_official_build=true"

Use lld linker its quicker see https://lld.llvm.org/#performance

-GN_ARGS += "use_lld=true use_gold=false"
+GN_ARGS += "use_lld=false use_gold=true"

By default, passing is_official_build=true to GN causes its symbol_level

variable to be set to "2". This means the compiler will be passed "-g2" and

@@ -301,7 +301,8 @@ GN_ARGS += ' \

This parameter is added by limit-number-of-LTO-jobs.patch with the default value of 8,

but we can use whatever user configured in PARALLEL_MAKE

-GN_ARGS += 'max_jobs_per_link="${@oe.utils.parallel_make_argument(d, '%d')}"'
+GN_ARGS += 'max_jobs_per_link=4'
+GN_ARGS += 'use_thin_lto=false'

`

Still have the same issue related to gcc_link_wrapper.py and mksnapshot linking step.