Bugzilla Bug 128069

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 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 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 189663 has been marked as a duplicate of this bug. ***

*** 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 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. ***