Summary: | x11-libs/libxcb injects itself into .la files in all sorts of packages via libtool | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Petteri Räty (RETIRED) <betelgeuse> |
Component: | [OLD] Library | Assignee: | Gentoo X packagers <x11> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | candrews, devangm, djphazer, dmakovey, eXt, flameeyes, galtgendo, ikelos, jakub, le.petit.fou, mroconnor, pacho, psihozefir, quickhelp, radhermit, simon.thum, tomka |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | |||
Bug Blocks: | 174434 |
Description
Petteri Räty (RETIRED)
2006-12-18 10:58:27 UTC
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 |