I’ve been working as an experiment on rewriting
xclip to use XCB rather than Xlib. This is mostly because I always have been interested in XCB but I never had time to learn the internals too much.
To make my task easier I ended up using some funcitons that are not available in the currently-released version of xcb-util, the side-package of XCB that contains some higher-level functions that make it easier to replace Xlib.
Beside the fact that xcb-util still haven’t bumped its version, which makes it impossible to check for the right version with pkg-config, there is one interesting point in using the latest available version through the x11 overlay.
Letting alone some problems with being able to actually fetch and install the packages I need (Donnie, I’ll send you the patches later if I can polish them a bit), over the actual GIT tree there are a few patches applied, coming from Jamey Sharp (an XCB developer) from March 2008. These remove one library (libxcb-xlib) and change the locking method used to make Xlib use the same socket as XCB. These changes not only break ABI (without changing the soname, alas!) but also make it impossible to build the old libX11 against the new libxcb. Using the live version of libX11 (that is also patched to use the new hand-out mechanism) fixes this problem, but the result is a way bigger trouble.
First of all, this is a perfectly good example of what I said about preserve-libs. If you are not using
--as-needed, and you had libX11 built with xcb USE flag enabled, you’ll have libxcb.so.1 links on almost all X-using binaries in your system; after rebuilding the new libxcb and libX11 (which respectively would install libxcb.so.2, in theory, and let libX11 link to that), all the binaries will have in their process space both the old and the new libxcb. With different ABIs. And that’s a huge problem on itself.
Then there is the other problem, that is related to the .la files I discussed a few months back. As a huge amount of KDE modules (and not limited to) linked to Xlib, they also had libxcb-xlib listed in their .la files dependencies. Which causes everything to fail linking with libtool as it’s looking for the missing
I suppose it’s time to spend time to get a script to fix this situation, but I admit I’m not much motivated at the moment. Especially since my system is pretty slow when it comes to rebuild stuff for testing, and my employer is not going to pay me anytime soon to allow me getting a newer box.
Once the script is available, it should probably be much much easier to get rid of .la files in ebuilds, as we could just say to the users to run the fixing script and be done with that..
But I admit I was planning on doing some different things in the next days, I had little time for myself lately to begin with, and I’m following way too many things at once. Sigh.This work by Diego Elio Pettenò is licensed under Creative Commons Attribution-ShareAlike 3.0 Unported License.
Based on a work at flameeyes.blog.
you may want to look into thishttp://git.naquadah.org/?p=…
i’ve found a good and interesting way of getting rid of the xcb failures. first of all try rebuilding the packages you need to rebuild and a whole bunch of them will build in the correct way. the packages that fail need to be manually uninstalled, then reinstalled after removing their remnants by hand. this time pkg-config and libtool will work in the right way and find out that they really don’t need the la files. if they still need it (there are 2 or 3 packages that still need them) then the problem is that these packages build static shared libs. so just remove the static shared and make them to be dinamically linked (i still don’t understand why a system as gentoo doesn’t still take into consideration the full removal of static shared libs). of course –as-needed helps very much containing the rebuild, but you should also control that some packages have static .la that still point to the incorrect xcb .la.from the x11 overlay i’ve also found out that the protos and the majority of libs are very stable. i’m now using it to its fullness and have a much more stable system than gentoo’s stable amd64 branch.
I _think_ you have a bit of confusion about libraries. At any rate, I’ve fixed it quite easily, I’ll post something later tomorrow most likely.
I tried to wipe my system clean from *.la files, and have found some programs having trouble compiling. Should I file this somewhere or just propose a fix and send upstream?
This libtool static linking nonsense is one of gentoo’s greatest pitfalls.My experience with libxcb-xlib.la breakage has left me so frustrated with libtool I can hardly stand it. Portage does a very poor job of handling the breakage as well; revdep-rebuild doesn’t work because lib*.la files circularly reference one another and make rebuilding the libraries without a libxcb-xlib reference all but impossible. My next best solution is to unmerge all broken packages completely and then remerge them.