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.

Sign up for GitHub

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

Jump to bottom

Unable to Link Chrome 70 #194

Closed
mdavis777 opened this issue Nov 20, 2018 · 24 comments · Fixed by #286
Closed

Unable to Link Chrome 70 #194

mdavis777 opened this issue Nov 20, 2018 · 24 comments · Fixed by #286

Comments

@mdavis777
Copy link
Contributor

Every time I try to build Chromium 70 I get the following linker error.

| python "../../build/toolchain/gcc_link_wrapper.py" --output="./chrome" -- x86_64-poky-linux-g++ -m64 -march=corei7 -mtune=corei7 -mfpmath=sse -msse4.2 --sysroot=/build/mdavis/test/tmp/work/corei7-64-poky-linux/chromium-x11/70.0.3538.102-r0/recipe-sysroot -pie -Wl,--version-script=../../build/linux/chrome.map -Wl,--fatal-warnings -Wl,--build-id=sha1 -fPIC -Wl,-z,noexecstack -Wl,-z,now -Wl,-z,relro -Wl,-z,defs -Wl,--as-needed -m64 -Wl,-O2 -Wl,--gc-sections -rdynamic -Wl,-rpath-link=. -Wl,--disable-new-dtags -Wl,-O1 -Wl,--hash-style=gnu -Wl,--as-needed -o "./chrome" -Wl,--start-group @"./chrome.rsp" -Wl,--end-group -latomic -ldl -lpthread -lrt -lX11 -lX11-xcb -lxcb -lXcomposite -lXcursor -lXdamage -lXext -lXfixes -lXi -lXrender -lXtst -lgmodule-2.0 -lgobject-2.0 -lgthread-2.0 -lglib-2.0 -lsmime3 -lnss3 -lsoftokn3 -lnssutil3 -lplds4 -lplc4 -lnspr4 -lxml2 -lexpat -ldbus-1 -lXss -lwebpdemux -lwebpmux -lwebp -lfreetype -ljpeg -luuid -lXrandr -lresolv -lgio-2.0 -lm -lasound -lz -lpangocairo-1.0 -lpango-1.0 -lcairo -lpci -latk-1.0 -latk-bridge-2.0 -lFLAC -lgtk-3 -lgdk-3 -lcairo-gobject -lgdk_pixbuf-2.0 -lxslt
| obj/third_party/pdfium/third_party/libfx_agg.a: error adding symbols: Malformed archive

This is with Sumo GCC 7 intel-corei7-64 or core2-32 on a Fedora 26 64bit host.

Chromium 69 was building fine on the same system.
@mdavis777
Copy link
Contributor Author

Trying with clang now to see if is the same

@kraj
Copy link
Collaborator

kraj commented Nov 20, 2018

I am interested to see your results with clang

@mdavis777
Copy link
Contributor Author

Just finished up clang passed fine.

@kraj
Copy link
Collaborator

kraj commented Nov 20, 2018

OK while you are here, can you see if this works as well as your normal testing worked when built with gcc

@mdavis777
Copy link
Contributor Author

I am confused on the "this" you are referring too. If you are talking about testing the chrome from the clang build then I have an image building but it will take a bit of time.
I can say that GCC 8 with Thud is getting the same linker error on my system.

@kraj
Copy link
Collaborator

kraj commented Nov 20, 2018

yes here
this = "build with clang"

@mdavis777
Copy link
Contributor Author

My image failed on an unrelated error ( a different layer not ready for thud). I have an image of sumo + clang (for chromium only) building. Chromium was able to build with clang so I expect it will run property.

@kraj
Copy link
Collaborator

kraj commented Nov 20, 2018

OK. I am interested to know if someone switched to use clang in OE to do day to day chromium based images then what differences do they see, building-wise or runtime-wise.

@mdavis777
Copy link
Contributor Author

Ahhh I am not even close to doing that. I just use clang for some static analysis functions so I already had the layer to try and build chromium with. I didn't enable it as my global default compiler.
I did notice the build time for chromium was reduced over what it tends to be for GCC.

@kraj
Copy link
Collaborator

kraj commented Nov 20, 2018

