Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Building chromium 116 with musl libc failed #759

Open
ibenhassen opened this issue Oct 9, 2023 · 8 comments
Open

Building chromium 116 with musl libc failed #759

ibenhassen opened this issue Oct 9, 2023 · 8 comments

Comments

@ibenhassen
Copy link

ibenhassen commented Oct 9, 2023

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
Copy link
Collaborator

rakuco commented Oct 9, 2023

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
Copy link
Author

ibenhassen commented Oct 9, 2023

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
Copy link
Author

@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
Copy link
Collaborator

kraj commented Oct 10, 2023

@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
Copy link
Author

ibenhassen commented Oct 10, 2023

@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
Copy link
Collaborator

kraj commented Oct 10, 2023

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
Copy link
Author

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

@ibenhassen
Copy link
Author

ibenhassen commented Oct 11, 2023

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

No branches or pull requests

3 participants