Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 471968 - www-client/seamonkey-2.18_beta4[crypt] build fails - error while loading shared libraries: libxpcom.so: cannot open shared object file: No such file or directory
Summary: www-client/seamonkey-2.18_beta4[crypt] build fails - error while loading shar...
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: Lars Wendler (Polynomial-C) (RETIRED)
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-06-01 02:26 UTC by Ben Kohler
Modified: 2013-07-12 21:10 UTC (History)
5 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
build.log.xz (build.log.xz,365.35 KB, application/x-xz)
2013-06-01 02:26 UTC, Ben Kohler
Details
create enigmail xpi later in ebuild (seamonkey-2.19.diff,797 bytes, patch)
2013-07-12 13:38 UTC, Jory A. Pratt
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Ben Kohler gentoo-dev 2013-06-01 02:26:47 UTC
Created attachment 349794 [details]
build.log.xz

The error mentioned in the summary happens during src_install but I think there must be an earlier undetected error.  This is suspect but I don't know what to do with it:

--------
if test -d ../../../mozilla/dist/bin ; then touch ../../../mozilla/dist/bin/.purgecaches ; fi
make -j1 xpi
/var/tmp/portage/www-client/seamonkey-2.18_beta4/work/comm-beta/mailnews/extensions/enigmail/genxpi enigmail-1.5-linux-x86_64.xpi 1.5 Linux "x86_64-gcc3" seamonkey-2.18 ../../../mozilla/dist/bin /var/tmp/portage/www-client/seamonkey-2.18_beta4/work/comm-beta/mailnews/extensions/enigmail enigmail .so lib
genxpi: Generating enigmail-1.5-linux-x86_64.xpi in ../../../mozilla/dist/bin
cp: cannot stat 'components/libenigmime.so': No such file or directory
--------



Portage 2.2.0_alpha177 (default/linux/amd64/13.0/desktop/gnome, gcc-4.7.3, glibc-2.17, 3.9.4 x86_64)
=================================================================
System uname: Linux-3.9.4-x86_64-Intel-R-_Core-TM-_i5-3470_CPU_@_3.20GHz-with-gentoo-2.2
KiB Mem:     8070256 total,   3633296 free
KiB Swap:          0 total,         0 free
Timestamp of tree: Fri, 31 May 2013 12:45:01 +0000
ld GNU ld (GNU Binutils) 2.23.1
app-shells/bash:          4.2_p45
dev-lang/python:          2.7.5, 3.2.5, 3.3.2
dev-util/cmake:           2.8.10.2-r2
dev-util/pkgconfig:       0.28
sys-apps/baselayout:      2.2
sys-apps/openrc:          0.11.8
sys-apps/sandbox:         2.6-r1
sys-devel/autoconf:       2.13, 2.69
sys-devel/automake:       1.11.6, 1.12.6, 1.13.2
sys-devel/binutils:       2.23.1
sys-devel/gcc:            4.7.3
sys-devel/gcc-config:     1.8
sys-devel/libtool:        2.4.2
sys-devel/make:           3.82-r4
sys-kernel/linux-headers: 3.9 (virtual/os-headers)
sys-libs/glibc:           2.17
Repositories: gentoo iamben temp-fix
Installed sets: @system
ACCEPT_KEYWORDS="amd64 ~amd64"
ACCEPT_LICENSE="* -@EULA google-chrome Intel-SDP googleearth Oracle-BCLA-JavaSE dlj-1.1 PUEL AdobeFlash-11.x"
CBUILD="x86_64-pc-linux-gnu"
CFLAGS="-O2 -pipe -march=native"
CHOST="x86_64-pc-linux-gnu"
CONFIG_PROTECT="/etc /usr/share/config /usr/share/gnupg/qualified.txt /usr/share/polkit-1/actions"
CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/dconf /etc/env.d /etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release /etc/revdep-rebuild /etc/sandbox.d /etc/terminfo /etc/xdg/autostart/"
CXXFLAGS="-O2 -pipe -march=native"
DISTDIR="/var/db/distfiles"
EMERGE_DEFAULT_OPTS="--autounmask=n -j2 --with-bdeps=y"
FCFLAGS="-O2 -pipe"
FEATURES="assume-digests binpkg-logs config-protect-if-modified distlocks ebuild-locks fixlafiles merge-sync news parallel-fetch preserve-libs protect-owned sandbox sfperms strict unknown-features-warn unmerge-logs unmerge-orphans userfetch"
FFLAGS="-O2 -pipe"
GENTOO_MIRRORS="http://distfiles.gentoo.org"
LANG="en_US.utf8"
LDFLAGS="-Wl,-O1 -Wl,--as-needed"
MAKEOPTS="-j5"
PKGDIR="/usr/portage/packages"
PORTAGE_CONFIGROOT="/"
PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --stats --human-readable --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages"
PORTAGE_TMPDIR="/var/tmp"
PORTDIR="/var/db/portage"
PORTDIR_OVERLAY="/var/lib/layman/iamben /usr/local/portage"
SYNC="rsync://ris-cel.vtaig.com/gentoo-portage"
USE="X a52 aac acl acpi alsa amd64 berkdb branding bzip2 cairo cdda cdr cli consolekit cracklib crypt cups cxx dbus dconf dri dts dvd dvdr eds emboss encode evo exif fam ffmpeg firefox flac fortran gdbm gdu gif gnome gnome-keyring gnome-online-accounts gpm gstreamer gtk gtk3 iconv icu jpeg kde lcms libnotify libsecret mad mmx mng modules mp3 mp4 mpeg mudflap multilib nautilus ncurses networkmanager nptl ogg opengl openmp pam pango pcre pdf png policykit ppds pulseaudio qt3support qt4 readline samba sdl session socialweb spell sse sse2 ssl ssse3 startup-notification svg tcpd theora threads tiff truetype udev udisks unicode upower usb vaapi vala vorbis x264 xcb xml xv xvid zlib" ABI_X86="64" ALSA_CARDS="ali5451 als4000 atiixp atiixp-modem bt87x ca0106 cmipci emu10k1x ens1370 ens1371 es1938 es1968 fm801 hda-intel intel8x0 intel8x0m maestro3 trident usb-audio via82xx via82xx-modem ymfpci" APACHE2_MODULES="authn_core authz_core socache_shmcb unixd actions alias auth_basic authn_alias authn_anon authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache cgi cgid dav dav_fs dav_lock deflate dir disk_cache env expires ext_filter file_cache filter headers include info log_config logio mem_cache mime mime_magic negotiation rewrite setenvif speling status unique_id userdir usertrack vhost_alias" CALLIGRA_FEATURES="kexi words flow plan sheets stage tables krita karbon braindump author" CAMERAS="ptp2" COLLECTD_PLUGINS="df interface irq load memory rrdtool swap syslog" ELIBC="glibc" GPSD_PROTOCOLS="ashtech aivdm earthmate evermore fv18 garmin garmintxt gpsclock itrax mtk3301 nmea ntrip navcom oceanserver oldstyle oncore rtcm104v2 rtcm104v3 sirf superstar2 timing tsip tripmate tnt ubx" GRUB_PLATFORMS="efi-64" INPUT_DEVICES="evdev" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LIBREOFFICE_EXTENSIONS="presenter-console presenter-minimizer" LINGUAS="en" OFFICE_IMPLEMENTATION="libreoffice" PHP_TARGETS="php5-3" PYTHON_SINGLE_TARGET="python2_7" PYTHON_TARGETS="python2_7 python3_2" RUBY_TARGETS="ruby19" USERLAND="GNU" VIDEO_CARDS="intel i965" XTABLES_ADDONS="quota2 psd pknock lscan length2 ipv4options ipset ipp2p iface geoip fuzzy condition tee tarpit sysrq steal rawnat logmark ipmark dhcpmac delude chaos account"
Unset:  CPPFLAGS, CTARGET, INSTALL_MASK, LC_ALL, PORTAGE_BUNZIP2_COMMAND, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS, USE_PYTHON
Comment 1 Guy 2013-06-01 21:30:06 UTC
Same problem here both x86 and amd64.

Setting MAKEOPTS="-j1" did not help.
Comment 2 Guy 2013-06-01 21:40:47 UTC
Perhaps this is the error?

/var/tmp/portage/www-client/seamonkey-2.18_beta4/work/comm-beta/seamonk/mozilla/dist/bin/xpcshell

Shouldn't 'seamonk' be 'seamonkey'?
Comment 3 Guy 2013-06-01 22:04:55 UTC
(In reply to Guy from comment #2)
> Perhaps this is the error?
> 
> /var/tmp/portage/www-client/seamonkey-2.18_beta4/work/comm-beta/seamonk/
> mozilla/dist/bin/xpcshell
> 
> Shouldn't 'seamonk' be 'seamonkey'?

Ignore this - I don't know where my head was.

I actually meant this line:

/comm-beta/mozilla/xpcom/stub/dependentlibs.py libxpcom.so -L ../../dist/bin  > ../../dist/bin/dependentlibs.list

Shouldn't " ../../dist/bin " read "../../seamonk/dist/bin "? {or something which gives equivalent results}

Earlier in the build, the following is executed:

var/tmp/portage/www-client/seamonkey-2.18_beta4/work/comm-beta/seamonk/mozilla/config/nsinstall -t -m 644 "libxpcom.so" "../../dist/bin" which implies the absolute path for libxpcom.so is:

/var/tmp/portage/www-client/seamonkey-2.18_beta4/work/comm-beta/seamonk/mozilla/dist/bin/

The dependentlibs.py command implies an absolute path of /var/tmp/portage/www-client/seamonkey-2.18_beta4/work/comm-beta/mozilla/dist/bin/

At least, that's how I seem to read it. Then again, I'm not a programmer.

;)

