W3C home > Mailing lists > Public > www-amaya-dev@w3.org > July 2005

Re: subscribe RE: Amaya 9.2 compile error MacOS 10.4

From: <p.kerr@auckland.ac.nz>
Date: Sat, 9 Jul 2005 14:47:28 +1200
Message-ID: <1120877248.f94b285baa0ef@webmail.auckland.ac.nz>
To: Joseph Myers <jkmyers@wichita.edu>
Cc: www-amaya-dev@w3.org

Quoting Joseph Myers <jkmyers@wichita.edu>:

> When one include file can't be found, future errors caused at the same point
> of compilation are pretty much meaningless. All kinds of things are
> undefined,
> and sometimes some surprising things pop up, even some things that seem to be
> syntax errors in the C source code.
> 
> There is a copy of the missing file available here:
> 
> http://scipy.net/cgi-bin/viewcvsx.cgi/freetype/freetype2/include/ft2build.h
> 
> But if the rest of the correct edition of freetype2 isn't there, this won't
> help. Someone posted a message on this subject a while ago, here:
> 
> http://www.opendarwin.org/pipermail/darwinports/2004-April/020827.html

Thanks Joseph. I had 2 versions of freetype 2 installed, one in fink and one in 
X11, and for some reason ft2build.h was at a different nested level in X11 where 
the compiler was looking. I've bitten the bullet and got rid of fink, sorted out 
the includes and libs dirs, and now there is no error shown in make right up 
till

>./../thotlib/internals/h/glglyph.h:24:10: error: #include expects
>"FILENAME" or <FILENAME>
>./../thotlib/internals/h/glglyph.h:25:10: error: #include expects
>"FILENAME" or <FILENAME>
>./../thotlib/internals/h/glglyph.h:26:10: error: #include expects
>"FILENAME" or <FILENAME>
>./../thotlib/internals/h/glglyph.h:63: error: 'FT_BBox' does not
>name a type
>./../thotlib/internals/h/glglyph.h:64: error: 'FT_Vector' does not
>name a type
>./../thotlib/internals/h/glglyph.h:65: error: 'FT_Vector' does not
>name a type
>./../thotlib/internals/h/glglyph.h:80: error: 'FT_Face' does not
>name a type
>make[1]: *** [dialogue/font.o] Error 1
>make: *** [thotlib] Error 2

There are a lot of warnings in config.log about pointer targets being passed 
with wrong signedness, but I assumed they had something to do with a 32/64 bit 
confusion, and none seem to point at this part of the code.

Peter Kerr

-------------------------------------------------
This mail sent through University of Auckland
http://www.auckland.ac.nz/
Received on Saturday, 9 July 2005 02:47:37 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:49:01 GMT