I enabled the xcb USE flag and after that emerges began to fail. Here is an example of this failure in gtk+: /bin/sh ../libtool --mode=link x86_64-pc-linux-gnu-gcc -DG_DISABLE_DEPRECATED -march=athlon64 -O2 -pipe -Wall -o libgdk-x11-2.0.la -version-info 1000:9:1000 -export-dynamic -rpath /usr/lib64 -export-symbols-regex "^[^_].*" gdk.lo gdkcairo.lo gdkcolor.lo gdkcursor.lo gdkdisplay.lo gdkdnd.lo gdkdraw.lo gdkevents.lo gdkfont.lo gdkgc.lo gdkglobals.lo gdkkeys.lo gdkkeyuni.lo gdkimage.lo gdkdisplaymanager.lo gdkpango.lo gdkpixbuf-drawable.lo gdkpixbuf-render.lo gdkpixmap.lo gdkpolyreg-generic.lo gdkrgb.lo gdkrectangle.lo gdkregion-generic.lo gdkscreen.lo gdkselection.lo gdkvisual.lo gdkwindow.lo gdkenumtypes.lo x11/libgdk-x11.la -lpangocairo-1.0 -lpango-1.0 -lcairo -lgobject-2.0 -lgmodule-2.0 -ldl -lglib-2.0 -lfontconfig -lXext -lXrender -lX11 -lXinerama -lXi -lXrandr -lXcursor -lXfixes -lm ../gdk-pixbuf/libgdk_pixbuf-2.0.la grep: /usr/lib64/libXCBRenderUtil.la: No such file or directory /bin/sed: can't read /usr/lib64/libXCBRenderUtil.la: No such file or directory libtool: link: `/usr/lib64/libXCBRenderUtil.la' is not a valid libtool archive make[2]: *** [libgdk-x11-2.0.la] Error 1 make[2]: Leaving directory `/var/tmp/portage/x11-libs/gtk+-2.10.9/work/gtk+-2.10.9/gdk' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/var/tmp/portage/x11-libs/gtk+-2.10.9/work/gtk+-2.10.9/gdk' make: *** [all] Error 2 I modified the ../libtool to add "set -x" and noticed that, while building a list of all of the "xcb" libs, this is the only lib where it is using it's old (v0.1) name instead of the correct lib name "libxcb-render-util.la", all of the other xcb libs were referred to correctly. I have not yet traced down where it's pulling this name from. Here is my emerge info: As you can see, I have even removed the xcb flag. This same failure occurs even after unmerging all of the xcb packages (I also tried merging them all). revdep-rebuild fails with the same problem. I have attempted "emerge -uDNv world", "emerge -uDNv system" and even "emerge -euDNv world" to no avail. Note that I have >=libtool-1.5.23 masked due to problems with SED not being defined in 1.5.23b. Reproducible: Always Steps to Reproduce: I'm afraid I couldn't detail this very well. The description contains my emerge --info. I have gone through a few iterations of rebuilding things at this point and I'm still a bit green around the edges, so I can't promise 100% that I could reproduce this problem if I created a new Gentoo from scratch. I will note, however, that I booted from a 2006.0 CD and that I also started with a 2006.0 stage3. Actual Results: see output from description Expected Results: I expected it to successfully merge the packages # emerge --info Portage 2.1.2.1 (default-linux/amd64/2006.0, gcc-4.1.2, glibc-2.5-r0, 2.6.20-gentoo x86_64) ================================================================= System uname: 2.6.20-gentoo x86_64 AMD Athlon(tm) 64 X2 Dual Core Processor 4200+ Gentoo Base System release 1.12.9 Timestamp of tree: Mon, 05 Mar 2007 04:20:01 +0000 ccache version 2.4 [enabled] dev-java/java-config: 1.3.7, 2.0.31-r3 dev-lang/python: 2.4.4 dev-python/pycrypto: 2.0.1-r5 dev-util/ccache: 2.4-r6 sys-apps/sandbox: 1.2.18.1 sys-devel/autoconf: 2.13, 2.61 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2, 1.10 sys-devel/binutils: 2.16.1, 2.17 sys-devel/gcc-config: 1.3.14 sys-devel/libtool: 1.5.22 virtual/os-headers: 2.6.20-r1 ACCEPT_KEYWORDS="amd64 ~amd64" AUTOCLEAN="yes" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-march=athlon64 -O2 -msse3 -pipe" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/3.5/env /usr/kde/3.5/share/config /usr/kde/3.5/shutdown /usr/share/X11/xkb /usr/share/config" CONFIG_PROTECT_MASK="/etc/env.d /etc/env.d/java/ /etc/gconf /etc/java-config/vms/ /etc/revdep-rebuild /etc/terminfo /etc/texmf/web2c" CXXFLAGS="-march=athlon64 -O2 -msse3 -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="autoconfig ccache distlocks metadata-transfer sandbox sfperms strict" GENTOO_MIRRORS="http://gentoo.osuosl.org/ ftp://distro.ibiblio.org/pub/linux/distributions/gentoo/ http://distro.ibiblio.org/pub/linux/distributions/gentoo/ ftp://ftp.gtlib.gatech.edu/pub/gentoo http://www.gtlib.gatech.edu/pub/gentoo ftp://mirror.iawnet.sandia.gov/pub/gentoo/ ftp://ftp.ucsb.edu/pub/mirrors/linux/gentoo/ http://gentoo.chem.wisc.edu/gentoo/ ftp://gentoo.chem.wisc.edu/gentoo/ http://cudlug.cudenver.edu/gentoo/ http://gentoo.mirrors.pair.com/ ftp://gentoo.mirrors.pair.com/ http://gentoo.mirrors.tds.net/gentoo ftp://gentoo.mirrors.tds.net/gentoo http://mirror.datapipe.net/gentoo ftp://mirror.datapipe.net/gentoo http://mirror.usu.edu/mirrors/gentoo/ ftp://mirror.usu.edu/mirrors/gentoo/ http://mirror.phy.olemiss.edu/mirror/gentoo http://mirror.mcs.anl.gov/pub/gentoo/ ftp://mirror.mcs.anl.gov/pub/gentoo/ " MAKEOPTS="-j4" PKGDIR="/usr/portage/packages" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --delete-after --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages --filter=H_**/files/digest-*" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://rsync.namerica.gentoo.org/gentoo-portage" USE="X a52 aac aalib acpi aim akode alsa amd64 amr apache apache2 apm arts audiofile autoipd bash-completion berkdb bitmap-fonts bonjour bzip2 calendar caps cdr cg cgi cli console cpudetection cracklib crypt cups curl curlwrappers directfb dmx dri dts dvd dvdr dvdread dxr3 emboss encode esd exif fbcon fftw firefox flac fontconfig foomaticdb fortran ftp fuse fusion gcj gdb gdbm gif glitz gmp gnome gnutls gphoto2 gpm graphviz gstreamer gtk gtk2 hal hibernate iconv icq ieee1394 imagemagick imap imlib insecure-savers ipv6 isdnlog jack java javascript jbig jikes jingle jpeg jpeg2k kde kdeenablefinal kdexdeltas kdrive kerberos keyring ldap libcaca libg++ libwww lirc lm_sensors logitech-mouse lzw lzw-tiff mad md5sum meanwhile midi mime ming mmap mng modperl modplug motif mozbranding mozilla mp3 mpeg msn mudflap multislot musepack mysql mysqli nas ncurses netjack nls nntp nptl nptlonly nsplugin ogg openal openexr opengl pam pcntl pcre pdf perl php png portaudio posix pppd pulseaudio python qq qt qt3 qt4 quicktime readline reflection rrdcgi sametime sasl sdl sensord session sharedext sharedmem silc smtp sndfile soap sockets source speex spell spl sqlite sse3 ssl startup-notification svg sysfs sysvipc tcl tcpd theora threads tidy tiff tk tokenizer truetype truetype-fonts type1-fonts unicode urandom usb userlocales v4l v4l2 vcd vhosts videos vorbis vorbis-psy wavpack wifi wmf wxwindows x264 xface xine xinerama xml xmlreader xmlwriter xorg xpm xprint xscreensaver xsl xv xvid xvmc yahoo zip zlib" 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" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mulaw multi null plug rate route share shm softvol" ELIBC="glibc" INPUT_DEVICES="keyboard mouse joystick" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" USERLAND="GNU" VIDEO_CARDS="nvidia" Unset: CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LANG, LC_ALL, LDFLAGS, LINGUAS, PORTAGE_RSYNC_EXTRA_OPTS
Also, this is the directory that was being made when the failure occurred: /var/tmp/portage/x11-libs/gtk+-2.10.9/work/gtk+-2.10.9/gdk
Created attachment 112245 [details] libxxx.la files with anachronistic lib reference
More Info: I examined the set -x output from libtool better and discovered that the reference to libXCBRenderUtil.la was coming from sourcing /usr/lib64/libpangocairo-1.0.la. I searched for all of the .la files that had this reference and this is the list: /usr/lib64# grep -l libXCBRenderUtil * libbonoboui-2.la libglade-2.0.la libgnomecanvas-2.la libgnomeui-2.la libgtkgl-2.0.la libgtkspell.la libpangocairo-1.0.la libpoppler-glib.la I'm going to unmerge these packages to attempt to solve my problem. None the less, I suspect that this is still a bug. I'm attaching a copy of these files for investigation.
Crap, this may be a dupe of #169521, but at least I have more info in this report. As with #169521, revdep-rebuild did not solve the problem. Would the true problem then lie in revdep-rebuild failing to properly resolve this issue (without making a futile attempt to recompile the packages that are broken by the original problem anyway?)
Also of note, I tried revdep-rebuild --library "libXCBRenderUtil.*" and this also failed in the exact same way. To solve my problem, I've unmerged everything with this reference (except for gcc and python) and I'm rebuilding them.
Yeah, I know this sucks, but nothing we could do about it, sorry. *** This bug has been marked as a duplicate of bug 169521 ***
(In reply to comment #6) > Yeah, I know this sucks, but nothing we could do about it, sorry. > > *** This bug has been marked as a duplicate of bug 169521 *** > I'm willing to wager that it can be addressed in revdep-rebuild.
*** Bug 169624 has been marked as a duplicate of this bug. ***
Recycling this bug.
@x11 folks: - the postinstall instructions are wrong, running revdep-rebuild without any options plain fails - plus what's this hardcoded crap in .la files all over the place (noticed in Bug 158476 already)?
(In reply to comment #10) > - the postinstall instructions are wrong, running revdep-rebuild without any > options plain fails It fixed the problem for my system, so it doesn't fail for everyone. I'm open for better suggestions. > - plus what's this hardcoded crap in .la files all over the place (noticed in > Bug 158476 already)? Let me know if you find out. It doesn't make much sense to me either.
I found a workaround : first re-emerge pango and after run revdep-rebuild. It seems to work, but revdep-rebuild isn't finished.
> - plus what's this hardcoded crap in .la files all over the place (noticed in > Bug 158476 already)? Forgive my noob-ness, but are the .la files a shortcut mechanism for libtool so it doesn't have to scrape through the .so files to figure out what their dependencies are? It would seem to me that the purpose of revdep-rebuild is to correct dependency problems that occur after some package is removed (or in the case of xcb, updated where the names of it's libs changed). So if libtool will enumerate through the stated dependencies in the .la files and then fail, it would seem that this problem lies within the territory of revdep-rebuild. This most immediate solution that comes to mind involves: * create a lock file (to make sure that only one revdep-rebuild happens at once) * trap SIGINT & SIGTERM (any others?) * making backups of the .la files in the "broken deps" list (perhaps to the same dir with .la-revdep-<timestamp> appended? ) * remove the broken dependencies from the .la files to prevent libtool from failing during the build. * for each package: * emerge * upon success, enumerate through all of the .la files in the "broken" list that belong to this package remove the .la backup. This presumes that, upon a successful rebuild we now have a good .la file. Then, if we get SIGINT or SIGTERM, we clean up by replacing the original .la files with their backup. There should probably be a mechanism for revdep-rebuild to look for backup files that were left by a previous run that was somehow killed more violently (and replace those .la files). This is just an off-the-top-of-my-head and I don't know the script at all. Daniel
(In reply to comment #12) > I found a workaround : first re-emerge pango and after run revdep-rebuild. It > seems to work, but revdep-rebuild isn't finished. This may work in your particular instance, but dependency problems can manifest in several different ways. Personally, I had to unmerge all of the packages I could, but I still had broken deps in gcc and python. So I manually removed the broken references from those .la files so that I was able to do all of my rebuilds without libtool failing.
(In reply to comment #13) > > - plus what's this hardcoded crap in .la files all over the place (noticed in > > Bug 158476 already)? > > Forgive my noob-ness, but are the .la files a shortcut mechanism for libtool so > it doesn't have to scrape through the .so files to figure out what their > dependencies are? As noted on Bug 158476 Comment #3, this shouldn't end up scattered across loads of .la files (see Comment #2 in this bug), should be just in one place where it belongs... (Honestly this xcb thing is still too much unstable for my taste, I guess people should avoid it until it's more mature and doesn't change all the time.)
*** Bug 169521 has been marked as a duplicate of this bug. ***
revdep-rebuild in gentoolkit-0.2.4_pre1 should provide better ordering and prevent this issue from occuring.
Per comment #17 please test =app-portage/gentoolkit-0.2.4_rc3. Also, is this bug really specific to AMD64?
