[gentoo-amd64] Re: xpdf & SplashFTFont

[Duncan]

Pete Pardoe posted <6c6bf172050823095740760c0d@××××××××××.com>, excerpted
below,  on Tue, 23 Aug 2005 13:57:19 -0300:

> I get the following errors when I try to emerge xpdf - any insight
> would be greatly appreciated.
> ------------------------------------------------------------------
>
> x86_64-pc-linux-gnu-g++ -O2 -march=k8 -pipe -DHAVE_CONFIG_H -I..
> -I./../goo -I./../fofi -I.   -c SplashFTFont.cc
> SplashFTFont.cc:15:30: freetype/ftoutln.h: No such file or directory
> SplashFTFont.cc:16:69: freetype/internal/ftobjs.h: No such file or directory
> In file included from SplashFTFont.cc:21:
> SplashFTFontEngine.h:48: error: `FT_Library' has not been declared
> SplashFTFontEngine.h:48: error: ISO C++ forbids declaration of `libA'
> with no type
> SplashFTFontEngine.h:51: error: `FT_Library' does not name a type
> In file included from SplashFTFont.cc:22:
> SplashFTFontFile.h:56: error: `FT_Face' has not been declared
> SplashFTFontFile.h:57: error: ISO C++ forbids declaration of `faceA'
> with no type
> SplashFTFontFile.h:60: error: `FT_Face' does not name a type
> In file included from SplashFTFont.cc:23:
> SplashFTFont.h:48: error: `FT_Size' does not name a type
> SplashFTFont.h:49: error: `FT_Matrix' does not name a type
> SplashFTFont.cc:27: error: `FT_Vector' was not declared in this scope
> SplashFTFont.cc:27: error: `pt' was not declared in this scope
> SplashFTFont.cc:27: error: expected primary-expression before "void"
> SplashFTFont.cc:27: error: initializer expression list treated as
> compound expression
[major snip]
> make[1]: Leaving directory
> `/var/tmp/portage/xpdf-3.00-r10/work/xpdf-3.00/splash'
> ----------------------------------------------------------------------
> I did an emerge -S splashftfont and found nothing.  And I did a find
> on my system with the same result.

You are misunderstanding the errors.  The x86_64...g++ line at the top
says what's being compiled, the source file SplashFTFont.cc.  Immediately
below that, we have the errors starting.  They list the file, the line
number in the file where the error occurred, and sometimes (as at the
top), the approximate column in the line.

*.cc files are C++ source files.  *.h files are the headers, defining
variable and procedure call formats and the like.  Thus, it's saying that
the source file specifies (giving the line where they are specified)
certain header files it can't find, in this case, header files having to
do with freetype.  With the definitions from those header files missing,
all the bad type and not declared type errors aren't a mystery, because
they'd presumably be declared in the missing header files.

Then, down at the bottom, the "Leaving directory" line tells you which
specific temporary package working sub-directory it was in, when the
errors happened.  That way, if you want to go take a look at the mentioned
file and find the line that had the problem, you can.  Sometimes that
helps, altho it's not likely to be that much help here, because the
problem is obvious -- it can't find the header files it needs.

So... it's not a font that's missing, tho I can see how you might think
that if you didn't understand the way the error messages "talk", but
rather, either a missing freetype, or you have it installed, but the make
file (and therefore the ebuild, which should set it up) isn't configured
to point to the right spot.

Here's what I have here for the one missing header file:

$ equery belongs ftoutln.h

[ Searching for file(s) ftoutln.h in *... ]
media-libs/freetype-2.1.10 (/usr/include/freetype2/freetype/ftoutln.h)

That  tells you what package it's in, and where it's located in the
directory tree.  See if that package (that or a different version, not
that I'm on ~amd64, here, so your version may be older) is merged, and if
that header file exists at that location.  If you don't have the freetype
package merged, the bug is likely a missing dependency or the like,
probably in xpdf. If the package is merged but the file doesn't exist, use
equery files freetype (grepping the output if needed), to see if the file
was in the package at all -- the bug may be in your freetype package if
not.  If the file exists and simply isn't being detected, the bug is again
probably in your xpdf package, this time, probably either due to a missing
or incorrect path parameter telling the compile where to find the headers
it needs, or to some sort of screwed up logic with USE flags or something,
so it's trying to compile in support for something (the truetype USE
flag, maybe?) that should be turned off.

FWIW, you already know what freetype I have merged here, from the above
equery output.  My successfully merged xpdf is xpdf-3.00-r10.

The problem could also be a bit more obscure -- something like a bad
binutils or the like.  Note that here, in addition to running all ~arch,
I'm also running gcc-4.0.1, with related binutils and glibc snapshots,
all still hard-masked, AFAIK.  Thus, if it's some obscure toolchain bug
that happens to be fixed in the newest masked versions, I may not see it.

-- 
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 in
http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html


-- 
gentoo-amd64@g.o mailing list