Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 645540 - x11-libs/pango-1.40.14: .../work/pango-1.40.14/pango/pangocairo.h:26:19: fatal error: cairo.h: No such file or directory
Summary: x11-libs/pango-1.40.14: .../work/pango-1.40.14/pango/pangocairo.h:26:19: fata...
Status: UNCONFIRMED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: All Linux
: Normal normal with 2 votes (vote)
Assignee: Gentoo Linux Gnome Desktop Team
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: no-symlink-lib
  Show dependency tree
 
Reported: 2018-01-24 08:20 UTC by John Dallahan
Modified: 2020-04-12 21:11 UTC (History)
6 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
emerge --info (file_645540.txt,6.26 KB, text/plain)
2018-01-24 08:20 UTC, John Dallahan
Details
emerge -pqv (file_645540.txt,97 bytes, text/plain)
2018-01-24 08:21 UTC, John Dallahan
Details
build.log (file_645540.txt,134.00 KB, text/plain)
2018-01-24 08:22 UTC, John Dallahan
Details
/usr/lib32 and /lib32 contents (file_645540.txt,55.43 KB, text/plain)
2018-01-24 08:29 UTC, John Dallahan
Details

Note You need to log in before you can comment on or make changes to this bug.
Description John Dallahan 2018-01-24 08:20:43 UTC
Created attachment 516304 [details]
emerge --info

