| 1 |
Igor Korot posted on Mon, 26 Nov 2012 16:49:01 -0800 as excerpted: |
| 2 |
|
| 3 |
>> ... you included the portage error, but not the make install log with |
| 4 |
>> its error... and you didn't include an emerge --verbose --pretend or |
| 5 |
>> similar, to see the USE flags it used, either! |
| 6 |
|
| 7 |
> LearningRight samples # emerge -pv ksvg |
| 8 |
> |
| 9 |
> These are the packages that would be merged, in order: |
| 10 |
> |
| 11 |
> Calculating dependencies... done! |
| 12 |
> [ebuild N ~] kde-base/ksvg-3.5.10-r1:3.5::kde-sunset USE="-debug" 0 |
| 13 |
> kB |
| 14 |
|
| 15 |
OK, so no real USE flags to worry about. (People still running kde3 |
| 16 |
would likely know that, but I didn't, because as I said I've long been on |
| 17 |
kde4.) Knowing there's no USE flags to speak of means the error isn't |
| 18 |
something that could be worked around by simply flipping a USE flag, a |
| 19 |
useful trick to keep in mind for those times when the problem does look |
| 20 |
like it might be USE flag related, especially if you don't really care |
| 21 |
which way you go with that particular flag. |
| 22 |
|
| 23 |
|
| 24 |
|
| 25 |
>> The easiest way to find the first error is often to either grep for or |
| 26 |
>> open the log file in your favorite editor and search for, "error". |
| 27 |
>> With a lot of packages the first few hits will be on errorlog or |
| 28 |
>> whatever modules, but then you'll start hitting the errors that |
| 29 |
>> triggered the die. You'll want to post at least the code surrounding |
| 30 |
>> the first one. (I usually backup from there until I find the "entering |
| 31 |
>> whatever-subdir" |
| 32 |
>> line before the error, and post from there thru the "leaving whatever |
| 33 |
>> subdir" line after the error, when I bug-file, then attach the whole |
| 34 |
>> build-log as well, just in case it's needed.) |
| 35 |
> |
| 36 |
> And here is the error from the build.log: |
| 37 |
|
| 38 |
> Making install in src make[4]: Entering directory |
| 39 |
> `/var/tmp/portage/kde-base/ksvg-3.5.10-r1/work/ksvg-3.5.10/ksvg/impl/ |
| 40 |
libs/libtext2path/src' |
| 41 |
> /bin/sh ../../../../../libtool --silent --tag=CXX --mode=compile |
| 42 |
> x86_64-pc-linux-gnu-g++ -DHAVE_CONFIG_H -I. -I. -I../../../../.. |
| 43 |
> -I/usr/include/freetype2 $ |
| 44 |
> /bin/sh ../../../../../libtool --silent --tag=CXX --mode=compile |
| 45 |
> x86_64-pc-linux-gnu-g++ -DHAVE_CONFIG_H -I. -I. -I../../../../.. |
| 46 |
> -I/usr/include/freetype2 $ |
| 47 |
> /bin/sh ../../../../../libtool --silent --tag=CXX --mode=compile |
| 48 |
> x86_64-pc-linux-gnu-g++ -DHAVE_CONFIG_H -I. -I. -I../../../../.. |
| 49 |
> -I/usr/include/freetype2 $ |
| 50 |
> /bin/sh ../../../../../libtool --silent --tag=CXX --mode=compile |
| 51 |
> x86_64-pc-linux-gnu-g++ -DHAVE_CONFIG_H -I. -I. -I../../../../.. |
| 52 |
> -I/usr/include/freetype2 $ |
| 53 |
> /bin/sh ../../../../../libtool --silent --tag=CXX --mode=compile |
| 54 |
> x86_64-pc-linux-gnu-g++ -DHAVE_CONFIG_H -I. -I. -I../../../../.. |
| 55 |
> -I/usr/include/freetype2 $ |
| 56 |
> /bin/sh ../../../../../libtool --silent --tag=CXX --mode=compile |
| 57 |
> x86_64-pc-linux-gnu-g++ -DHAVE_CONFIG_H -I. -I. -I../../../../.. |
| 58 |
> -I/usr/include/freetype2 $ |
| 59 |
> /bin/sh ../../../../../libtool --silent --tag=CXX --mode=compile |
| 60 |
> x86_64-pc-linux-gnu-g++ -DHAVE_CONFIG_H -I. -I. -I../../../../.. |
| 61 |
> -I/usr/include/freetype2 $ |
| 62 |
> In file included from /usr/include/fribidi/fribidi.h:35:0, |
| 63 |
> from Converter.cpp:25: |
| 64 |
> /usr/include/fribidi/fribidi-common.h:65:20: fatal error: glib.h: No |
| 65 |
> such file or directory compilation terminated. |
| 66 |
> make[4]: *** [Converter.lo] Error 1 make[4]: Leaving directory |
| 67 |
> `/var/tmp/portage/kde-base/ksvg-3.5.10-r1/work/ksvg-3.5.10/ksvg/impl/ |
| 68 |
libs/libtext2path/src' |
| 69 |
|
| 70 |
> It references "glib.h", but I don't understand this at all. |
| 71 |
> Does this mean that this package depends on the GTK+? Or "g" in the |
| 72 |
> "glib.h" means something else? |
| 73 |
> |
| 74 |
> I am under GNOME2 stable with GTK+2, BTW... |
| 75 |
|
| 76 |
glib was originally part of the gtk+ core indeed, and remains hosted at |
| 77 |
gtk.org. However, now days it's an extremely widely used base dependency |
| 78 |
required by pretty much any X-based app that's anywhere close to modern, |
| 79 |
including much or all of kde (I'm not sure if it's a dep of kdelibs or |
| 80 |
not), and is thus no longer really part of gtk per se but rather, now |
| 81 |
more like a general purpose library required by nearly anything X-based |
| 82 |
that's even close to modern, including much of kde (even kde3), as I said. |
| 83 |
|
| 84 |
Note that the problem traces thru the fribidi (bi-dir text utilities |
| 85 |
helper lib, for right-to-left as well as left-to-right text, etc, it's |
| 86 |
part of the i18n (i-18-letters-n, internationalization) stuff) header |
| 87 |
files. |
| 88 |
|
| 89 |
Thus, remerging your fribidi package may eliminate the problem... or |
| 90 |
trace the root of the problem to a fribidi (or glib) issue if /fribidi/ |
| 91 |
fails to build with a similar glib.h header-file error. Or it may not, |
| 92 |
but if all it takes is a fribidi rebuild (or even a glib rebuild, then a |
| 93 |
fribidi rebuild, then back to ksvg), it's a simple enough fix, and the |
| 94 |
problem would surely eventually spread if you didn't fix it too, given |
| 95 |
the number of packages that require glib and/or fribidi. |
| 96 |
|
| 97 |
That's why the first real error is so important to post (and why I asked |
| 98 |
for it). With what you originally posted there was no way on earth to |
| 99 |
trace the problem back to fribidi or glib. Knowing what that first error |
| 100 |
is can make all the difference in the world! |
| 101 |
|
| 102 |
-- |
| 103 |
Duncan - List replies preferred. No HTML msgs. |
| 104 |
"Every nonfree program has a lord, a master -- |
| 105 |
and if you use the program, he is your master." Richard Stallman |
Archives