Ahhh I am not even close to doing that. I just use clang for some static analysis functions so I already had the layer to try and build chromium with. I didn't enable it as my global default compiler.
I did notice the build time for chromium was reduced over what it tends to be for GCC.

keep going ...

@rakuco
Copy link
Collaborator

rakuco commented Nov 20, 2018

| obj/third_party/pdfium/third_party/libfx_agg.a: error adding symbols: Malformed archive

In my testings, this is actually a "too many open files" error underneath. Running ulimit -n 4096 before running bitbake made the problem go away for me.

@mdavis777
Copy link
Contributor Author

Yep I just ran it with an increased ulimit and it pass fine.

Thanks!

@kraj
Copy link
Collaborator

kraj commented Nov 20, 2018

| obj/third_party/pdfium/third_party/libfx_agg.a: error adding symbols: Malformed archive

In my testings, this is actually a "too many open files" error underneath. Running ulimit -n 4096 before running bitbake made the problem go away for me.

pretty hacky.. where is -n documented

@mdavis777
Copy link
Contributor Author

It is in the man pages for ulimit. I think at this point it is an issue of the host system. Something that needs to be documented, but not something that can be fixed inside the layer.
At most maybe a check for too small a value and a bbwarn being output to maybe raise it.

@rakuco
Copy link
Collaborator

rakuco commented Nov 21, 2018

pretty hacky.. where is -n documented

I thought it was part of POSIX, but apparently it's the builtin version implemented by most shells that offer this option. In any case, I don't see how it's that hacky, AFAICS it's just a matter of having too many file descriptors open at the same time, and any suggestions on how to do that in a better way are welcome.

@msisov msisov mentioned this issue Feb 6, 2019
Merged
@Yann-le-Chevoir Yann-le-Chevoir mentioned this issue Mar 19, 2019
Closed
@msisov msisov mentioned this issue Apr 2, 2019
Closed
@rakuco rakuco mentioned this issue Apr 5, 2019
Closed
@denis-shienkov
Copy link

I got same error on my Yocto 'thud' layer but with the chromium-x11 v75:

| python "../../build/toolchain/gcc_link_wrapper.py" --output="./chrome" -- arm-poky-linux-gnueabi-g++ -march=armv7-a -mfpu=neon -mfloat-abi=hard -mcpu=cortex-a9 -fstack-protector-strong -D_FORTIFY_SOURCE=2 -Wformat -Wformat-security -Werror=format-security --sysroot=/mnt/data/Yocto-miatech/yocto-miatech/build-apalis-imx6/tmp/work/cortexa9t2hf-neon-mx6qdl-poky-linux-gnueabi/chromium-x11/75.0.3770.80-r0/recipe-sysroot -Wl,--version-script=../../build/linux/chrome.map -Wl,--fatal-warnings -Wl,--build-id=sha1 -fPIC -Wl,-z,noexecstack -Wl,-z,relro -Wl,-z,now -Wl,-z,defs -Wl,--as-needed -Wl,-O2 -Wl,--gc-sections -rdynamic -pie -Wl,--disable-new-dtags -Wl,-O1 -Wl,--hash-style=gnu -Wl,--as-needed -fstack-protector-strong -Wl,-z,relro,-z,now -o "./chrome" -Wl,--start-group @"./chrome.rsp" -Wl,--end-group -latomic -ldl -lpthread -lrt -lX11 -lX11-xcb -lxcb -lXcomposite -lXcursor -lXdamage -lXext -lXfixes -lXi -lXrender -lXtst -lgmodule-2.0 -lgobject-2.0 -lgthread-2.0 -lglib-2.0 -lsmime3 -lnss3 -lsoftokn3 -lnssutil3 -lplds4 -lplc4 -lnspr4 -lxml2 -ldbus-1 -lXss -lwebpdemux -lwebpmux -lwebp -lfreetype -ljpeg -lexpat -luuid -lXrandr -lresolv -lgio-2.0 -lasound -lm -lz -lpci -latk-1.0 -latk-bridge-2.0 -lpangocairo-1.0 -lpango-1.0 -lcairo -latspi -lFLAC -lgtk-3 -lgdk-3 -lcairo-gobject -lgdk_pixbuf-2.0 -lxslt
| /mnt/data/Yocto-miatech/yocto-miatech/build-apalis-imx6/tmp/work/cortexa9t2hf-neon-mx6qdl-poky-linux-gnueabi/chromium-x11/75.0.3770.80-r0/recipe-sysroot-native/usr/bin/arm-poky-linux-gnueabi/../../libexec/arm-poky-linux-gnueabi/gcc/arm-poky-linux-gnueabi/8.2.0/ld: obj/ppapi/proxy/libppapi_proxy.a: error adding symbols: malformed archive