configure says `checking for CAIRO... no`, which could be the issue here.
emerge --info, emerge -pqv, build.log attached.
Comment 1 John Dallahan 2018-01-24 08:21:40 UTC
Created attachment 516306 [details]
emerge -pqv
Comment 2 John Dallahan 2018-01-24 08:22:08 UTC
Created attachment 516308 [details]
build.log
Comment 3 John Dallahan 2018-01-24 08:28:52 UTC
Note: I got this bug after I followed the news item for the 17.1 profile. It shows up when I try to do the last step, `emerge -av /lib32 /usr/lib32`. Attached is the folders' contents.
Comment 4 John Dallahan 2018-01-24 08:29:18 UTC
Created attachment 516312 [details]
/usr/lib32 and /lib32 contents
Comment 5 Alexander Tsoy 2018-02-01 11:44:32 UTC
Please attach "/var/tmp/portage/x11-libs/pango-1.40.14/work/pango-1.40.14-abi_x86_32.x86/config.log"
Comment 6 John Dallahan 2018-02-01 13:26:50 UTC
I will have to install Gentoo in a VM then try to migrate it to 17.1. I will add the config.log this weekend.
Comment 7 Alex 2018-02-03 08:32:15 UTC
Look my last comment (comment #82) in bug 506276

I managed to have all packages including pango capable for rebuilding by disabling ABI x64_32 globally and then rebuilding the world and then I could do again
emerge -1v /usr/lib32
with the result that no-one apart from mesa claims files in /usr/lib32.

I'm on the way to restore the 32-ABI. Will report on the result.
Comment 8 John Dallahan 2018-02-03 09:00:55 UTC
(In reply to Alex from comment #7)
> Look my last comment (comment #82) in bug 506276
> 
> I managed to have all packages including pango capable for rebuilding by
> disabling ABI x64_32 globally and then rebuilding the world and then I could
> do again
> emerge -1v /usr/lib32
> with the result that no-one apart from mesa claims files in /usr/lib32.
> 
> I'm on the way to restore the 32-ABI. Will report on the result.

How about, USE=-abi_x86_32 emerge -1v /lib32 /usr/lib32 && emerge --changed-use -v1D @world ?
Because I had a lot of multilib packages I did not want to rebuild it. I will test this command in a VM shortly.
Comment 9 Alex 2018-02-03 09:20:22 UTC
(In reply to John Dallahan from comment #8)
> (In reply to Alex from comment #7)
> > Look my last comment (comment #82) in bug 506276
> > 
> > I managed to have all packages including pango capable for rebuilding by
> > disabling ABI x64_32 globally and then rebuilding the world and then I could
> > do again
> > emerge -1v /usr/lib32
> > with the result that no-one apart from mesa claims files in /usr/lib32.
> > 
> > I'm on the way to restore the 32-ABI. Will report on the result.
> 
> How about, USE=-abi_x86_32 emerge -1v /lib32 /usr/lib32 && emerge
> --changed-use -v1D @world ?
> Because I had a lot of multilib packages I did not want to rebuild it. I
> will test this command in a VM shortly.

No way. First world and then STILL again /usr/lib32. The point is that if you try to disable some flags (not necessarily ABI) and issue emerge over /usr/lib32, the dependency tracker will fail because many other packages (higher level) who rely on the libraries in /usr/lib32 are already build with some flags for these libraries in mind. emerge will not start, I tried.
What is really strange (and bad), however, is that rebuilding the world will still put files of, for example pango, explicitly in /usr/lib32. But emerge will go without mistakes. Later, you will have to do again
emerge -1v /usr/lib32
and only then pango would say nothing about lib32. Weird in my opinion.

I have a thought that you can try rebuilding the world without disabling anything, but this may be not true. In my case, pango was 732 in the queue for world re-emerging and I was reluctant to try different options. I decided to go immediately without 32-ABI to eliminate as much as possible enquires for lib32.
Comment 10 Alex 2018-02-05 00:53:05 UTC
In the general bug about migration I have completed my observations. I believe it is emerge whom to blame for oddities of the process.
Comment 11 Mart Raudsepp gentoo-dev 2018-07-30 21:42:13 UTC
Is there anything to fix here for pango or cairo gentoo maintainers?
Comment 12 Jack 2019-06-06 22:58:09 UTC
The failure still exists with pango-1.42.4-r1.  At first I had several failures during the configure stage, but those all resolved by re-emerging the packages it apparently couldn't find, and now I'm left with the same error.  Note I have "checking for CAIRO... yes" so I suspect that's a red herring.  I also have not removed abi_x86_32.

At this point, it looks to me like this bug should block the 17.1 migration tracker bug 506276.
Comment 13 Jack 2019-06-06 23:10:52 UTC
Sorry - I need to correct myself.  I do have "no" for finding Cairo in 32 bit, but "yes" in 64 bit.  That confuses me, because if it didn't find it, why would it be looking for it at all during compile phase for 32 bit?
Comment 14 Paul Osmialowski 2019-06-07 11:56:59 UTC
Is there a way to solve this? I stuck at 1/3 of 17.0 to 17.1 migration making this system partially unusable and completely unupdateable.
Comment 15 Luke Bratch 2019-06-07 12:08:17 UTC
(In reply to Paul Osmialowski from comment #14)
> Is there a way to solve this? I stuck at 1/3 of 17.0 to 17.1 migration
> making this system partially unusable and completely unupdateable.

I was also stuck on this for the 17.1 profile migration and solved it by remerging (almost) everything that equery depgraph said x11-libs/pango depended on with a --depth of 3.

Something along the lines of:

equery -C depgraph --depth 3 x11-libs/pango > depgraph.txt
emerge -1av $(awk '{print $3}' depgraph.txt | sed 's/^/=/')

Note that I did have to remove ruby from depgraph.txt and fix various things along the way (all along the lines of "configure can't find package foo") but this approach got there in the end.
Comment 16 Alexander Tsoy 2019-06-07 12:29:31 UTC
If you have "dev-util/pkgconfig", then you need to rebuild it. Unlike "dev-util/pkgconf", it doesn't install shared libraries, so rebuilding everything in  /usr/lib32 doesn't trigger its rebuild.
Comment 17 Alexander Tsoy 2019-06-07 12:34:50 UTC
If my theory is correct, just after migration you will get something like this:

# i686-pc-linux-gnu-pkg-config --libs cairo 
Package cairo was not found in the pkg-config search path.
Perhaps you should add the directory containing `cairo.pc'
to the PKG_CONFIG_PATH environment variable
No package 'cairo' found

# strace i686-pc-linux-gnu-pkg-config --libs cairo 2>&1 | grep lib32
openat(AT_FDCWD, "/lib32/libc.so.6", O_RDONLY|O_LARGEFILE|O_CLOEXEC) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/lib32/libpthread.so.0", O_RDONLY|O_LARGEFILE|O_CLOEXEC) = -1 ENOENT (No such file or directory)
stat64("/usr/lib32/pkgconfig/cairo-uninstalled.pc", 0xff8b3c4c) = -1 ENOENT (No such file or directory)
stat64("/usr/lib32/pkgconfig/cairo.pc", 0xff8b3cbc) = -1 ENOENT (No such file or directory)
Comment 18 Alexander Tsoy 2019-06-07 12:47:02 UTC
(In reply to Alexander Tsoy from comment #17)
> If my theory is correct..
Nevermind. Problems with pkgconfig can happen only after removal of /usr/lib32 symlink. But it seems your migration is stuck somewhere before this point.
Comment 19 David 2019-06-07 16:56:49 UTC
Same issue here with the 17.1 profile migration.

We need to rebuild media-libs/mesa first because pango depend on cairo and cairo pkgconfig is breaked by the lack of gl.pc file:

i686-pc-linux-gnu-pkg-config --cflags cairo
Package gl was not found in the pkg-config search path.
Perhaps you should add the directory containing `gl.pc'
to the PKG_CONFIG_PATH environment variable
Package 'gl', required by 'cairo', not found
Comment 20 Jack 2019-06-07 17:07:55 UTC
After handling several such issues manually (seeing what failed why, then emerging the dependency) I tried "emerge -1 --deep /lib32 /usr/lib32".  It's now over half done, and does seem to have put things in the right order - no failures so far.  It's now on 32 of 44, with no failures yet.
Comment 21 David 2019-06-07 17:13:33 UTC
So to get things works on my system:


emerge -1 x11-libs/libdrm x11-libs/libXxf86vm x11-libs/libxcb x11-libs/libX11 x11-libs/libXfixes x11-libs/libXdamage x11-libs/libXext

then:

emerge -1 media-libs/mesa

and after all:

emerge -1 x11-libs/pango

Hope it will help you.
Comment 22 Paul Osmialowski 2019-06-07 17:17:38 UTC
@Luke Bratch Thanks for your hint. Although whole list failed half way through (e.g. libsoup dependency on sqlite and libpsl was not picked) I finally got to the point where I was re-merging packages from the list manually and trying to re-merge pango after each. In the end pango re-emerged after I re-emerged mesa.
Whole operation shifted the progress of overall migration from 1/3 to 1/2.
Comment 23 Bernd Feige 2019-06-10 15:17:00 UTC
(In reply to Paul Osmialowski from comment #22)

Thanks, re-emerging mesa helped here as well - I have USE=vaapi creating a circular dependency as x11-libs/libva also searches for (and doesn't find) libGL ... I had to do

USE=-vaapi emerge media-libs/mesa
emerge -1 x11-libs/libva media-libs/mesa

Afterwards cairo32 installed to correct /usr/lib and pango + dependencies compiled as well.
Comment 24 mercuriete 2019-07-25 16:57:05 UTC
I have the same problem.
I will try to rebuild mesa as suggested by #23
Comment 25 mercuriete 2019-07-25 18:04:02 UTC
exaclty that comment#23 fixes my problem
libva circular dependency so compile mesa without vaapi.
then compile libva and mesa again.

after that I could compile pango

Thanks for sharing this knowledge :-)
Comment 26 Sebastian Schmid 2019-09-30 14:00:58 UTC
The approach in comment #23 has solved my issues as well.

Before ...
emerge -1 =x11-libs/pango-1.42.4-r2
... complaint:
"fatal error: cairo.h: No such file or directory"

After, I could ...
emerge -1 =x11-libs/gtk+-2.24.32-r1 =x11-libs/gtk+-3.24.10
... and the other packages which failed before.

Thank you.
Comment 27 Greg Turner 2019-10-28 01:02:24 UTC
This is a problem nobody's Grandma is ever going to solve (unless Grandma's a hacker)....

I wish there was some kind of provision in Gentoo EAPI allowing ebuild authors to give package manager hints about how particular circular-dependency-affected migrations could be performed without having to read those awful 'sorry-depsolver-says-"no"' error messages... iow ideally these problems could be sorted out automatically.

... but, admittedly, this particular case might not benefit, even if there were such a thing, since, here, dbapi doesn't correctly reflect the current deployed state of ABI_X86_32 files.
Comment 28 Philippe Trottier 2020-04-12 21:11:07 UTC
Hello, I am in the same predicament now. 

One thing went even worst in my case I did a --keep-going @world and it borked the python-3.6.10 needed for portage, lucky enough I had a package

Broke as in emerge --info was not working anymore.

I did find nearly the same list of packages to re install, missing a few. I'll be trying all the packages listed here.