creating toolkit/mozapps/installer/unix/wizard/Makefile creating toolkit/mozapps/installer/unix/Makefile creating toolkit/mozapps/installer/Makefile creating toolkit/mozapps/installer/windows/Makefile creating toolkit/mozapps/installer/windows/wizard/Makefile creating toolkit/mozapps/installer/windows/wizard/setup/Makefile creating toolkit/mozapps/installer/windows/wizard/setuprsc/Makefile creating toolkit/mozapps/installer/windows/wizard/uninstall/Makefile creating toolkit/mozapps/update/Makefile creating toolkit/mozapps/update/public/Makefile creating toolkit/mozapps/update/src/Makefile creating toolkit/mozapps/xpinstall/Makefile creating toolkit/profile/Makefile creating toolkit/profile/public/Makefile creating toolkit/profile/skin/Makefile creating toolkit/profile/src/Makefile creating toolkit/themes/Makefile creating toolkit/themes/gnomestripe/global/Makefile creating toolkit/themes/gnomestripe/Makefile creating toolkit/themes/pinstripe/communicator/Makefile creating toolkit/themes/pinstripe/Makefile creating toolkit/themes/pinstripe/global/Makefile creating toolkit/themes/pinstripe/help/Makefile creating toolkit/themes/pinstripe/mozapps/Makefile creating toolkit/themes/qute/communicator/Makefile creating toolkit/themes/qute/Makefile creating toolkit/themes/qute/global/Makefile creating toolkit/themes/qute/help/Makefile creating toolkit/themes/qute/mozapps/Makefile creating toolkit/themes/winstripe/communicator/Makefile creating toolkit/themes/winstripe/Makefile creating toolkit/themes/winstripe/global/Makefile creating toolkit/themes/winstripe/help/Makefile creating toolkit/themes/winstripe/mozapps/Makefile creating toolkit/xre/Makefile updating cache ./config.cache creating ./config.status creating config/autoconf.mk creating config/doxygen.cfg creating xpfe/global/buildconfig.html creating toolkit/content/buildconfig.html creating gfx/gfx-config.h creating netwerk/necko-config.h creating xpcom/xpcom-config.h creating xpcom/xpcom-private.h * Parsing Makefiles ... cat: ./config/build_number: No such file or directory cat: ./config/build_number: No such file or directory rm -f -rf ./dist/sdk rm -f -rf ./dist/include /usr/bin/gmake -C config export cat: ../config/build_number: No such file or directory gmake[1]: Entering directory `/var/tmp/portage/mozilla-firefox-1.5.0.1-r3/work/mozilla/config' nsinstall.c i686-pc-linux-gnu-gcc -o host_nsinstall.o -c -march=athlon-xp -pipe -Wno-return-type -w -freorder-blocks -fno-reorder-functions -DXP_UNIX -O2 -I../dist/include -I../dist/include -I/usr/include/nspr -I../dist/sdk/include -I/usr/include/nspr nsinstall.c pathsub.c i686-pc-linux-gnu-gcc -o host_pathsub.o -c -march=athlon-xp -pipe -Wno-return-type -w -freorder-blocks -fno-reorder-functions -DXP_UNIX -O2 -I../dist/include -I../dist/include -I/usr/include/nspr -I../dist/sdk/include -I/usr/include/nspr pathsub.c rm -f nfspwd cp nfspwd.pl nfspwd chmod +x nfspwd rm -f revdepth cp revdepth.pl revdepth chmod +x revdepth /usr/bin/perl -I. ./bdate.pl build_number 1 i686-pc-linux-gnu-gcc -DOSTYPE=\"Linux2.6\" -DOSARCH=\"Linux\" -DBUILD_ID= -I../dist/include -I../dist/include -I/usr/include/nspr -I../dist/sdk/include -fPIC -DGENTOO_NSPLUGINS_DIR=\"/usr/lib/nsplugins\" -DGENTOO_NSBROWSER_PLUGINS_DIR=\"/usr/lib/nsbrowser/plugins\" -W -Wno-unused -Wpointer-arith -Wcast-align -Wno-long-long -march=athlon-xp -pipe -Wno-return-type -w -freorder-blocks -fno-reorder-functions -pthread -pipe -DNDEBUG -DTRIMMED -ffunction-sections -O2 -DGENTOO_NSPLUGINS_DIR=\"/usr/lib/nsplugins\" -DGENTOO_NSBROWSER_PLUGINS_DIR=\"/usr/lib/nsbrowser/plugins\" -include ../mozilla-config.h -DMOZILLA_CLIENT -I/usr/include/gtk-2.0 -I/usr/lib/gtk-2.0/include -I/usr/include/atk-1.0 -I/usr/include/cairo -I/usr/include/pango-1.0 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -o elf-dynstr-gc elf-dynstr-gc.c -Wl,-rpath,'$ORIGIN' -lgtk-x11-2.0 -lgdk-x11-2.0 -latk-1.0 -lgdk_pixbuf-2.0 -lm -lpangocairo-1.0 -lpango-1.0 -lcairo -lgobject-2.0 -lgmodule-2.0 -ldl -lglib-2.0 /usr/lib/gcc/i686-pc-linux-gnu/4.1.0/../../../../i686-pc-linux-gnu/bin/ld: warning: libexpat.so.0, needed by /usr/lib/libfontconfig.so.1, not found (try using -rpath or -rpath-link) /usr/lib/libfontconfig.so.1: undefined reference to `XML_SetElementHandler' /usr/lib/libfontconfig.so.1: undefined reference to `XML_SetDoctypeDeclHandler' /usr/lib/libfontconfig.so.1: undefined reference to `XML_ParserFree' /usr/lib/libfontconfig.so.1: undefined reference to `XML_SetCharacterDataHandler' /usr/lib/libfontconfig.so.1: undefined reference to `XML_ErrorString' /usr/lib/libfontconfig.so.1: undefined reference to `XML_ParseBuffer' /usr/lib/libfontconfig.so.1: undefined reference to `XML_ParserCreate' /usr/lib/libfontconfig.so.1: undefined reference to `XML_SetUserData' /usr/lib/libfontconfig.so.1: undefined reference to `XML_GetErrorCode' /usr/lib/libfontconfig.so.1: undefined reference to `XML_GetBuffer' /usr/lib/libfontconfig.so.1: undefined reference to `XML_GetCurrentLineNumber' collect2: ld returned 1 exit status gmake[1]: *** [elf-dynstr-gc] Error 1 gmake[1]: Leaving directory `/var/tmp/portage/mozilla-firefox-1.5.0.1-r3/work/mozilla/config' make: *** [default] Error 2 !!! ERROR: www-client/mozilla-firefox-1.5.0.1-r3 failed. Call stack: ebuild.sh, line 1526: Called dyn_compile ebuild.sh, line 923: Called src_compile mozilla-firefox-1.5.0.1-r3.ebuild, line 158: Called die !!! (no error message) !!! If you need support, post the topmost build error, and the call stack if relevant. 'emerge --info' Portage 2.1_pre7-r2 (default-linux/x86/2006.0, gcc-4.1.0, glibc-2.4-r1, 2.6.16-gentoo-r1 i686) ================================================================= System uname: 2.6.16-gentoo-r1 i686 AMD Athlon(tm) XP 2600+ Gentoo Base System version 1.12.0_pre16 ccache version 2.4 [enabled] dev-lang/python: 2.4.2-r1 sys-apps/sandbox: 1.2.17 sys-devel/autoconf: 2.13, 2.59-r7 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2 sys-devel/binutils: 2.16.1-r2 sys-devel/libtool: 1.5.22 virtual/os-headers: 2.6.11-r3 ACCEPT_KEYWORDS="x86 ~x86" AUTOCLEAN="yes" CBUILD="i686-pc-linux-gnu" CFLAGS="-march=athlon-xp -pipe -Os -fomit-frame-pointer" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3/share/config /usr/share/X11/xkb /usr/share/config /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/revdep-rebuild /etc/splash /etc/terminfo /etc/env.d" CXXFLAGS="-march=athlon-xp -pipe -Os -fomit-frame-pointer" DISTDIR="/usr/portage/distfiles" FEATURES="autoconfig ccache distlocks metadata-transfer sandbox sfperms strict" GENTOO_MIRRORS="http://trumpetti.atm.tut.fi/gentoo/ ftp://ftp.dtiltas.lt/mirror/gentoo/ http://pandemonium.tiscali.de/pub/gentoo/" LC_ALL="lt_LT.UTF-8" LINGUAS="lt" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="x86 3dnow 3dnowext X a52 aac aalib acpi alsa apm artworkextra asf audiofile avi bash-completion berkdb bitmap-fonts browserplugin bzip2 cairo cdb cdparanoia cdr chroot crypt curl dbus dri dv dvd dvdr dvdread eds emboss encode exif expat fam fat ffmpeg firefox flac foomaticdb fortran gd gdbm gif glut gnome gnutls gpm gstreamer gtk gtk2 gtkhtml hal howl idn imagemagick imlib irssi java javascript jpeg lame lcms libg++ libwww live logrotate mad matroska mikmod mjpeg mmx mmxext mng motif mozilla mp3 mpeg mplayer nautilus ncurses network nls nptl nptlonly nsplugin ntfs numeric nvidia offensive ogg oggvorbis openal opengl oss pam pdf pdflib perl pic png python quicktime readline real reiser4 reiserfs sdl shorten spell sqlite sse ssl symlink tcpd tiff truetype truetype-fonts type1-fonts udev unicode usb vcd vidix vorbis win32codecs wxwindows xchat xine xml xml2 xv xvid zlib elibc_glibc input_devices_keyboard input_devices_mouse kernel_linux linguas_lt userland_GNU video_cards_nvidia" Unset: ASFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, LANG, LDFLAGS, PORTDIR_OVERLAY
*** Bug 128071 has been marked as a duplicate of this bug. ***
*** Bug 128074 has been marked as a duplicate of this bug. ***
> /usr/lib/gcc/i686-pc-linux-gnu/4.1.0/../../../../i686-pc-linux-gnu/bin/ld: > warning: libexpat.so.0, needed by /usr/lib/libfontconfig.so.1, not found (try > using -rpath or -rpath-link) > /usr/lib/libfontconfig.so.1: undefined reference to `XML_SetElementHandler' > /usr/lib/libfontconfig.so.1: undefined reference to `XML_SetDoctypeDeclHandler' > /usr/lib/libfontconfig.so.1: undefined reference to `XML_ParserFree' > /usr/lib/libfontconfig.so.1: undefined reference to > `XML_SetCharacterDataHandler' > /usr/lib/libfontconfig.so.1: undefined reference to `XML_ErrorString' > /usr/lib/libfontconfig.so.1: undefined reference to `XML_ParseBuffer' > /usr/lib/libfontconfig.so.1: undefined reference to `XML_ParserCreate' > /usr/lib/libfontconfig.so.1: undefined reference to `XML_SetUserData' > /usr/lib/libfontconfig.so.1: undefined reference to `XML_GetErrorCode' > /usr/lib/libfontconfig.so.1: undefined reference to `XML_GetBuffer' > /usr/lib/libfontconfig.so.1: undefined reference to `XML_GetCurrentLineNumber' You didn't run revdep-rebuild after upgrading expat...
Everyone here - you need to run revdep-rebuild as noted in the expat ebuild. <snip> ewarn "Please note that the soname of the library changed!" ewarn "If you are upgrading from a previous version you need" ewarn "to fix dynamic linking inconsistencies by executing:" ewarn "revdep-rebuild --library libexpat.so.0" </snip>
*** Bug 128077 has been marked as a duplicate of this bug. ***
*** Bug 128113 has been marked as a duplicate of this bug. ***
*** Bug 128134 has been marked as a duplicate of this bug. ***
*** Bug 128060 has been marked as a duplicate of this bug. ***
*** Bug 128179 has been marked as a duplicate of this bug. ***
Ok, stupid question. Where do I get revdep-rebuild? [root@kronos / 231]% find . -name revdep\* ./etc/revdep-rebuild ..but that file is no help. I searched with emerge --search and searchdesc for revd and combinations but didn't find anything. Would appreciate any help!
emerge app-portage/gentoolkit for revdep-upgrade
As has been said elsewhere, the introduction of this upgrade requires me to recompile almost my entire system, including Xorg-x11 and KDE. What worries me even more is that both of these have just been upgraded in the past few days: Xorg-x11 to versie 7.0 and KDE to 3.5.2. Both of these are time-consuming (KDE) and/or complicated (Xorg-x11). At the very least, timing of this expat upgrade is bad. I will have to stay with expat 1.95.8 for as long as possible since upgrading is just a waste of resources now.
Hi, This is exactly my thinking, the only thing that made me go and re-emerge KDE-3.5.2 etc.,just day after it went out was because i use GCC-4.0.3(work wonderfully here). Sorry is this is a little bit OT. Rumen
*** Bug 128278 has been marked as a duplicate of this bug. ***
*** Bug 128285 has been marked as a duplicate of this bug. ***
*** Bug 128357 has been marked as a duplicate of this bug. ***
*** Bug 128406 has been marked as a duplicate of this bug. ***
*** Bug 132985 has been marked as a duplicate of this bug. ***
It is not actually simple, because Opera needs libexpat.so.0 too I resolved it buy making symlink libexpat.so.0 -> libexpat.so. Maybe ebuild should create this link too?
*** Bug 140783 has been marked as a duplicate of this bug. ***
*** Bug 142704 has been marked as a duplicate of this bug. ***
*** Bug 146873 has been marked as a duplicate of this bug. ***
(In reply to comment #19) > It is not actually simple, because Opera needs libexpat.so.0 too > > I resolved it buy making symlink libexpat.so.0 -> libexpat.so. Maybe ebuild > should create this link too? You can't just pretend that an ABI break didn't happen. While it may fortuitously work for a subset of functionality used by opera, it's wrong to do this.
*** Bug 149597 has been marked as a duplicate of this bug. ***
*** Bug 152302 has been marked as a duplicate of this bug. ***
*** Bug 154655 has been marked as a duplicate of this bug. ***
*** Bug 155458 has been marked as a duplicate of this bug. ***
*** Bug 157325 has been marked as a duplicate of this bug. ***
*** Bug 158065 has been marked as a duplicate of this bug. ***
There are tons of duplicate bug marks pointing here from bugs named "expat-2 should have new slot" but no one actually answered the issue (using common sense arguments (I mean other than "just because")): If upgrading expat 1.x to 2.x breaks ABI and requires recompilation of most of the desktop system, then why isn't it in the separate slot? Or maybe it should preserve the old libs just like openldap does? Why does OpenLDAP preserve old libs if it's a matter of revdep-rebuild to fix dependencies (this argument is raised against slotting expat)?
(In reply to comment #30) > the desktop system, then why isn't it in the separate slot? Kindly read all the comments above before commenting. There won't be any slot because it's _not_ safely slottable. Period. > preserve the old libs just like openldap does? Why does OpenLDAP preserve old > libs if it's a matter of revdep-rebuild to fix dependencies (this argument is > raised against slotting expat)? Because it's not safe here, stuff can continue to link against the old libexpat ABI. Again, read the backlog before posting yet another comment here.
*** Bug 167291 has been marked as a duplicate of this bug. ***
*** Bug 167301 has been marked as a duplicate of this bug. ***
*** Bug 175546 has been marked as a duplicate of this bug. ***
*** Bug 175946 has been marked as a duplicate of this bug. ***
*** Bug 178644 has been marked as a duplicate of this bug. ***
*** Bug 181486 has been marked as a duplicate of this bug. ***
*** Bug 181758 has been marked as a duplicate of this bug. ***
*** Bug 182131 has been marked as a duplicate of this bug. ***
*** Bug 188317 has been marked as a duplicate of this bug. ***
*** Bug 188319 has been marked as a duplicate of this bug. ***
*** Bug 188369 has been marked as a duplicate of this bug. ***
*** Bug 188472 has been marked as a duplicate of this bug. ***
*** Bug 188473 has been marked as a duplicate of this bug. ***
*** Bug 188531 has been marked as a duplicate of this bug. ***
*** Bug 188571 has been marked as a duplicate of this bug. ***
> Everyone here - you need to run revdep-rebuild as noted in the expat ebuild. I never saw the message. There's literally hundreds of reports due to this, so I think other's missed it also. Maybe it should be done automatically. There should at least be some sort of way to give the user a message after the entire emerge process has completed instead of at the end or middle of one of 30 ebuilds queued.
*** Bug 188677 has been marked as a duplicate of this bug. ***
*** Bug 188688 has been marked as a duplicate of this bug. ***
*** Bug 188701 has been marked as a duplicate of this bug. ***
"revdep-rebuild -X --library libexpat.so.0" as stated on the emerge did not work. I did not see this either, it was lost above 250 updated ebuilds. I had to do "revdep-rebuild -X" to pick up all changed libs, not only this but other libs were broken too (libexif etc). For future reference, if you are having problems, try "revdep-rebuild -X".
*** Bug 188815 has been marked as a duplicate of this bug. ***
My subversion[-1.3.2-r4] continued to be broken, "error while loading shared libraries: libexpat.so.0 [...]" at runtime, after multiple `revdep-rebuild -X`es. revdep-rebuild brought up libapr-1.2.8 a couple of times, but to no avail. Looking carefully at the output of a subversion re-build, it – because of apache2 usage – was building against apr-util-0.9.12(-r1), not apr-util-1.2.8. But revdep-rebuild wasn't picking up apr-util-0.9.12 ... just -1.2.8. I see another couple of subversion rebuild failures dup'ed against this bug, but subversion (re)built fine for me ... it was a runtime failure here. Manually re-emerging apr-util-0.9.12(-r1) resolved the subversion problem. :(
*** Bug 189506 has been marked as a duplicate of this bug. ***
*** Bug 189515 has been marked as a duplicate of this bug. ***
*** Bug 189585 has been marked as a duplicate of this bug. ***
(In reply to comment #31) > (In reply to comment #30) > > the desktop system, then why isn't it in the separate slot? > > Kindly read all the comments above before commenting. There won't be any slot > because it's _not_ safely slottable. Period. And no other options have been investigated, especially since this library is inside dependencies and typically only gets touched during something like "emerge -uD". > > > preserve the old libs just like openldap does? Why does OpenLDAP preserve old > > libs if it's a matter of revdep-rebuild to fix dependencies (this argument is > > raised against slotting expat)? > > Because it's not safe here, stuff can continue to link against the old libexpat > ABI. Again, read the backlog before posting yet another comment here. > I have read through this bugs comments, and didn't see that mentioned/discuss here.
(In reply to comment #48) > > Everyone here - you need to run revdep-rebuild as noted in the expat ebuild. > > I never saw the message. There's literally hundreds of reports due to this, so > I think other's missed it also. > > Maybe it should be done automatically. There should at least be some sort of > way to give the user a message after the entire emerge process has completed > instead of at the end or middle of one of 30 ebuilds queued. The problem is it's an "important" library (given the number of dependencies) and it caused hassles since 2006/06... >14months ago, and yes, it byte my too :( And yes, the problem is that I didn't installed it directly, but it got installed by some package deep in an update queue :( And no revdep-rebuild is not fixing everything (I appear to have a long time lingering gcc revdep problem that recompiles gcc everything :() and yes, it breaks systems in near totality... I'm fear for the day that login(1) or sshd starts using it... >
*** Bug 189642 has been marked as a duplicate of this bug. ***
*** Bug 189663 has been marked as a duplicate of this bug. ***
*** Bug 189700 has been marked as a duplicate of this bug. ***
On my system, revdep-rebuild just resulted in more build failures. Every package I tried to build would complain about missing libexpat.so.0. The only solution was to create a link: libexpat.so.0, pointing to libexpat.so Please re-open this because the solution does not work
*** Bug 189745 has been marked as a duplicate of this bug. ***
(In reply to comment #64) > On my system, revdep-rebuild just resulted in more build failures. Every > package I tried to build would complain about missing libexpat.so.0. The only > solution was to create a link: libexpat.so.0, pointing to libexpat.so > > Please re-open this because the solution does not work > It worked fine on my machine. What output did you get when doing revdep-rebuild -v -p ?
*** Bug 189923 has been marked as a duplicate of this bug. ***
(In reply to comment #4) > Everyone here - you need to run revdep-rebuild as noted in the expat ebuild. > > <snip> > ewarn "Please note that the soname of the library changed!" > ewarn "If you are upgrading from a previous version you need" > ewarn "to fix dynamic linking inconsistencies by executing:" > ewarn "revdep-rebuild --library libexpat.so.0" > </snip> > revdep-rebuild has solved my problem. the system update was successfull. thanks
*** Bug 189984 has been marked as a duplicate of this bug. ***
*** Bug 190088 has been marked as a duplicate of this bug. ***
*** Bug 190235 has been marked as a duplicate of this bug. ***
*** Bug 190897 has been marked as a duplicate of this bug. ***
*** Bug 191077 has been marked as a duplicate of this bug. ***
*** Bug 192615 has been marked as a duplicate of this bug. ***
emerge / revdep-rebuild still fails. not going to link the so.0 to the .so of expat-2.0 reopening bug. Tried: a) revdep-rebuild -X --library libexpat.so.0 didnt work. (qt-3.3.8 failed with missing file libexpat.so.0) b) same as a) but without distcc same result. c) skipping qt on the emerge from a) (emerge --resume --skipfirst), then retrying a) this apparently narrows down the list of broken packages but doesn't really solve the problem. (more successes after multiple runs, but some remain, like qt3) will try to find a workaround.
multiple runs of revdep-rebuild and subsequent emerge --resume --skipfirst seem to have "fixed" this.
*** Bug 195835 has been marked as a duplicate of this bug. ***
Not just a matter of running revdep-rebuild I'm afraid, this worked for many other programs but not for scilab! (please re-open)
*** Bug 197360 has been marked as a duplicate of this bug. ***
*** Bug 197377 has been marked as a duplicate of this bug. ***
*** Bug 197536 has been marked as a duplicate of this bug. ***
*** Bug 205634 has been marked as a duplicate of this bug. ***
*** Bug 206536 has been marked as a duplicate of this bug. ***
*** Bug 207145 has been marked as a duplicate of this bug. ***
(In reply to comment #86) > *** Bug 207145 has been marked as a duplicate of this bug. *** > (In reply to comment #86) > *** Bug 207145 has been marked as a duplicate of this bug. *** > All solutions given in this thread don't work. revdep-rebuild detect /usr/bin/xgettext (require libexpat.so.0) and fail when trying to compile gettext => there are no ebuilds to satisfy "=sys-devel/gettext-0.16.1" But, emerge -1 --nodeps gettext-0.17 fix the problem. If this bug come again, maybe they are an error somewhere ?
*** Bug 208837 has been marked as a duplicate of this bug. ***
*** Bug 209073 has been marked as a duplicate of this bug. ***
*** Bug 210737 has been marked as a duplicate of this bug. ***
*** Bug 212862 has been marked as a duplicate of this bug. ***
(In reply to comment #91) > *** Bug 212862 has been marked as a duplicate of this bug. *** > revdep-rebuild -X --library libexpat.so.0 does not work. Sys-apps/attr-2.4.39 has failed in the same way: #============================================== gmake[1]: warning: jobserver unavailable: using -j1. Add `+' to parent make rule. /usr/bin/xgettext --language=C --keyword=_ -o attr.pot ../attr/attr.c ../getfattr/getfattr.c ../setfattr/setfattr.c ../libattr/attr_copy_fd.c ../libattr/attr_copy_file.c /usr/bin/xgettext: error while loading shared libraries: libexpat.so.0: cannot open shared object file: No such file or directory gmake[1]: *** [attr.pot] Error 127 make: *** [default] Error 2 #============================================= It is known for almost year, I see, and not solved yet definitely?
(In reply to comment #92) > (In reply to comment #91) > > *** Bug 212862 has been marked as a duplicate of this bug. *** > > > revdep-rebuild -X --library libexpat.so.0 does not work. Sys-apps/attr-2.4.39 > has failed in the same way: > #============================================== > gmake[1]: warning: jobserver unavailable: using -j1. Add `+' to parent make > rule. > /usr/bin/xgettext --language=C --keyword=_ -o attr.pot ../attr/attr.c > ../getfattr/getfattr.c ../setfattr/setfattr.c ../libattr/attr_copy_fd.c > ../libattr/attr_copy_file.c > /usr/bin/xgettext: error while loading shared libraries: libexpat.so.0: cannot > open shared object file: No such file or directory > gmake[1]: *** [attr.pot] Error 127 > make: *** [default] Error 2 > #============================================= > It is known for almost year, I see, and not solved yet definitely? > The problem was with USE flag "acl", for te first time in stage1 it is better not to use it to fulfil emerge -e system. because sys-devel/gettext-0.17 with acl requires sys-apps/acl-2.2.45 and acl requires sys-apps/attr-2.4.39, but unfortunately sys-apps/attr-2.4.39, requires sys-devel/gettext-0.17. So we need first emerge sys-devel/gettext-0.17 without acl USE flag.
*** Bug 213045 has been marked as a duplicate of this bug. ***
*** Bug 213481 has been marked as a duplicate of this bug. ***
*** Bug 218702 has been marked as a duplicate of this bug. ***
*** Bug 219555 has been marked as a duplicate of this bug. ***
