Re: freetype2 problems with cvs

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, Nov 20, 2003 at 08:00:21PM -0500, Ed Sweetman wrote:
>David Dawes wrote:
>> On Thu, Nov 20, 2003 at 01:29:13AM -0500, Ed Sweetman wrote:
>> 
>>>David Dawes wrote:
>>>
>>>>On Wed, Nov 19, 2003 at 11:19:01PM -0500, Ed Sweetman wrote:
>>>>
>>>>
>>>>
>>>>
>>>>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 
>> 
>> 
>> What you consider "wrong". :-)
>> 
>> 
>>>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.
>> 
>> 
>> The system one is only used for the module freetype backend build.
>> In fact last night I committed a change that moves it (and some
>> other locally modified headers) to the module directory so they
>> can't be used by anything else.  In my build tests with the patch,
>> it only uses the local ft2build.h in that case.  That's why if you're
>> seeing something different I need some specific details in order to
>> follow it up.
>> 
>> 
>>>
>>>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.
>> 
>> 
>> So because one out of the 4 or 5 things that reference freetype2 ignores
>> the external one, we shouldn't allow the external one at all?
>> 
>>>
>>>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.
>> 
>> 
>> If you build a non-modular XFree86 server, then you get exactly that.
>> Add '#define DoLoadableServer NO' to you host.def.
>> 
>> You don't get that for the (default) modular XFree86 server because
>> nobody has done the work necessary to build an XFree86 "freetype"
>> backend module that can request that an external freetype library
>> be loaded on demand.  Remember the backend font modules are loaded
>> optionally by the modular XFree86 server, so modules that use
>> specific external interfaces should cause those interface to get
>> loaded as required rather than requiring the core XFree86 binary
>> to be linked against all conceivable external interfaces in advance.
>> 
>> Until that work is done, the freetype backend module needs to contain
>> its own complete copy of libfreetype.
>> 
>> Feel free to do the work necessary to correct this obvious anomaly :-).
>> 
>> The ttobjs.h issue needs to be addressed one way or another too,
>> either by findind an equivalent public interface, or creating an
>> equivalent public interface, so that this user-mode program can do
>> what it needs to do without knowing more about the freetype internals
>> than it has any right to :-)
>> 
>> David
>
>
>Ok, so the module responsible for the actual rendering in Xfree86 is 
>compiling against the local copy of freetype2 right?  The reason why I 

Server side rendering, yes.  Client side rendering, no.

>thought there was no reason to link to a local source tree because 
>you're building it into a module, is that there are plenty of examples 
>of programs with plugins that link to libraries like gtk and such 
>without having local copies of such libraries. I take it this is very 
>difficult to do with XFree86 since it was originally written in a 
>non-modular form.

We don't use dlopen() as our module loader (for semantic reasons,
primarily).  Nevertheless it's possible to do what is needed.  It
just needs to be done.

>Are there flags i can override in host.cf that will let me point xfree86 
>to a different source tree or can i just dump the system freetype2 
>source tree into xc/extras and do things that way?  Otherwise i'll just 

No, because you'll also almost certainly need to modify
lib/font/FreeType/module/Imakefile and some other files, which are
likely tied fairly closely to the freetype version.

>Here's the latest error after your ftnew.diff

OK, I hadn't checked the utilities that directly reference freetype.
I'd only done the libraries.

>It uses quotes in the source file but doesn't appear to need to use the 
>local copy of the source tree so i changed them to use the system copy 
>headers.  Of course this doesn't mean it'll be linked to the system 
>library.  :-/  it compiled though.

It should be.  Check for -L/path/to/your/installed/lib in the build log.

The attached patch fixes these two utilities.  I'll commit that too.

My complete build against the external freetype installation hasn't
finished yet (old slow machines, and all that).  If there are more
problems, I'll commit fixes for them too.

David
-- 
David Dawes
developer/release engineer                      The XFree86 Project
www.XFree86.org/~dawes
_______________________________________________
XFree86 mailing list
XFree86@xxxxxxxxxxx
http://XFree86.Org/mailman/listinfo/xfree86

[Index of Archives]     [X Forum]     [Xorg]     [XFree86 Newbie]     [IETF Announce]     [Security]     [Font Config]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux Kernel]

  Powered by Linux