Background: I had the xcb use flag off but because java did not work with it here I switched it off and recompiled libX11 and mesa so nothing was using xcb any more at least use flag wise: pena eclass # USE="-xcb" emerge -uDNpvt world | grep xcb pena eclass # Updating kate I got: creating libkateutils_la.all_cpp.cpp ... /bin/sh ../../libtool --silent --tag=CXX --mode=compile i686-pc-linux-gnu-g++ -DHAVE_CONFIG_H -I. -I. -I../.. -I../../kate/utils -I/usr/kde/3.5/include -I/usr/qt/3/include -I. -DQT_THREAD_SUPPORT -D_REENTRANT -Wno-long-long -Wundef -ansi -D_XOPEN_SOURCE=500 -D_BSD_SOURCE -Wcast-align -Wconversion -Wchar-subscripts -Wall -W -Wpointer-arith -DNDEBUG -DNO_DEBUG -O2 -O2 -march=nocona -pipe -Wformat-security -Wmissing-format-attribute -Wno-non-virtual-dtor -fno-exceptions -fno-check-new -fno-common -fvisibility=hidden -fvisibility-inlines-hidden -DQT_CLEAN_NAMESPACE -DQT_NO_ASCII_CAST -DQT_NO_STL -DQT_NO_COMPAT -DQT_NO_TRANSLATION -c -o libkateutils_la.all_cpp.lo libkateutils_la.all_cpp.cpp /bin/sh ../../libtool --silent --tag=CXX --mode=link i686-pc-linux-gnu-g++ -Wno-long-long -Wundef -ansi -D_XOPEN_SOURCE=500 -D_BSD_SOURCE -Wcast-align -Wconversion -Wchar-subscripts -Wall -W -Wpointer-arith -DNDEBUG -DNO_DEBUG -O2 -O2 -march=nocona -pipe -Wformat-security -Wmissing-format-attribute -Wno-non-virtual-dtor -fno-exceptions -fno-check-new -fno-common -fvisibility=hidden -fvisibility-inlines-hidden -DQT_CLEAN_NAMESPACE -DQT_NO_ASCII_CAST -DQT_NO_STL -DQT_NO_COMPAT -DQT_NO_TRANSLATION -Wl,--as-needed -o libkateutils.la -rpath /usr/kde/3.5/lib -L/usr/kde/3.5/lib -L/usr/qt/3/lib -L/usr/lib -no-undefined -Wl,--no-undefined -Wl,--allow-shlib-undefined libkateutils_la.all_cpp.lo -lkdeui -lkdecore -lkio grep: /usr/lib/libxcb-xlib.la: No such file or directory /bin/sed: can't read /usr/lib/libxcb-xlib.la: No such file or directory libtool: link: `/usr/lib/libxcb-xlib.la' is not a valid libtool archive make[3]: *** [libkateutils.la] Error 1 make[3]: Leaving directory `/var/tmp/portage/kde-base/kate-3.5.5-r1/work/kate-3.5.5/kate/utils' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/var/tmp/portage/kde-base/kate-3.5.5-r1/work/kate-3.5.5/kate' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/var/tmp/portage/kde-base/kate-3.5.5-r1/work/kate-3.5.5' make: *** [all] Error 2 !!! ERROR: kde-base/kate-3.5.5-r1 failed. Call stack: ebuild.sh, line 1580: Called dyn_compile ebuild.sh, line 945: Called src_compile ebuild.sh, line 1269: Called kde-meta_src_compile kde-meta.eclass, line 379: Called kde_src_compile kde.eclass, line 169: Called kde_src_compile 'all' kde.eclass, line 339: Called kde_src_compile 'myconf' 'configure' 'make' kde.eclass, line 335: Called die !!! died running emake, kde_src_compile:make !!! If you need support, post the topmost build error, and the call stack if relevant. running revdep-rebuild: Calculating dependencies... done! [ebuild R ] x11-libs/libXrender-0.9.2 USE="-debug" 0 kB [ebuild R ] x11-libs/libXext-1.0.2 USE="-debug" 0 kB [ebuild R ] x11-libs/libXtst-1.0.1 USE="-debug" 0 kB [ebuild R ] x11-libs/libXfixes-4.0.3 USE="-debug" 0 kB [ebuild R ] x11-libs/libXcursor-1.1.8 USE="-debug" 0 kB [ebuild R ] x11-libs/libXt-1.0.4 USE="-debug" 0 kB [ebuild R ] x11-libs/libXmu-1.0.3 USE="-debug -ipv6" 0 kB [ebuild R ] x11-libs/libXres-1.0.2 USE="-debug" 0 kB [ebuild R ] x11-libs/libXdamage-1.0.4 USE="-debug" 0 kB [ebuild R ] x11-libs/libXinerama-1.0.1 USE="-debug" 0 kB [ebuild R ] x11-libs/libXxf86vm-1.0.1 USE="-debug" 0 kB [ebuild R ] x11-libs/libXi-1.1.0 USE="-debug" 0 kB [ebuild R ] x11-libs/libXp-1.0.0 USE="-debug" 0 kB [ebuild R ] x11-libs/libXrandr-1.1.2 USE="-debug" 0 kB [ebuild R ] x11-libs/libXcomposite-0.3.1 USE="-debug" 0 kB [ebuild R ] x11-libs/startup-notification-0.8 0 kB [ebuild R ] x11-libs/libXft-2.1.12 USE="-debug" 0 kB [ebuild R ] media-libs/glitz-0.5.6 0 kB <snip> All because of: <snip> broken /usr/lib/libXrandr.la (requires /usr/lib/libxcb-xlib.la) broken /usr/lib/libXrandr.la (requires /usr/lib/libxcb.la) broken /usr/lib/libXrender.la (requires /usr/lib/libxcb-xlib.la) broken /usr/lib/libXrender.la (requires /usr/lib/libxcb.la) broken /usr/lib/libXRes.la (requires /usr/lib/libxcb-xlib.la) broken /usr/lib/libXRes.la (requires /usr/lib/libxcb.la) broken /usr/lib/libXt.la (requires /usr/lib/libxcb-xlib.la) broken /usr/lib/libXt.la (requires /usr/lib/libxcb.la) broken /usr/lib/libXtst.la (requires /usr/lib/libxcb-xlib.la) </snip> So the libxcb ebuild should info the you need to run revdep-rebuild when unmerging the ebuild and most likely switching on the xcb use flag requires a lot of rebuilding. Should try if emerge -e world after turning on the xcb use flag makes things work. pena betelgeuse # emerge --info Portage 2.1.2_rc3-r6 (default-linux/x86/2006.1/desktop, gcc-4.1.1, glibc-2.5-r0, 2.6.19-gentoo-r2 i686) ================================================================= System uname: 2.6.19-gentoo-r2 i686 Intel(R) Core(TM)2 CPU 6600 @ 2.40GHz Gentoo Base System version 1.13.0_alpha9 Last Sync: Unknown distcc 2.18.3 i686-pc-linux-gnu (protocols 1 and 2) (default port 3632) [disabled] ccache version 2.4 [enabled] dev-java/java-config: 1.3.7, 2.0.31 dev-lang/python: 2.4.4, 2.5-r1 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.17 sys-devel/gcc-config: 1.3.14 sys-devel/libtool: 1.5.22 virtual/os-headers: 2.6.17-r2 ACCEPT_KEYWORDS="x86 ~x86" AUTOCLEAN="yes" CBUILD="i686-pc-linux-gnu" CFLAGS="-O2 -march=nocona -pipe" CHOST="i686-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/splash /etc/terminfo" CXXFLAGS="-O2 -march=nocona -pipe" DISTDIR="/var/distfiles" FEATURES="autoaddcvs autoconfig ccache collision-protect cvs distlocks fixpackages java-strict parallel-fetch sandbox sfperms sign strict stricter userpriv usersandbox verify-rdepend" GENTOO_MIRRORS=" http://trumpetti.atm.tut.fi/gentoo http://lame.lut.fi/linux/gentoo " LANG="en_US.utf8" LC_ALL="en_US.utf8" LDFLAGS="-Wl,--as-needed" LINGUAS="fi" MAKEOPTS="-j2" PKGDIR="/home/pkg/" 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" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/mnt/checkouts/overlays/migrated-java" SYNC="rsync://192.168.150.1:/portage" USE="x86 aac acl acpi alsa alsa_cards_cs46xx alsa_cards_hda-intel arts audiofile bash-completion berkdb bitmap-fonts bluetooth bzip2 cairo cdb cddb cdparanoia cdr cli cracklib crypt cups dbus dlloader dri dts dvd dvdr dvdread elibc_glibc emboss esd fam ffmpeg firefox gif gstreamer hal iconv input_devices_evdev input_devices_keyboard input_devices_mouse isdnlog java jpeg kde kdeenablefinal kdehiddenvisibility kernel_linux libg++ linguas_fi logitech-mouse mad mikmod mjpeg mmx mp3 mpeg ncurses network nptl nptlonly nsplugin nvidia offensive ogg opengl pam pcre png ppds pppd qt3 quicktime readline real reflection rtc samba session spell spl sse sse2 ssl subversion svg symlink theora threads truetype truetype-fonts type1-fonts udev unicode usb userland_GNU userlocales video_cards_none video_cards_nvidia vim-syntax vorbis xcomposite xinerama xml xorg xv xvid xvmc zlib" Unset: CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, PORTAGE_RSYNC_EXTRA_OPTS
Hmm, Donnie, what do you think? Static linking is icky.
(In reply to comment #1) > Hmm, Donnie, what do you think? > > Static linking is icky. > Yeah I think we should move towards using dynamic linking more.
I'm not sure why libtool is adding libxcb-xlib into the .la files. It should only show up in the .la for libX11, so if that disappears, everything still works. For some reason all these other packages seem to be pulling it in.
This is not a kde bug. If you make any progress that requires any changes to kde packages, cc us again.
*** Bug 199893 has been marked as a duplicate of this bug. ***
*** Bug 200648 has been marked as a duplicate of this bug. ***
I hope Diego won't mind pasting a part of his email here so that we can move on... <snip> Easy way? Remove libxcb.la from being installed by the libxcb ebuild. Easy breezy, the nightmare is solved. The usefulness of .la files stops at two points: - module loading, as used by KDE and by PulseAudio, with libltdl; - non-ELF operating systems which can't declare library dependencies; - static linking; As we're only targeting sane platforms with Gentoo (Linux, *BSD, Solaris all use ELF, OSX uses Mach-O which does have library dependencies, Windows PE iirc has too), we don't strictly need the .la files; and for what concerns static linking, pkg-config --static --libs xcb provides the information already. </snip>
That's technically correct, but it feels like a hack to not install this .la file but continue installing every other one.
If it was for me we could be removing .la files by default and just keeping the ones needed for module loading. Unfortunately that _might_ break with static linking, so I'd rather avoid it an decide on a case-by-case. libxcb is safe for static linking because of pkg-config, other packages using pkg-config might be safe too.
(In reply to comment #9) > If it was for me we could be removing .la files by default and just keeping the > ones needed for module loading. Unfortunately that _might_ break with static > linking, so I'd rather avoid it an decide on a case-by-case. libxcb is safe for > static linking because of pkg-config, other packages using pkg-config might be > safe too. Sort of. Except not every package out there knows about pkg-config, so any X-based package that doesn't use pkg-config and wants to statically link will fail.
I would certainly like to see whatever tries to link to X11 statically in portage, to use a clue-by-four on it ;) On the other hand, don't expect stuff linking statically to X11 to use libtool either, so the problem is there already.
(In reply to comment #11) > I would certainly like to see whatever tries to link to X11 statically in > portage, to use a clue-by-four on it ;) Anyone building embedded systems with X apps might be interested. > On the other hand, don't expect stuff linking statically to X11 to use libtool > either, so the problem is there already. Sure, but we'd be making it even harder and creating a regression. Anything autotools-based will work now, but this would add the additional requirement that it use pkg-config macros. I haven't seen evidence that pkg-config is nearly ubiquitous in common applications as libtool is, but I could be convinced of it. That would be enough justification for me to say this would be a good idea. On a more general level, we would have to do something like check revdeps of a given pkgconfig-using package to see whether we have to install a .la file or just the .pc.
Since it plagues me right now, I'd like to second Donnie's idea. I've got .la's with xcb-xlib spilled all over the system - and now its gone (x11 overlay)! Practically all build fail. A revdep-rebuild that somehow checked the .la's would be exactly the tool I need ATM.
*** Bug 245889 has been marked as a duplicate of this bug. ***
This is going to bite us one day or another. FTR, here's the oneliner I've used to "fix" my .la files : find /usr/lib -name "*.la" -exec sed -e "s:-lxcb-xlib:: ; s:/usr/lib/libxcb-xlib.la::" -i \{\} \; Oh and cairo injects glitz everywhere too, but that's my own damn fault as I shouldn't have put USE=glitz in the first place ;)
*** Bug 255013 has been marked as a duplicate of this bug. ***
I just did my daily "emerge -uDN world" and encounter this error. I'm not sure exactly what caused the problem, but regardless, I'm experiencing it. Almost any package I emerge errors out like so (this is from x11-libs/libX11-1.1.5): checking for X11... configure: error: Package requirements (xextproto xtrans xcb-xlib >= 0.9.92) were not met: No package 'xcb-xlib' found I tried the one-liner from comment #15 (adjusting lib to lib64, because I'm on amd64) and was shown no love. What can I do (besides removing the "xcb" use flag) to fix my system?
If you're using libxcb-9999, you'll need libX11-9999 as well. Thanks
*** Bug 262338 has been marked as a duplicate of this bug. ***
Here's everything I did to recover from this: find /usr/lib -name "*.la" -exec sed -e "s:-lxcb-xlib:: ; s:/usr/lib64/libxcb-xlib.la::" -i \{\} \; and find /usr/kde/3.5/lib64 -name "*.la" -exec sed -e "s:-lxcb-xlib:: ; s:/usr/lib64/libxcb-xlib.la::" -i \{\} \; After doing rm -rf /usr/lib/libxcb-xlib*, revdep-rebuild finds everything still depending on the so file, but not much else (I don't know why). I had to manually remove everything found by revdep-rebuild depending on /usr/lib/libxcb-xlib.so and then let revdep-rebuild fix the new non-libxcb-xlib.so dependencies it found, which it mostly did by itself. It could have just been one package affecting the rest, but I didn't know how to find it.
the xcb-rebuild.sh tool in the x11 overlay will rewrite all .la files installed by portage (it gets a full list using "qlist") instead of just looking in a predefined list. I consider this particular aspect of the xcb upgrade solved. Thanks
(In reply to comment #21) > the xcb-rebuild.sh tool in the x11 overlay will rewrite all .la files installed > by portage (it gets a full list using "qlist") instead of just looking in a > predefined list. > > I consider this particular aspect of the xcb upgrade solved. > > Thanks > In what package in the x11 overlay is this tool? I could not find it?
(In reply to comment #22) > In what package in the x11 overlay is this tool? I could not find it? It's in portage now, head over to http://www.gentoo.org/proj/en/desktop/x/x11/libxcb-1.4-upgrade-guide.xml to find out more. All the instructions are now properly written down in this guide. Thanks
(In reply to comment #23) > (In reply to comment #22) > > In what package in the x11 overlay is this tool? I could not find it? > > It's in portage now, head over to > http://www.gentoo.org/proj/en/desktop/x/x11/libxcb-1.4-upgrade-guide.xml to > find out more. > > All the instructions are now properly written down in this guide. Except that # emerge -1 x11-proto/xproto x11-proto/xextproto x11-libs/libX11 x11-libs/libXext stopped at x11-libs/libX11 for me with the same error. But thanks to all the helpful comments here, I figured I had to unmask a newer version of libX11 to match libxcb's. Then the rest went smooth. I think the -pv on that one liner might fool n00bs in thinking it actually did something. -av would have been easier for them. :P > > Thanks >
(In reply to comment #23) > (In reply to comment #22) > > In what package in the x11 overlay is this tool? I could not find it? > > It's in portage now, head over to > http://www.gentoo.org/proj/en/desktop/x/x11/libxcb-1.4-upgrade-guide.xml to > find out more. > > All the instructions are now properly written down in this guide. > > Thanks > No. Gnome and many other ebuilds require inexistent /usr/lib64/libxcb-xlib.la and /usr/lib64/libGL.la. I've follow the instructions contained in the pages found with Google, but I can't install Gnome. I continue to search a solution, but right now I have given up hope of installing Gnome. :-((( P.S. I remember that in September theese ebeuilds existed. I copied them (from a backup), but they don't work.
(In reply to comment #25) > No. Yes. > Gnome and many other ebuilds require inexistent /usr/lib64/libxcb-xlib.la and > /usr/lib64/libGL.la. > I've follow the instructions contained in the pages found with Google, but I > can't install Gnome. I continue to search a solution, but right now I have > given up hope of installing Gnome. :-((( Then you haven't followed _all_ the steps. Read them again, it _works_. Hundreds of users have tried them successfully. > P.S. I remember that in September theese ebeuilds existed. I copied them (from > a backup), but they don't work. Don't use them, you'll break your system even more. Cheers
