There is an error on emerging newly-stabilized-but-failed firefox-10.0.3:
Firefox building has become a monster, long build time and huge memory usage during linking stage. 64% of 2GB more. A few version after, I might need to user firefox-bin, just like libreoffice-bin.
I looked into Changelog and saw this is actually something called 10.0.3 ESR (Extended Support Release), which is begun with Firefox 10. And this is why there is an "esr" string in "mozilla-esr10." I don't know if this ESR has different build process or because 10.0.3 is a planned security update, therefore the Gentoo dev rushed to mark 10.0.3 as stable.
I can't remember I have ever had Firefox failed to emerge before. When some big update is included, I always wait for a while, monitor the forums. I forgot that this time. Everything has its first, doesn't it?
Anyway, be sure to subscribe to RSS feed of firefox package updates, so you don't need to keep watching for the fix.
The comments in the bug report also reported that this is not x86_64 only, you other arch users, we, x86_64 users, are your lab rat! ;p
I actually tried to symlink to actual shlibsign was when I was trying to resolve the issue, but it was actually a directory not an executable file. I was hoping the build script would somehow pick it up and build that build. It didn't work.
Now I know, I can bypass it, I bet you you can do the following to bypass while emerging:
The problem here is it does not resolve the issue as the patch submitter said it's a workaround. There is a reason why the build script wants to run that file, even it seems that we don't need that process.
As I said in My weekly Gentoo update process:
No need to rush for an update, let others be your lab rats! xD
run-mozilla.sh: Cannot execute /var/tmp/portage/www-client/firefox-10.0.3/work/mozilla-esr10/obj-x86_64-unknown-linux-gnu/browser/installer/../../dist/bin/shlibsign.The more complete build log:
Warning: package error or possible missing or unnecessary file: bin/libnssckbi.so (package-manifest, 372).
bin/components/pipboot.xpt
bin/components/pipnss.xpt
bin/components/pippki.xpt
Warning: package error or possible missing or unnecessary file: bin/libnss3.so (package-manifest, 376).
Warning: package error or possible missing or unnecessary file: bin/libnssutil3.so (package-manifest, 377).
Warning: package error or possible missing or unnecessary file: bin/libsmime3.so (package-manifest, 378).
Warning: package error or possible missing or unnecessary file: bin/libsoftokn3.so (package-manifest, 379).
Warning: package error or possible missing or unnecessary file: bin/libfreebl3.so (package-manifest, 380).
Warning: package error or possible missing or unnecessary file: bin/libssl3.so (package-manifest, 381).
Warning: package error or possible missing or unnecessary file: bin/libfreebl3.chk (package-manifest, 382).
Warning: package error or possible missing or unnecessary file: bin/libsoftokn3.chk (package-manifest, 383).
Warning: package error or possible missing or unnecessary file: bin/libnssdbm3.so (package-manifest, 384).
Warning: package error or possible missing or unnecessary file: bin/libnssdbm3.chk (package-manifest, 385).
[snip]
Linking .xpt files...
[browser]
Manifest file: ../../dist/firefox//components/interfaces.manifestLinking .xpt files completed.
/usr/bin/python2.7 /var/tmp/portage/www-client/firefox-10.0.3/work/mozilla-esr10/toolkit/mozapps/installer/link-manifests.py \
../../dist/firefox//components/components.manifest \
../../dist/manifests/xpcom/components ../../dist/manifests/browser/components
Warning: trying to link manifests in missing directory '../../dist/manifests/xpcom/components'
/usr/bin/python2.7 /var/tmp/portage/www-client/firefox-10.0.3/work/mozilla-esr10/toolkit/mozapps/installer/link-manifests.py \
../../dist/firefox//chrome/nonlocalized.manifest \
../../dist/manifests/xpcom/chrome ../../dist/manifests/browser/chrome
Warning: trying to link manifests in missing directory '../../dist/manifests/xpcom/chrome'
/usr/bin/python2.7 /var/tmp/portage/www-client/firefox-10.0.3/work/mozilla-esr10/toolkit/mozapps/installer/link-manifests.py \
../../dist/firefox//chrome/localized.manifest \
../../dist/manifests/en-US/chrome
printf "manifest components/interfaces.manifest\nmanifest components/components.manifest\nmanifest chrome/nonlocalized.manifest\nmanifest chrome/localized.manifest\n" > ../../dist/firefox//chrome.manifest
/usr/bin/python2.7 /var/tmp/portage/www-client/firefox-10.0.3/work/mozilla-esr10/config/optimizejars.py --optimize /var/tmp/portage/www-client/firefox-10.0.3/work/mozilla-esr10/obj-x86_64-unknown-linux-gnu/browser/installer/../../jarlog//en-US ../../dist/bin/chrome ../../dist/firefox/chrome
signing nss libraries
run-mozilla.sh: Cannot execute /var/tmp/portage/www-client/firefox-10.0.3/work/mozilla-esr10/obj-x86_64-unknown-linux-gnu/browser/installer/../../dist/bin/shlibsign.
make[1]: *** [stage-package] Error 1
make[1]: Leaving directory `/var/tmp/portage/www-client/firefox-10.0.3/work/mozilla-esr10/obj-x86_64-unknown-linux-gnu/browser/installer'
make: *** [install] Error 2
emake failed
* ERROR: www-client/firefox-10.0.3 failed (install phase):
* emake install failed
*
* Call stack:
* ebuild.sh, line 85: Called src_install
* environment, line 6495: Called die
* The specific snippet of code:
* MOZ_MAKE_FLAGS="${MAKEOPTS}" emake DESTDIR="${D}" install || die "emake install failed";
*
* If you need support, post the output of 'emerge --info =www-client/firefox-10.0.3',
* the complete build log and the output of 'emerge -pqv =www-client/firefox-10.0.3'.
* The complete build log is located at '/var/tmp/portage/www-client/firefox-10.0.3/temp/build.log'.
* The ebuild environment file is located at '/var/tmp/portage/www-client/firefox-10.0.3/temp/environment'.
* S: '/var/tmp/portage/www-client/firefox-10.0.3/work/mozilla-esr10'
* Messages for package www-client/firefox-10.0.3:
* You are enabling official branding. You may not redistribute this build
* to any users on your network or the internet. Doing so puts yourself into
* a legal problem with Mozilla Foundation
* You can disable it by emerging firefox _with_ the bindist USE-flag
* Fallback PaX marking -m
* /var/tmp/portage/www-client/firefox-10.0.3/work/mozilla-esr10/obj-x86_64-unknown-linux-gnu/dist/bin/xpcshell
* ERROR: www-client/firefox-10.0.3 failed (install phase):
* emake install failed
*
* Call stack:
* ebuild.sh, line 85: Called src_install
* environment, line 6495: Called die
* The specific snippet of code:
* MOZ_MAKE_FLAGS="${MAKEOPTS}" emake DESTDIR="${D}" install || die "emake install failed";
*
* If you need support, post the output of 'emerge --info =www-client/firefox-10.0.3',
* the complete build log and the output of 'emerge -pqv =www-client/firefox-10.0.3'.
* The complete build log is located at '/var/tmp/portage/www-client/firefox-10.0.3/temp/build.log'.
* The ebuild environment file is located at '/var/tmp/portage/www-client/firefox-10.0.3/temp/environment'.
* S: '/var/tmp/portage/www-client/firefox-10.0.3/work/mozilla-esr10'
The problem seem to be path issue and only on x86_64 arch (because this arch is only one got stabilized). Someone unmasked 11.0 to skip the issue, but I don't want to build again, ccache already have cache for 10.0.3. Another 2 hours for 11.0? Not gonna do it. I will wait for a fix.Firefox building has become a monster, long build time and huge memory usage during linking stage. 64% of 2GB more. A few version after, I might need to user firefox-bin, just like libreoffice-bin.
I looked into Changelog and saw this is actually something called 10.0.3 ESR (Extended Support Release), which is begun with Firefox 10. And this is why there is an "esr" string in "mozilla-esr10." I don't know if this ESR has different build process or because 10.0.3 is a planned security update, therefore the Gentoo dev rushed to mark 10.0.3 as stable.
I can't remember I have ever had Firefox failed to emerge before. When some big update is included, I always wait for a while, monitor the forums. I forgot that this time. Everything has its first, doesn't it?
Anyway, be sure to subscribe to RSS feed of firefox package updates, so you don't need to keep watching for the fix.
The workaround is here (2012-03-24T04:47:15Z)
A workaround was posted and I wish I had read it soon enough. It basically bypasses the non-existing executable file,shlibsign, by changing && to ;. If you know shell scripting, you know what that does.The comments in the bug report also reported that this is not x86_64 only, you other arch users, we, x86_64 users, are your lab rat! ;p
I actually tried to symlink to actual shlibsign was when I was trying to resolve the issue, but it was actually a directory not an executable file. I was hoping the build script would somehow pick it up and build that build. It didn't work.
Now I know, I can bypass it, I bet you you can do the following to bypass while emerging:
ln -s shlibsign /bin/trueThe problem here is it does not resolve the issue as the patch submitter said it's a workaround. There is a reason why the build script wants to run that file, even it seems that we don't need that process.
As I said in My weekly Gentoo update process:
When you have doubts or you are nervous about an update, do a search for those guides. Or wait for a little bit, say a few days, then search on forums to see if there is any victims :)
No need to rush for an update, let others be your lab rats! xD