In file included from /usr/local/include/freetype2/freetype/internal/ftobjs.h:31,
from /usr/local/include/freetype2/freetype/internal/tttypes.h:26,
from ftfuncs.c:53:
/usr/local/include/freetype2/freetype/ftrender.h:24:21: freetype/ftmodule.h: No such file or directory
Here we clearly see a system header being called from the local source tree's "ftheader.h" which has FT_MODULE_H defined as freetype/ftmodule.h instead of the newer ftmodapi.h which is what my system ftheader.h has defined. This is what happens when you have two conflicting versions of a library and you have to manually -I the directory for each one to use them. include "something.h" gets the same meaning as include <something.h> and thus we get a mixing of headers.
Ed Sweetman wrote:
David Dawes wrote:
On Wed, Nov 19, 2003 at 11:19:01PM -0500, Ed Sweetman wrote:
David Dawes wrote:
On Wed, Nov 19, 2003 at 07:47:04PM -0500, Ed Sweetman wrote:
Not sure if this is the place for bugs, in fact i really think it's xpert@xxxxxxxxxxx so i'll cc it to them too.
It might have been mentioned already but the cvs head is not up to date with freetype2 2.1.7 Many XFT and freetype related source and header files have #include <freetype/freetype.h> and other assorted headers which is not how you use libfreetype anymore. You're supposed to #include <ft2build.h> and then use macro includes for the various headers. The new version of freetype2 also appears to have broken compiling for lib/font/FreeType. I have no idea why there is a duplication of many headers in Xfree86's source tree and so far changing includes to be what they should be isn't fixing the these errors with expected headers missing and what not. Is nobody else seeing these errors?
Something like the attached patch should take care of most of it. Let me know if it works.
Amongst some other complications, lib/font/FreeType has at least one dependence on a header that isn't exported (ttobjs.h), so building against an external version currently probably won't work as expected. Maybe that can be handled differently?
The patch attached should address the other parts of lib/font/FreeType.
David
Yea, most of this i'd already done. It seems that freetype2 2.1.7 does not install ttobjs.h and it borks the install of the services headers by
ttobjs.h isn't a public interface, so naturally it isn't installed. If we can avoid using it, that'd be good. But it's more important that our freetype backend works correctly at this point in the release cycle :-)
not putting them in a services directory. Upon fixing that. I come across errors relating to the fact that headers with the same name as freetype2's appear in the X cvs tree. Such as ft2build.h It appears an old tree of freetype2 is in X which is really bothering me. Why is it there and why do any of the source files include it via path directly without any define anywhere to say not to use the system freetype2? I know it's using those files over the system ones because if i delete a common header i start getting build errors. This looks like either a serious design flaw or a bug. If i go through the trouble setting a truetype2 directory via host.cf it should use that and not the included xfree86 tree.
The patch I sent should fix that. If not, send the relevant build log info that shows the wrong ft2build.h file being used.
well i'm not sure what "wrong" would be because i dont know when it's supposed to use this local copy and when it's supposed to use the system and why it even needs the system one at all.
I cant build X now even with the patch because of me refusing to let the build use the local tree (removed it from extras). I cant find where you specify FTSOURCEDIR which apparently X needs (why?) to point to my current freetype2 build dir.
Well, the build of the module version of the freetype backend is actually a build of freetype itself, hence it needs the freetype source rather than a freetype installation. This also means that it's fairly closely tuned to the version of freetype we're using. Don't expect that to work against an external source tree of a newer version without some tuning.
The non-module freetype backend only requires ttobjs.h from the build tree, and editing lib/font/FreeType/Imakefile would allow that to find ttobjs.h from elsewhere.
So what's the point of having "#define freetype2" if we're going to build our own local copy of freetype2 anyway? Why link to any external freetype2.
If you want to build against an external *installation* (not build tree) of a newer freetype version, then keep extras/freetype2 around, and that should work with the patch I sent, providing the public interfaces are backward compatible. That's what I thought your original email was about. If you want to go beyond that and use an external build tree so that nothing in xc/extras/freetype2 is ever used, then you're on your own for now, or you'll have to wait until after 4.4 is out, when we'll probably look at importing a newer version of freetype.
David
But why does xfree86 need to have it's own build of freetype2 when every other userspace programs that use freetype2 just use the library interface like they're supposed to? For instance, freedesktop.org's Xserver links to freetype and doesn't require a build of it's own freetype2 library locally, it links to the system one.
_______________________________________________ XFree86 mailing list XFree86@xxxxxxxxxxx http://XFree86.Org/mailman/listinfo/xfree86
