Summary: | x11-libs/libdrm-2.4.54: building with abi_x86_32 fails: "/usr/include/cairo/cairo-features.h:13:3: error: #error "abi_x86_32 not supported by the package."" | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | PM <mitaspiotr> |
Component: | [OLD] Library | Assignee: | Gentoo X packagers <x11> |
Status: | RESOLVED DUPLICATE | ||
Severity: | normal | CC: | multilib+disabled |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
See Also: | https://bugs.gentoo.org/show_bug.cgi?id=511448 | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: | build log |
Description
PM
2014-05-27 12:58:57 UTC
Created attachment 377706 [details]
build log
For completeness, please post the output of: emerge -pv cairo or otherwise, the USE flags on your installed cairo. Ah, right, it's not built with abi_x86_32. Rebuilding it with this flag fixes the problem. This is somewhat similar to the cairo issue. Here cairo is used for some optional tests, so the ebuild author didn't add it to DEPEND and the tests are supposed to be run if cairo is installed. But for some reason, configure finds 32-bit pkg-config file for it on your system... I'll try to reproduce this. I can't reproduce. Any chance you have been using crossdev w/ i686-pc-linux-gnu? Nope. Would you be able to get a config.log off the original failure? Sorry, I don't have it anymore. Trying to reproduce it myself now I ran into some weird blocks when trying to rebuild cairo without x86_32 and I don't have time to deal with them now. Ok, for another test: i686-pc-linux-gnu-pkg-config --help does it mention 'lib32' or 'lib64' on the bottom? I don't have that in my PATH at all. Then I'm afraid we'd really use build.log and config.log with PKG_CONFIG_DEBUG_SPEW=1 like: ABI_X86=64 emerge -1v --nodep cairo PKG_CONFIG_DEBUG_SPEW=1 emerge -1v --nodep libdrm The '--nodep' will allow portage to ignore blockers. Later on, you will want to rebuild cairo back to both ABIs. Tried that, now libdrm build without a hiccup. There was a bunch of packages that were rebuilt with abi_x86_32 when I originally rebuilt cairo. Here's the list: Tue May 27 15:27:32 2014 >>> x11-libs/gdk-pixbuf-2.30.7-r1 Tue May 27 15:28:17 2014 >>> x11-libs/pixman-0.32.4 Tue May 27 15:28:44 2014 >>> media-libs/imlib-1.9.15-r4 Tue May 27 15:31:01 2014 >>> x11-libs/cairo-1.12.16-r3 Tue May 27 15:31:24 2014 >>> media-gfx/graphite2-1.2.4-r1 Tue May 27 15:32:05 2014 >>> media-libs/harfbuzz-0.9.28 Tue May 27 15:32:54 2014 >>> x11-libs/pango-1.36.3-r2 Tue May 27 15:33:12 2014 >>> x11-libs/pangox-compat-0.0.2-r1 Tue May 27 15:33:28 2014 >>> app-emulation/emul-linux-x86-gtklibs-20140508 Tue May 27 15:35:12 2014 >>> x11-libs/libdrm-2.4.54 Perhaps one of those was the culprit? Did you happen to have 32-bit cairo provided by emul-linux-x86-gtklibs[-abi_x86_32]? If yes, then it would be the temporary issue where headers installed by cairo were unsuitable for libraries provided by emul-linux. I honestly have no idea. As far as I'm concerned this whole multilib system is a big black box that sometimes breaks, and then you poke it with a stick randomly until it starts working again. If you think it's a temporary issue (i.e. "will fix itself"), then I'm fine with leaving it at that. Well, as many other Gentoo issues this one fixes itself when you 'emerge -e @world' to rebuild all packages :). It applies to all people who have built some packages in a short period of time when there was bug in the eclass, and is fixed by rebuilding the buggy deps. Just to be clear, if you rebuilt cairo without changing USE flags, it would likely work as well. *** This bug has been marked as a duplicate of bug 509556 *** |