Summary: | www-client/firefox-5.0-r1 fails to build: "collect2: ld returned 1 exit status" | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Dennis Schridde <dschridde+gentoobugs> |
Component: | Current packages | Assignee: | Mozilla Gentoo Team <mozilla> |
Status: | RESOLVED INVALID | ||
Severity: | normal | CC: | alex_pogodin, follettoonip, nikoli |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: | build.log (xz compressed) |
Description
Dennis Schridde
2011-06-27 08:42:16 UTC
Created attachment 278327 [details]
build.log (xz compressed)
Same issue here on my laptop. Oddly enough it built fine on my workstation, which is quite similar in regards to portage config / packages but much less frequently updated. Do you see these messages too? scanelf: rpath_security_checks(): Maybe? sec problem with DT_RPATH='lib64:/usr/lib64/xulrunner-devel-2.0/lib' in /usr/lib64/libproxy.so scanelf: rpath_security_checks(): Maybe? sec problem with DT_RUNPATH='lib64:/usr/lib64/xulrunner-devel-2.0/lib' in /usr/lib64/libproxy.so scanelf: rpath_security_checks(): Maybe? sec problem with DT_RPATH='lib64:/usr/lib64/xulrunner-devel-2.0/lib' in /usr/lib64/libproxy.so.1.0.0 scanelf: rpath_security_checks(): Maybe? sec problem with DT_RUNPATH='lib64:/usr/lib64/xulrunner-devel-2.0/lib' in /usr/lib64/libproxy.so.1.0.0 scanelf: rpath_security_checks(): Maybe? sec problem with DT_RPATH='lib64:/usr/lib64/xulrunner-devel-2.0/lib' in /usr/lib64/libproxy.so.1 scanelf: rpath_security_checks(): Maybe? sec problem with DT_RUNPATH='lib64:/usr/lib64/xulrunner-devel-2.0/lib' in /usr/lib64/libproxy.so.1 scanelf: rpath_security_checks(): Maybe? sec problem with DT_RPATH='lib64:/usr/lib64/xulrunner-devel-2.0/lib' in /usr/lib64/libproxy.so scanelf: rpath_security_checks(): Maybe? sec problem with DT_RUNPATH='lib64:/usr/lib64/xulrunner-devel-2.0/lib' in /usr/lib64/libproxy.so scanelf: rpath_security_checks(): Maybe? sec problem with DT_RPATH='lib64:/usr/lib64/xulrunner-devel-2.0/lib' in /usr/lib64/libproxy.so.1.0.0 scanelf: rpath_security_checks(): Maybe? sec problem with DT_RUNPATH='lib64:/usr/lib64/xulrunner-devel-2.0/lib' in /usr/lib64/libproxy.so.1.0.0 scanelf: rpath_security_checks(): Maybe? sec problem with DT_RPATH='lib64:/usr/lib64/xulrunner-devel-2.0/lib' in /usr/lib64/libproxy.so.1 scanelf: rpath_security_checks(): Maybe? sec problem with DT_RUNPATH='lib64:/usr/lib64/xulrunner-devel-2.0/lib' in /usr/lib64/libproxy.so.1 scanelf: rpath_security_checks(): Maybe? sec problem with DT_RPATH='lib64:/usr/lib64/xulrunner-devel-2.0/lib' in /usr/lib64/libproxy.so scanelf: rpath_security_checks(): Maybe? sec problem with DT_RUNPATH='lib64:/usr/lib64/xulrunner-devel-2.0/lib' in /usr/lib64/libproxy.so scanelf: rpath_security_checks(): Maybe? sec problem with DT_RPATH='lib64:/usr/lib64/xulrunner-devel-2.0/lib' in /usr/lib64/libproxy.so.1.0.0 scanelf: rpath_security_checks(): Maybe? sec problem with DT_RUNPATH='lib64:/usr/lib64/xulrunner-devel-2.0/lib' in /usr/lib64/libproxy.so.1.0.0 scanelf: rpath_security_checks(): Maybe? sec problem with DT_RPATH='lib64:/usr/lib64/xulrunner-devel-2.0/lib' in /usr/lib64/libproxy.so.1 scanelf: rpath_security_checks(): Maybe? sec problem with DT_RUNPATH='lib64:/usr/lib64/xulrunner-devel-2.0/lib' in /usr/lib64/libproxy.so.1 I'm running portage 2.2... Stupid thing is, equery b /usr/lib/libproxy.so and equery b /usr/lib64/libproxy.so don't find any packages to which this file should belong. Beh no edit. Forgot to ask, can you check if you a) have the files (/usr/lib(64)/libproxy.so(.1(.0.0)))? b) if a, if equery b <filename> can find them (probably wise to use both /usr/lib/libproxy.so and /usr/lib64/libproxy.so as paths). Thanks have you enough space to disk/tmpfs? Yes on the diskspace. It was tight in my /var/tmp/portage tmpfs, but unmounting it (and thus using local disk) yielded same results. This solved it for me (use at your OWN risk, I do not have a complete idea on what the removal breaks, revdep-rebuild should give you some indications, maybe better to move them... since libproxy.so files couldn't be found by equery I just deleted them as they're probably left over from some old package) rm /usr/lib64/libproxy.so* revdep-rebuild emerge -1 xulrunner # (doubt this is necessary, but I already had it running because the ld error status was on libxul.so) emerge firefox (In reply to comment #6) > emerge -1 xulrunner > # (doubt this is necessary, but I already had it running because the ld error > status was on libxul.so) I think firefox-5.0 contains xulrunner internally. At least the compiletime and the missing DEPEND=xulrunner suggest this. (In reply to comment #4) > Beh no edit. Forgot to ask, can you check if you > a) have the files (/usr/lib(64)/libproxy.so(.1(.0.0)))? > b) if a, if equery b <filename> can find them (probably wise to use both > /usr/lib/libproxy.so and /usr/lib64/libproxy.so as paths). $ q file -v /usr/lib/libproxy.so net-libs/libproxy-0.4.6-r3 (/usr/lib64/libproxy.so) libproxy is (no longer) installed here: ~/ eix libproxy * net-libs/libproxy Available versions: 0.4.6 (~)0.4.6-r2 (~)0.4.6-r3 {gnome kde mono networkmanager perl python test vala webkit xulrunner} Homepage: http://code.google.com/p/libproxy/ Description: Library for automatic proxy configuration management I recently ran depclean/prune (emerge --depclean; emerge -DP). Proxy settings here seem to work fine (usually don't use proxies but currently at a customer where it's required). (In reply to comment #5) > have you enough space to disk/tmpfs? I resized /var/tmp/portage from 2G to 4G and now firefox builds. I don't have a different partition for /var/tmp/portage, but it saturates both ram and swap for a total of about 8G. Also 5.0 was built correctly so there's something wrong with the new patches. (In reply to comment #11) > I don't have a different partition for /var/tmp/portage, but it saturates both > ram and swap for a total of about 8G. Also 5.0 was built correctly so there's > something wrong with the new patches. There is nothing wrong with the patches, the problem is space, we need to add a check to ensure there is enough space left on device to link libxul, if we were to allow the build to strip during install it would save a ton of space on the device during src_install. If you guys have problems with space and/or RAM, use the -bin version. The compiled version isn't really be that much faster, seriously. Besides, there's no separate xulrunner anymore which means you don't have to compile it for anything else. We think about adding some warnings to pkg_pretend or pkg_setup, but it's not guaranteed. |