The following error occurred during the update from Harfbuzz 1.9.0 to 2.0.2: checking for GLIB... no configure: error: glib support requested but glib-2.0 not found ... * ERROR: media-libs/harfbuzz-2.0.2::gentoo failed (configure phase) The pkconfig files exist: # ls -la /usr/lib64/pkgconfig/glib-2.0.pc -rw-r--r-- 1 root root 381 26. Nov 21:37 /usr/lib64/pkgconfig/glib-2.0.pc # ls -la /usr/lib32/pkgconfig/glib-2.0.pc -rw-r--r-- 1 root root 381 26. Nov 21:37 /usr/lib32/pkgconfig/glib-2.0.pc # pkg-config --modversion glib-2.0 2.52.3 A update from Harfbuzz 1.9.0 to 2.1.1/2.1.3 also failed on the same line on configure phase.
Created attachment 556666 [details] build.log
Created attachment 556668 [details] emerge_info.txt
Please attach the config.log file form failed harfbuzz merge and post the output of emerge -Oqpv dev-libs/glib:2 to this bug.
This isn't the issue (as build.log has it finding i686 pkgconfig), but something I noticed when looking into it from bugmail: the virtual/pkgconfig BDEPEND is missing [${MULTILIB_USEDEP}] Might want to fix that too; but as said, this shouldn't be the issue here as configure finds the correct ${CHOST}-pkg-config
Created attachment 556782 [details] config.log harfbuzz-2.0.2-abi_x86_32.x86/config.log
# emerge -Oqpv dev-libs/glib:2 [ebuild R ] dev-libs/glib-2.52.3 USE="dbus (mime) xattr -debug (-fam) (-selinux) -static-libs -systemtap -test -utils" ABI_X86="32 (64) (-x32)" PYTHON_TARGETS="python2_7"
Exactly the same problem here, on an amd64 system. It correctly configure and compile on a true i686 system.
Mmm ... I've crossdev for i686 installed on this system. And there is this nice symbolic link in my /usr/bin: /usr/bin/i686-pc-linux-gnu-pkg-config -> cross-pkg-config Now let try to use i686-pc-linux-gnu-pkg-config, i.e. cross-pkg-config against glib-2.0: i686-pc-linux-gnu-pkg-config glib-2.0 realpath: pkgconfig/..: No such file or directory that is the error where the harfbuzz configure stop its execution. While on systsem WITHOUT crossdev installed no errors at all. May be this the source of the error?
Yep. I uninstalled crossdev for i686 and emerge again pkgconfig. Now harfbuzz-2.0.2 configure, emerge and installs correctly, at least in my system.
Apologies for the multiple comments, but I've found that this symbolic link /usr/i686-pc-linux-gnu/usr/share/pkgconfig -> /usr/lib32/pkgconfig/ seems to solve the problem, leaving crossdev-i686 installed. May be a useful info?
Many Thanks together. This is a very useful information. I have build it on my other machine (without crossdev) there were no problems. I try it tomorrow again.
(In reply to Sven Eusewig from comment #11) > Many Thanks together. This is a very useful information. I have build it on > my other machine (without crossdev) there were no problems. I try it > tomorrow again. Fine. Unfortunately creating the symbolic link /usr/i686-pc-linux-gnu/usr/share/pkgconfig -> /usr/lib32/pkgconfig/ doesn't work. The "configure" stage is fine, but the package doesn't compile. Probably the crossdev pkgconfig script doesn't return the correct info. What works, of course, is using the "dev-util/pkgconfig" native i686-pc-linux-gnu-pkg-config binary. I do not use i686 crossdev tools on my system, I just need the gcc compiler to let distcc to help an old slow true i686 system (I use to keep alive acroread under gentoo) to emerge its world. So, for me, a copy of "dev-util/pkgconfig" i686-pc-linux-gnu-pkg-config binary is enough to keep my system healty, for my needs. But, this is not a solution, it is only an hack. Why on the hell crossdev silenty unlink "dev-util/pkgconfig" i686-pc-linux-gnu-pkg-config and create a simbolic link to its scripts? And why version 1.8.1 of harfbuzz is happy with this script while version 1.9.0 fails miserably? which other ebuilds may show the same problem with crossdev i686 cross-pkg-config script? I would think that this BUG should move from the harfbuzz maint to the crossdev maints.
I removed crossdev and the build goes through. I've installed crossdev simply for one reason so I can support an older machine via distcc. Okay. I also think. It should go to the crossdev maintainer. Should I contact the people?
CCing crossdev maintainers.
I think it's the #500338 where we need to add a safety check to crossdev to disallow people to generate ${!CHOST*} toolchains and break their systems by accident. *** This bug has been marked as a duplicate of bug 500338 ***
Correct bug, thanks for addressing us to it. I would complain that "forbidding" the crossdev i686 chain under amd64 is not a "solution", it is just an easy way to get rid of the problem. But I'm sure nobody is going to listen, reading the thread of the "bug 500338". I'm not a native english speaker, in italian language, my native tongue, we say "spazzare la polvere sotto il tappeto".
(In reply to Giuseppe Vitillaro from comment #16) > Correct bug, thanks for addressing us to it. > > I would complain that "forbidding" the crossdev i686 chain under amd64 is > not a "solution", it is just an easy way to get rid of the problem. The bug should be not about forbidding any i686 toolchain. Just the one that collides with system one, specifically i686-pc-linux-gnu. You can still have, say, i686-unknown-linux-gnu. Vendor field should be largely ignored by most packages (it is a bug if it's not). Or is it too restrictive you your opinion as well?
(In reply to Sergei Trofimovich from comment #17) > (In reply to Giuseppe Vitillaro from comment #16) > > Correct bug, thanks for addressing us to it. > > > > I would complain that "forbidding" the crossdev i686 chain under amd64 is > > not a "solution", it is just an easy way to get rid of the problem. > > The bug should be not about forbidding any i686 toolchain. Just the one that > collides with system one, specifically i686-pc-linux-gnu. You can still > have, say, i686-unknown-linux-gnu. Vendor field should be largely ignored by > most packages (it is a bug if it's not). > > Or is it too restrictive you your opinion as well? If I remeber correctly how distcc works ... yes.
