linking ../../../../lib/libQtWebKit.so.4.6.0 collect2: ld terminated with signal 11 [Segmentation fault] make: *** [../../../../lib/libQtWebKit.so.4.6.0] Error 1 if I remove --gc-sections from the Makefile linking is OK I had tried with (stable) binutils-1.18 and had the crash too. I may retest with --gc-sections removed. Before trying off-ing the linker options I had tracked pairs of .o files ending in crash. If it can help, I keep the list available. Before ld bug is resolved, what can be done for qt-webkit ? Reproducible: Always emerge --info Portage 2.2_rc54 (default/linux/powerpc/ppc32/10.0/desktop, gcc-4.4.2, glibc-2.10.1-r1, 2.6.30-gentoo-r4-l0 ppc) ================================================================= System uname: Linux-2.6.30-gentoo-r4-l0-ppc-7447A,_altivec_supported-with-gentoo-2.0.1 Timestamp of tree: Fri, 04 Dec 2009 19:00:01 +0000 distcc 3.1 powerpc-unknown-linux-gnu [disabled] ccache version 2.4 [enabled] app-shells/bash: 4.0_p35 dev-java/java-config: 2.1.9-r1 dev-lang/python: 2.5.4-r3, 2.6.4, 3.1.1-r1 dev-python/pycrypto: 2.1.0_beta1 dev-util/ccache: 2.4-r8 dev-util/cmake: 2.8.0 sys-apps/baselayout: 2.0.1 sys-apps/openrc: 0.5.3 sys-apps/sandbox: 2.2 sys-devel/autoconf: 2.13, 2.64 sys-devel/automake: 1.6.3, 1.9.6-r2, 1.10.2, 1.11 sys-devel/binutils: 2.20 sys-devel/gcc-config: 1.4.1 sys-devel/libtool: 2.2.6b virtual/os-headers: 2.6.30-r1 ACCEPT_KEYWORDS="ppc ~ppc" ACCEPT_LICENSE="* -@EULA IBM-J1.5 IBM-J1.6" CBUILD="powerpc-unknown-linux-gnu" CFLAGS="-mcpu=7400 -O2 -pipe -fno-strict-aliasing -maltivec -mabi=altivec" CHOST="powerpc-unknown-linux-gnu" CONFIG_PROTECT="/etc /usr/share/X11/xkb /usr/share/config" CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d /etc/env.d/java/ /etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release /etc/php/apache2-php5/ext-active/ /etc/php/cgi-php5/ext-active/ /etc/php/cli-php5/ext-active/ /etc/revdep-rebuild /etc/sandbox.d /etc/terminfo /etc/texmf/language.dat.d /etc/texmf/language.def.d /etc/texmf/updmap.d /etc/texmf/web2c /etc/udev/rules.d" CXXFLAGS="-mcpu=7400 -O2 -pipe -fno-strict-aliasing -maltivec -mabi=altivec" DISTDIR="/in_n_outs/distfiles" FEATURES="assume-digests ccache distlocks fixpackages news parallel-fetch preserve-libs protect-owned sandbox sfperms strict unmerge-logs unmerge-orphans userfetch" GENTOO_MIRRORS="http://mirror.uni-c.dk/pub/gentoo/ ftp://trumpetti.atm.tut.fi/gentoo/ ftp://ftp.tu-clausthal.de/pub/linux/gentoo/ ftp://mirror.switch.ch/mirror/gentoo/ ftp://ftp.heanet.ie/pub/gentoo/ ftp://ftp.snt.utwente.nl/pub/os/linux/gentoo http://mirror.gentoo.no/ " LANG="C" LC_ALL="C" LDFLAGS="-Wl,-O1" LINGUAS="fr fr_FR" MAKEOPTS="-j2" PKGDIR="/in_n_outs/packages" PORTAGE_CONFIGROOT="/" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage/layman/java-overlay /usr/local/portage" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="X Xaw3d a52 aac acl alsa altivec apache2 berkdb bluetooth branding bzip2 cairo cdr cli consolekit cracklib crypt cscope cups cxx dba dbus dri dts dvd dvdr eds emboss encode evo fam fbcon filter flac flash fortran gb gcj gd gdbm gif gnome gpm gstreamer gtk gtk2 hal iconv ipv6 java jikes jpeg kde kdehiddenvisibility kpathsea ldap libnotify mad mikmod mng modules mozdevelop mozsvg mp3 mp4 mpeg mudflap ncurses nls nptl nptlonly nsplugin objc ogg oggvorbis opengl openmp pam pcre pdf pdflib perl png povray ppc ppds pppd python qt qt3support qt4 quicktime readline reflection samba scanner sdl session speex spell spl ssl startup-notification svg sysfs tcpd tetex theora threads thunar tiff tk truetype udev unicode usb vorbis wmf x264 xine xinerama xml xml2 xorg xosd xulrunner xv xvid zlib" ALSA_CARDS="snd-aoa" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mmap_emul mulaw multi null plug rate route share shm softvol" APACHE2_MODULES="actions alias auth_basic auth_digest authn_anon authn_dbd authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache dav dav_fs dav_lock dbd deflate dir disk_cache env expires ext_filter file_cache filter headers ident imagemap include info log_config logio mem_cache mime mime_magic negotiation proxy proxy_ajp proxy_balancer proxy_connect proxy_http rewrite setenvif so speling status unique_id userdir usertrack vhost_alias" ELIBC="glibc" INPUT_DEVICES="keyboard mouse wacom evdev" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LINGUAS="fr fr_FR" RUBY_TARGETS="ruby18" USERLAND="GNU" VIDEO_CARDS="ati fbdev radeon" Unset: CPPFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, FFLAGS, INSTALL_MASK, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS
I encountered the very same problem using binutils-2.0.20 and also binutils-2.0.20.51.0.3, except that removing -Wl,--gc-section does not help, at least not with ld-2.20.0.51.0.3.20091109. I think you edited the Makefile in src/3rdparty/webkit/WebCore? When using 2.0.20, the linker normally terminated with the memory exhausted message. In one particular case, I also got a core dump, but it was unusable because the stack was overwritten. The memory consumption (from swap alone) peaked around 1,1 Giga Byte. Maybe the 1.5 GB limit put up by pax SEGMEXEC plays a role in why your workaround does not help here. Opensolaris (don't know if they also use GNU ld) has a very similar problem with qt-webkit: http://defect.opensolaris.org/bz/show_bug.cgi?id=9720
(In continuation of my own comment #1) When I tried to use the gold version (using EXTRA_ECONF=--enable-gold, as USE="gold" still appears to be filtered by the toolchain eclass), ld threw "std::badalloc" when using the original Makefile, although the memory consumption was about 30% when compared with old ld implemenation (which could point to heap fragmentation) When the parameter "-Wl,--gc-sections" was removed, ld (2.20.51.0.3) said: ld: fatal error: libqQtWebKit.so.4.6.0: mmap: failed to allocated 445046982 bytes for output file: Cannot allocated memory. Well, an output file of 445*10^6 bytes?
Created attachment 212683 [details] Simple Test program to show memory leaks in collect2
Created attachment 212684 [details] valgrind log file showing several memory leaks Sorry, I can't copy and paste after kde update failed due to this bug. Therefore I had attached two files. The file collect2.valgrind.log was produced by running the linker command line as obtained from gcc -v. active ld is from binutils-2.20. I'm unsure about the significance of the valgrind output. But some seem to be related to obstack, which I believe is heavily used by libbfd I will also attach the valgrind command line. (Note on running valgrind on hardened: one needs to run paxctl -m on /usr/lib/valgrind/memcheck-x86-linux).
Created attachment 212686 [details] run linker command under valgrind control Note that the linker command line is specific for hardened gcc as obtained by gcc -v
I repeated the experiment to link qt-webkit on a amd64 system equipped with 4 Gigabytes of physical RAM. When doing it the first time ld crashed. Then, when running make the second time, the kernel OOM handler even killed my session -- but I'll address this problem separately, as this link seems to have exposed a dma-related kernel bug (via mmap). After I removed -ggdb from CFLAGS/CXXFLAGS, ld succeeded even on that old ~x86 machine with 512 Megabytes of physical RAM. This made it possible to run ld under valgrind control even there. As expected, valgrind showed many small definite leaks, but virtally dozens in the MB range, though marked only as possible leaks. Below, I'm showing just the last two of them. ==7462== Command: /usr/lib/gcc/i686-pc-linux-gnu/4.3.4/../../../../i686-pc-linux-gnu/bin/ld [....] ==7462== 21,429,472 bytes in 5,273 blocks are possibly lost in loss record 188 of 190 ==7462== at 0x48256CF: malloc (vg_replace_malloc.c:195) ==7462== by 0x48D724E: _objalloc_alloc (objalloc.c:152) ==7462== by 0x4852980: bfd_hash_allocate (hash.c:571) ==7462== by 0x4850C89: bfd_section_hash_newfunc (section.c:744) ==7462== by 0x4852B3F: bfd_hash_insert (hash.c:483) ==7462== by 0x4852E45: bfd_hash_lookup (hash.c:470) ==7462== by 0x4850D1E: bfd_make_section_anyway_with_flags (section.c:1065) ==7462== by 0x4850DCA: bfd_make_section_anyway (section.c:1112) ==7462== by 0x4881302: _bfd_elf_make_section_from_shdr (elf.c:826) ==7462== by 0x48823F4: bfd_section_from_shdr (elf.c:1700) ==7462== by 0x4870457: bfd_elf32_object_p (elfcode.h:851) ==7462== by 0x484B0EA: bfd_check_format_matches (format.c:169) ==7462== ==7462== 26,441,772 bytes in 1,631 blocks are possibly lost in loss record 189 of 190 ==7462== at 0x48256CF: malloc (vg_replace_malloc.c:195) ==7462== by 0x48D72BB: _objalloc_alloc (objalloc.c:136) ==7462== by 0x4853186: bfd_hash_table_init_n (hash.c:378) ==7462== by 0x48531E3: bfd_hash_table_init (hash.c:402) ==7462== by 0x48447CE: bfd_preserve_save (bfd.c:1621) ==7462== by 0x487015E: bfd_elf32_object_p (elfcode.h:538) ==7462== by 0x484B0EA: bfd_check_format_matches (format.c:169) ==7462== by 0x11D12D: load_symbols (ldlang.c:2590) ==7462== by 0x11DC19: open_input_bfds (ldlang.c:3138) ==7462== by 0x11F26A: lang_process (ldlang.c:6287) ==7462== by 0x1249B9: main (ldmain.c:461) If these huge leaks have any significance obviously depends on ld's implementation. As debug information compiled in via -ggdb seems to be a necessary condition for ld to fail, I'd not be surprised for the small leaks being recognized to be responsible for the real problem. I'll attach the complete valgrind log. I obtained it by changing the following line in "src/3rdparty/webkit/WebCore/Makefile": #LINK = @echo linking $@ && g++ LINK = valgrind --leak-check=full --read-var-info=yes \ --run-libc-freeres=yes --trace-children=yes g++
Created attachment 212829 [details] valgrind output of qt-webkit-4.3.4 link phase ld --version: GNU ld (GNU Binutils) 2.20
I've been running into something similar when linking on ppc64. This machine has 16 GB of ram, and I have not been running out of memory. The error I have been getting is: linking ../../../../lib/libQtWebKit.so.4.6.0 /usr/lib/gcc/powerpc64-unknown-linux-gnu/4.4.2/../../../../powerpc64-unknown-linux-gnu/bin/ld: BFD (GNU Binutils) 2.19.1 internal error, aborting at /var/tmp/portage/sys-devel/binutils-2.19.1-r1/work/binutils-2.19.1/bfd/elf64-ppc.c line 5545 in ppc64_elf_gc_sweep_hook /usr/lib/gcc/powerpc64-unknown-linux-gnu/4.4.2/../../../../powerpc64-unknown-linux-gnu/bin/ld: Please report this bug. which it seems has already been reported upstream, and patches exist. http://sourceware.org/bugzilla/show_bug.cgi?id=11088
thanks marty, those patches apparently did the trick and let me compile qt-webkit on my powerbook. cheers
qt-webkit-4.6.1 built for me when using binutils-2.20.51.0.5 on ppc. It failed with a lower binutils version.
(In reply to comment #10) > qt-webkit-4.6.1 built for me when using binutils-2.20.51.0.5 on ppc. It failed > with a lower binutils version. > Yes, it also did if for me. Thanks ! Sorry for late reply, but a G4 is not as fast as twice...
*** Bug 297671 has been marked as a duplicate of this bug. ***
Bug #302696 appears to have superseded this.
*** This bug has been marked as a duplicate of bug 302696 ***