What is a workaround?

@rakuco
Copy link
Collaborator

rakuco commented Jul 15, 2019

Did you run ulimit -n 4096 as mentioned above?

@denis-shienkov
Copy link

denis-shienkov commented Jul 15, 2019 •
edited

In my case it is unlimited:

$ ulimit
unlimited

but, I will try to set 4096..

@rakuco
Copy link
Collaborator

rakuco commented Jul 15, 2019

Note that ulimit and ulimit -n are different things. You were running the equivalent of ulimit -f according to the bash man page.

@denis-shienkov
Copy link

Ah, yes, sorry, in my case with -n it return 1024. ok, thanks, I will try with 4096

@denis-shienkov
Copy link

Yes, it does help, many thanks.

@otavio
Copy link
Member

otavio commented Jul 16, 2019

Note that ulimit and ulimit -n are different things. You were running the equivalent of ulimit -f according to the bash man page.

@rakuco we could consider adding a check on the recipe to avoid people falling into this pitfall. What do you think?

@otavio otavio reopened this Jul 16, 2019
@rakuco
Copy link
Collaborator

rakuco commented Jul 16, 2019

I agree, I just don't really know how to do that. The best option would be to get people to use gold instead, but I guess that's not very usual, right?

@otavio
Copy link
Member

otavio commented Jul 16, 2019

I'd check if on do_configure if it is not gold. Direct on code.

rakuco added a commit to rakuco/meta-browser that referenced this issue Jul 16, 2019
@rakuco
chromium: Check maximum number of open file descriptors when using ld…
96181af 
….bfd

The usual limit (i.e. the value returned by `ulimit -n`), 1024, is too low
for ld.bfd to be able to link the `chrome` binary.

Add a fatal check for the value that aborts when ld.bfd is being used and
the resource limit is too low.

Fixes OSSystems#194.

Signed-off-by: Raphael Kubo da Costa <raphael.kubo.da.costa@intel.com>
@rakuco rakuco mentioned this issue Jul 16, 2019
Merged
rakuco added a commit to rakuco/meta-browser that referenced this issue Jul 16, 2019
@rakuco
chromium: Check maximum number of open file descriptors when using ld…
b764de1 
….bfd

The usual limit (i.e. the value returned by `ulimit -n`), 1024, is too low
for ld.bfd to be able to link the `chrome` binary.

Add a fatal check for the value that aborts when ld.bfd is being used and
the resource limit is too low.

Fixes OSSystems#194.

Signed-off-by: Raphael Kubo da Costa <raphael.kubo.da.costa@intel.com>
rakuco added a commit to rakuco/meta-browser that referenced this issue Jul 16, 2019
@rakuco
chromium: Check maximum number of open file descriptors when using ld…
7e675c8 
….bfd

The usual limit (i.e. the value returned by `ulimit -n`), 1024, is too low
for ld.bfd to be able to link the `chrome` binary.

Add a fatal check for the value that aborts when ld.bfd is being used and
the resource limit is too low.

Fixes OSSystems#194.

Signed-off-by: Raphael Kubo da Costa <raphael.kubo.da.costa@intel.com>
rakuco added a commit that referenced this issue Jul 16, 2019
@rakuco
chromium: Check maximum number of open file descriptors when using ld…
2c3c891 
….bfd

The usual limit (i.e. the value returned by `ulimit -n`), 1024, is too low
for ld.bfd to be able to link the `chrome` binary.

Add a fatal check for the value that aborts when ld.bfd is being used and
the resource limit is too low.

Fixes #194.

Signed-off-by: Raphael Kubo da Costa <raphael.kubo.da.costa@intel.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

chromium: Check maximum number of open file descriptors when using ld.bfd rakuco/meta-browser
5 participants
@otavio @rakuco @kraj @denis-shienkov @mdavis777