Igor Korot posted on Mon, 26 Nov 2012 16:49:01 -0800 as excerpted: >> ... you included the portage error, but not the make install log with >> its error... and you didn't include an emerge --verbose --pretend or >> similar, to see the USE flags it used, either!
> LearningRight samples # emerge -pv ksvg > > These are the packages that would be merged, in order: > > Calculating dependencies... done! > [ebuild N ~] kde-base/ksvg-3.5.10-r1:3.5::kde-sunset USE="-debug" 0 > kB OK, so no real USE flags to worry about. (People still running kde3 would likely know that, but I didn't, because as I said I've long been on kde4.) Knowing there's no USE flags to speak of means the error isn't something that could be worked around by simply flipping a USE flag, a useful trick to keep in mind for those times when the problem does look like it might be USE flag related, especially if you don't really care which way you go with that particular flag. >> The easiest way to find the first error is often to either grep for or >> open the log file in your favorite editor and search for, "error". >> With a lot of packages the first few hits will be on errorlog or >> whatever modules, but then you'll start hitting the errors that >> triggered the die. You'll want to post at least the code surrounding >> the first one. (I usually backup from there until I find the "entering >> whatever-subdir" >> line before the error, and post from there thru the "leaving whatever >> subdir" line after the error, when I bug-file, then attach the whole >> build-log as well, just in case it's needed.) > > And here is the error from the build.log: > Making install in src make[4]: Entering directory > `/var/tmp/portage/kde-base/ksvg-3.5.10-r1/work/ksvg-3.5.10/ksvg/impl/ libs/libtext2path/src' > /bin/sh ../../../../../libtool --silent --tag=CXX --mode=compile > x86_64-pc-linux-gnu-g++ -DHAVE_CONFIG_H -I. -I. -I../../../../.. > -I/usr/include/freetype2 $ > /bin/sh ../../../../../libtool --silent --tag=CXX --mode=compile > x86_64-pc-linux-gnu-g++ -DHAVE_CONFIG_H -I. -I. -I../../../../.. > -I/usr/include/freetype2 $ > /bin/sh ../../../../../libtool --silent --tag=CXX --mode=compile > x86_64-pc-linux-gnu-g++ -DHAVE_CONFIG_H -I. -I. -I../../../../.. > -I/usr/include/freetype2 $ > /bin/sh ../../../../../libtool --silent --tag=CXX --mode=compile > x86_64-pc-linux-gnu-g++ -DHAVE_CONFIG_H -I. -I. -I../../../../.. > -I/usr/include/freetype2 $ > /bin/sh ../../../../../libtool --silent --tag=CXX --mode=compile > x86_64-pc-linux-gnu-g++ -DHAVE_CONFIG_H -I. -I. -I../../../../.. > -I/usr/include/freetype2 $ > /bin/sh ../../../../../libtool --silent --tag=CXX --mode=compile > x86_64-pc-linux-gnu-g++ -DHAVE_CONFIG_H -I. -I. -I../../../../.. > -I/usr/include/freetype2 $ > /bin/sh ../../../../../libtool --silent --tag=CXX --mode=compile > x86_64-pc-linux-gnu-g++ -DHAVE_CONFIG_H -I. -I. -I../../../../.. > -I/usr/include/freetype2 $ > In file included from /usr/include/fribidi/fribidi.h:35:0, > from Converter.cpp:25: > /usr/include/fribidi/fribidi-common.h:65:20: fatal error: glib.h: No > such file or directory compilation terminated. > make[4]: *** [Converter.lo] Error 1 make[4]: Leaving directory > `/var/tmp/portage/kde-base/ksvg-3.5.10-r1/work/ksvg-3.5.10/ksvg/impl/ libs/libtext2path/src' > It references "glib.h", but I don't understand this at all. > Does this mean that this package depends on the GTK+? Or "g" in the > "glib.h" means something else? > > I am under GNOME2 stable with GTK+2, BTW... glib was originally part of the gtk+ core indeed, and remains hosted at gtk.org. However, now days it's an extremely widely used base dependency required by pretty much any X-based app that's anywhere close to modern, including much or all of kde (I'm not sure if it's a dep of kdelibs or not), and is thus no longer really part of gtk per se but rather, now more like a general purpose library required by nearly anything X-based that's even close to modern, including much of kde (even kde3), as I said. Note that the problem traces thru the fribidi (bi-dir text utilities helper lib, for right-to-left as well as left-to-right text, etc, it's part of the i18n (i-18-letters-n, internationalization) stuff) header files. Thus, remerging your fribidi package may eliminate the problem... or trace the root of the problem to a fribidi (or glib) issue if /fribidi/ fails to build with a similar glib.h header-file error. Or it may not, but if all it takes is a fribidi rebuild (or even a glib rebuild, then a fribidi rebuild, then back to ksvg), it's a simple enough fix, and the problem would surely eventually spread if you didn't fix it too, given the number of packages that require glib and/or fribidi. That's why the first real error is so important to post (and why I asked for it). With what you originally posted there was no way on earth to trace the problem back to fribidi or glib. Knowing what that first error is can make all the difference in the world! -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman
