New issue
Advanced search Search tips

Issue 917880 link

Starred by 2 users

Issue metadata

Status: Unconfirmed
Owner: ----
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 3
Type: Bug



Sign in to add a comment

chromium-71.0.3578.98 fails on linking libheap_profiling.a

Reported by m...@pc-networking-services.com, Dec 26

Issue description

chromium-71.0.3578.98

I am using a distribution called linuxfromscratch that like slackware, builds the whole operating system from scratch using stable tar archives.

This version goes all the way through the build process to the end and fails at the linking stage:

[32819/32819] LINK ./chrome
FAILED: chrome 
python "../../build/toolchain/gcc_link_wrapper.py" --output="./chrome" -- g++ -pie -Wl,--version-script=../../build/linux/chrome.map -fPIC -Wl,-z,noexecstack -Wl,-z,now -Wl,-z,relro -Wl,-z,defs -Wl,--as-needed -m64 -Wl,-O2 -Wl,--gc-sections -rdynamic -nodefaultlibs -Wl,-rpath-link=. -Wl,--disable-new-dtags -o "./chrome" -Wl,--start-group @"./chrome.rsp"  -Wl,--end-group   -lc -lgcc_s -lm -lrt -ldl -lpthread -lX11 -lX11-xcb -lxcb -lXcomposite -lXcursor -lXdamage -lXext -lXfixes -lXi -lXrender -lXtst -lgmodule-2.0 -lgobject-2.0 -lgthread-2.0 -lglib-2.0 -licui18n -licuuc -licudata -lnss3 -lnssutil3 -lsmime3 -lsoftokn3 -lplds4 -lplc4 -lnspr4 -lcups -lz -lcrypt -lxml2 -lexpat -ldbus-1 -latomic -levent -lXss -lwebpdemux -lwebpmux -lwebp -lfreetype -ljpeg -luuid -lharfbuzz -lXrandr -lresolv -lgio-2.0 -lavcodec -lavformat -lavutil -lopus -lasound -lpulse -lpangocairo-1.0 -lpango-1.0 -lcairo -lpci -latk-1.0 -latk-bridge-2.0 -latspi -lFLAC -lgtk-3 -lgdk-3 -lcairo-gobject -lgdk_pixbuf-2.0 -lxslt 
/usr/bin/ld: obj/components/services/heap_profiling/libheap_profiling.a: error adding symbols: malformed archive
collect2: error: ld returned 1 exit status
ninja: build stopped: subcommand failed.

I have no idea if this is another thin_archive error as was the case with one of the earlier versions in the stable-70 branch or exactly how to fix this.

I have used both google and bing to search the web for some clue as to how to fix this with zero relevant results.  I also tried the last stable version and got the same results.  As this takes so long to compile from source, it should work the first time with no patches required, but it seems that googles definition of stable is different to most.  The correct usage of the word "stable" is when the code cleanly compiles and you have a binary that is capable of being used to surf the net.

Regards,

Christopher.
 
Well I did a recompile with thin_archive disabled in both build/config/BUILDCONFIG.gn and media/cast/BUILD.gn and after setting ulimit -n 2048
the final linking was successful.

I am not sure which library is affected by not disabling thin_archive, but there is most certainly an issue.

It would be nice to know if there is an option, like there was with pdfium to set it as a complete static library, as disabling thin_archive does seem to significantly increase the build time.

I hope one of the developers actually takes the time to look at this, even though others may well not bother opening a bug report here, as they are most likely to do so at their distro end than here.

Regards,

Christopher.
Cc: phanindra.mandapaka@chromium.org
Components: Build
Labels: Needs-Triage-M71 Triaged-ET TE-NeedsTriageHelp
Thanks for filing the issue...

As per comment#0, the issue seems to be related to Build, which is out of scope for TE. Hence adding TE-NeedsTriageHelp label and requesting the respective team to have a look into this and help in further triaging of issue.

Sign in to add a comment