The following is true on my systems:

# ls -l /var/tmp/portage/www-client/seamonkey-2.18_beta4/work/comm-beta/seamonk/mozilla/dist/bin/
total 1936
-rw-r--r--  1 root root     513 Jun  1 12:06 application.ini
-rw-r--r--  1 root root   45780 May  2 23:02 blocklist.xml
drwxr-xr-x 12 root root    4096 Jun  1 15:30 chrome
drwxr-xr-x  2 root root   20480 Jun  1 15:30 components
drwxr-xr-x  7 root root    4096 Jun  1 15:30 defaults
-rw-r--r--  1 root root      70 Jun  1 15:29 dependentlibs.list
drwxr-xr-x  2 root root    4096 Jun  1 15:16 dictionaries
drwxr-xr-x  3 root root    4096 Jun  1 15:30 distribution
-rw-r--r--  1 root root 1290934 Jun  1 15:30 enigmail-1.5-linux-x86_64.xpi
drwxr-xr-x  2 root root    4096 Jun  1 15:30 extensions
lrwxrwxrwx  1 root root      37 Jun  1 12:32 greprefs.js -> ../../modules/libpref/src/greprefs.js
drwxr-xr-x  2 root root    4096 Jun  1 12:32 hyphenation
drwxr-xr-x  2 root root    4096 Jun  1 15:25 isp
lrwxrwxrwx  1 root root      21 Jun  1 12:19 js -> ../../js/src/shell/js
lrwxrwxrwx  1 root root     102 Jun  1 12:19 js-gdb.py -> /var/tmp/portage/www-client/seamonkey-2.18_beta4/work/comm-beta/seamonk/mozilla/js/src/shell/js-gdb.py
lrwxrwxrwx  1 root root      62 Jun  1 12:19 libldap60.so -> ../../../ldap/sdks/c-sdk/ldap/libraries/libldap/./libldap60.so
lrwxrwxrwx  1 root root      62 Jun  1 12:19 libldif60.so -> ../../../ldap/sdks/c-sdk/ldap/libraries/libldif/./libldif60.so
lrwxrwxrwx  1 root root      36 Jun  1 12:06 libmozalloc.so -> ../../memory/mozalloc/libmozalloc.so
lrwxrwxrwx  1 root root      37 Jun  1 12:32 libmozsqlite3.so -> ../../db/sqlite3/src/libmozsqlite3.so
lrwxrwxrwx  1 root root      66 Jun  1 12:19 libprldap60.so -> ../../../ldap/sdks/c-sdk/ldap/libraries/libprldap/./libprldap60.so
lrwxrwxrwx  1 root root      66 Jun  1 12:19 libssldap60.so -> ../../../ldap/sdks/c-sdk/ldap/libraries/libssldap/./libssldap60.so
-rw-r--r--  1 root root   25315 Jun  1 15:29 libxpcom.so
lrwxrwxrwx  1 root root      31 Jun  1 15:29 libxul.so -> ../../toolkit/library/libxul.so
-rw-r--r--  1 root root   16726 May  2 23:02 license.txt
drwxr-xr-x 12 root root    4096 Jun  1 15:30 modules
lrwxrwxrwx  1 root root      49 Jun  1 15:16 mozilla-xremote-client -> ../../widget/xremoteclient/mozilla-xremote-client
lrwxrwxrwx  1 root root      29 Jun  1 12:06 nsinstall -> ../../js/src/config/nsinstall
drwxr-xr-x  3 root root    4096 Jun  1 15:30 platform
lrwxrwxrwx  1 root root      30 Jun  1 15:20 platform.ini -> ../../toolkit/xre/platform.ini
-rwxr-xr-x  1 root root   89342 Jun  1 15:29 plugin-container
drwxr-xr-x  6 root root    4096 Jun  1 15:06 res
lrwxrwxrwx  1 root root      97 Jun  1 12:06 run-mozilla.sh -> /var/tmp/portage/www-client/seamonkey-2.18_beta4/work/comm-beta/mozilla/build/unix/run-mozilla.sh
-rwxr-xr-x  1 root root  108881 Jun  1 15:30 seamonkey
-rwxr-xr-x  1 root root  108881 Jun  1 15:30 seamonkey-bin
drwxr-xr-x  2 root root    4096 Jun  1 15:29 searchplugins
-rwxr-xr-x  1 root root  179952 Jun  1 15:30 xpcshell
Comment 4 Juergen Rose 2013-06-03 01:02:57 UTC
Same error here.
Comment 5 Juergen Rose 2013-06-08 17:24:51 UTC
Any news? All my computers are for one week every day about one hour busy with the attempt to install seamonkey-2.18_beta4. Should I mask >=seamonkey-2.18_beta4?
Comment 6 Guy 2013-06-09 10:53:19 UTC
(In reply to Juergen Rose from comment #5)
> Any news? All my computers are for one week every day about one hour busy
> with the attempt to install seamonkey-2.18_beta4. Should I mask
> >=seamonkey-2.18_beta4?

Usually, for a case like this, I just mask with "=", not ">=". i.e.:

# echo "=www-client/seamonkey-2.18_beta4" >> /etc/portage/package.mask/package.mask

This way, portage skips the problem package until the next release whatever the next release is {2.18-beta4-r1, 2.18-beta5 or 2.18}. It becomes all automatic and I don't even have to delete the mask because it's superceded.

If you really want to install this release, you can probably update the ebuild in a local overlay.

You would need to find the part of the ebuild which sets up this line:

var/tmp/portage/www-client/seamonkey-2.18_beta4/work/comm-beta/seamonk/mozilla/config/nsinstall -t -m 644 "libxpcom.so" "../../dist/bin"

If you look in your ebuild log, you'll see there are actually three places where "libxpcom.so" is installed in the workfiles. You may be able to modify the ebuild to install "libxpcom.so" to a fourth place in the workfiles to match where the "dependentlibs.py" command expects it.

I'm not a programmer so I simply masked this release.
Comment 7 Jory A. Pratt gentoo-dev 2013-06-10 13:21:16 UTC
The best solution right now is to disable crypt useflag. I am gonna dig into this later today and see what I can make of enigmail failing.
Comment 8 Torsten Kaiser 2013-06-23 16:51:10 UTC
www-client/seamonkey-2.19_beta1 fails in a different way:

make[1]: Leaving directory `/var/tmp/portage/www-client/seamonkey-2.19_beta1/work/comm-beta/seamonk'
make -j6
/var/tmp/portage/www-client/seamonkey-2.19_beta1/work/comm-beta/config/rules.mk:30: *** Variable DIRS is defined in /var/tmp/portage/www-client/seamonkey-2.19_beta1/work/comm-beta/seamonk/mailnews/extensions/enigmail/Makefile. It should only be defined in moz.build files.  Stop.
emake failed
 * ERROR: www-client/seamonkey-2.19_beta1 failed (compile phase):
 *   make enigmail failed

Problem is known and fixed by upstream, but there is not yet a new release of enigmail:
http://sourceforge.net/p/enigmail/bugs/134/

USE=gstreamer will fail the same way as firefox (bug 474074), but the same fix will work. You just need to bump PATCHFF="firefox-22.0-patches-0.1" to PATCHFF="firefox-22.0-patches-0.2".
Comment 9 James Cloos 2013-07-05 04:44:26 UTC
This also affects 2.19.

With USE='-crypt -gstreamer' it worked.
Comment 10 Torsten Kaiser 2013-07-05 17:09:01 UTC
USE=gstreamer builds fine for me, but with USE=crypt and the enigmal snapshot bump in the mozilla-overlay it is back at the original failure of this bug, the install phase not finding its libxpcom.so.

With 2.18 I tried to backtrace what goes wrong there, but I got lost in the build system. It seems the command fails because the library path does not point correctly to the newly build libxpcom.so and the other libs.
As far as I was able to trace the packager is getting that path from some manifest files. As it works with USE=-crypt I suspect some manifest that is part of enigmail is to blame, but I gave up at that point and I not try to find / understand these manifests...
Comment 11 Jory A. Pratt gentoo-dev 2013-07-12 13:38:55 UTC
Created attachment 353154 [details, diff]
create enigmail xpi later in ebuild

Basically enigmail is overwritting the chrome.manifest, we must build enigmails xpi after make install to prevent this from causing the problem. Please test and let us know.
Comment 12 Lars Wendler (Polynomial-C) (RETIRED) gentoo-dev 2013-07-12 21:10:00 UTC
+*seamonkey-2.19 (12 Jul 2013)
+
+  12 Jul 2013; Lars Wendler <polynomial-c@gentoo.org>
+  -seamonkey-2.18_beta4.ebuild, +seamonkey-2.19.ebuild,
+  +files/enigmail_mailnews_extensions_genxpi.patch:
+  Version bump. Removed old. Fixed bug #471968.
+