Bug 556

Summary: RFE: Update FreeType2 version in xc/extras/Freetype2 to V2.1.8...
Product: xorg Reporter: Roland Mainz <roland.mainz>
Component: Build/MonolithicAssignee: Roland Mainz <roland.mainz>
Status: RESOLVED FIXED QA Contact:
Severity: enhancement    
Priority: high CC: cyamauch, eich, xorg-team
Version: git   
Hardware: All   
OS: All   
Whiteboard:
i915 platform: i915 features:
Bug Depends on:    
Bug Blocks: 307, 438, 547    
Attachments:
Description Flags
Patch part #1
none
Patch part #2
none
Commit log for patch part#1 + #2 none

Description Roland Mainz 2004-04-26 10:59:45 UTC
RFE: Update FreeType2 version in xc/extras/Freetype2 to V2.1.8...
Comment 1 St├ęphane Loeuillet 2004-04-27 20:32:13 UTC
bug http://freedesktop.org/cgi-bin/bugzilla/show_bug.cgi?id=547 requires
freetype version bump to 2.1.8 too

so, this looks like a dupe
Comment 2 St├ęphane Loeuillet 2004-04-27 21:03:01 UTC
http://freedesktop.org/cgi-bin/bugzilla/show_bug.cgi?id=438 would require
freetype 2.1.8 version bump too
Comment 3 Roland Mainz 2004-04-28 15:25:17 UTC
Stephane LOEUILLET wrote:
> bug http://freedesktop.org/cgi-bin/bugzilla/show_bug.cgi?id=547 requires
> freetype version bump to 2.1.8 too
> 
> so, this looks like a dupe

No, bug 547 _depends_ on this bug. It's not a DUPlicate. I'll prefer that things
are done step-by-step since this allowes to isolate and unroll problems on
demand.
Comment 4 Roland Mainz 2004-04-28 15:26:06 UTC
Stephane LOEUILLET wrote:
> http://freedesktop.org/cgi-bin/bugzilla/show_bug.cgi?id=438 would require
> freetype 2.1.8 version bump too

That bug depends on this one too then...
Comment 5 Roland Mainz 2004-04-28 16:08:48 UTC
Taking bug... I'll try my luck...
Comment 6 Roland Mainz 2004-04-28 20:32:41 UTC
Created attachment 246 [details] [review]
Patch part #1
Comment 7 Roland Mainz 2004-04-28 20:34:15 UTC
Created attachment 247 [details] [review]
Patch part #2
Comment 8 Roland Mainz 2004-04-28 20:43:50 UTC
Created attachment 248 [details]
Commit log for patch part#1 + #2

attachment 246 [details] [review] and attachment 247 [details] [review] checked-in...

... I am leaving the bug open until I have tested that the tree still builds.
Comment 9 Roland Mainz 2004-04-30 07:17:24 UTC
Everything seems to work fine now.
Marking bug as FIXED.

Egbert:
Can you take a look at the patches attached to this bug and check whether you
see any glitches which need to be fixed ? If there is anything please either
REOPEN the bug or file a new one, CC: me and mark it as dependicy to this one.
Comment 10 Egbert Eich 2004-05-01 03:55:36 UTC
I don't understand the diffs. They are huge and seem to be the diff
between 2.1.7 and 2.1.8. We should not have to do *any* modification
to the stuff in extras we pull in. Instead we need to make all necessary
adjustments in the libs we are maintaining that link against that stuff.
If you met this requirement and did a build and run test you should be
save.
Also we need to put Chisato's patches into lib/fontFreeType/modules to
add the lazy font stuff.
Also there were some kludges to make 2.1.7 work (which haven't made it 
in the tree). We need to see if we still need some of them.
Comment 11 Egbert Eich 2004-05-01 04:01:02 UTC
I forgot to mention that I don't have real good access to my cvs trees right now.
Comment 12 Roland Mainz 2004-05-05 04:31:02 UTC
Egbert Eich wrote:
> I don't understand the diffs. They are huge and seem to be the diff
> between 2.1.7 and 2.1.8.

Uhm... this is usually the way how moz.org does the job - the patch is stored in
bugzilla for review/approval and checked-in as-is. Nothing in the main branches
goes "in" without being stored in bugzilla first.

> We should not have to do *any* modification
> to the stuff in extras we pull in. Instead we need to make all necessary
> adjustments in the libs we are maintaining that link against that stuff.
> If you met this requirement and did a build and run test you should be
> save.

I guess I met that requirement... but I better check that again to be sure.

> Also we need to put Chisato's patches into lib/fontFreeType/modules to
> add the lazy font stuff.

That's bug 307 ("Changes to freetype module break optimization heuristics on CJK
fonts") - this bug was about the freetype2 update, next step is to fix the
damage done by Keith Packard in the Freetype font code.

> Also there were some kludges to make 2.1.7 work (which haven't made it 
> in the tree). We need to see if we still need some of them.

Uhm... are there any bugzilla bugs which describe the "kludges" ?
Comment 13 Egbert Eich 2004-05-06 01:48:56 UTC
Roland Mainz wrote:

> Uhm... this is usually the way how moz.org does the job - the patch is stored in
> bugzilla for review/approval and checked-in as-is. Nothing in the main branches
> goes "in" without being stored in bugzilla first.

Right. But you were pulling in the freetype2 2.1.8 bits. These things should go
in unchanged. If at all we need to work around problems from outside. Changing
the freetype code in our tree means we have to tack our changes in future
versions. XFree86 seems to do this sometimes - but it is crazy. freetype should
not even have to be in the tree and we are moving to a situation where it
doesn't have to be. 
I've checked for differences to freetype2 2.1.8: I found a change in the
ftconfig.h header which was related to CHAR_BITS. I've reverted this and added a
patch to another place to take care of the problem. 

> Uhm... are there any bugzilla bugs which describe the "kludges" ?

No, unfortunately not. Today I worked a little bit more on the freetype issue
and found some other symbol problems. I will make a separate entry to bugzilla
for this.
I may also delete the static freetype module build so that the freetype module 
that gets used will be an .so which can link against a system supplied freetype
library.
Comment 14 Roland Mainz 2004-05-06 04:37:34 UTC
Egbert Eich wrote:
> Roland Mainz wrote:
> > Uhm... this is usually the way how moz.org does the job - the patch is 
> > stored in
> > bugzilla for review/approval and checked-in as-is. Nothing in the main 
> > branches goes "in" without being stored in bugzilla first.
>
> Right. But you were pulling in the freetype2 2.1.8 bits. These things should 
> go in unchanged. If at all we need to work around problems from outside. 
> Changing the freetype code in our tree means we have to tack our changes in 
> future versions. XFree86 seems to do this sometimes - but it is crazy. 
> freetype should not even have to be in the tree and we are moving to a 
> situation where it doesn't have to be. 
> I've checked for differences to freetype2 2.1.8: I found a change in the
> ftconfig.h header which was related to CHAR_BITS. I've reverted this and added 
> a patch to another place to take care of the problem. 

I found the difference yesterday... my fault... but I was preparing a patch for
the Freetype.org CVS to include that fix... is that no longer needed now ?

> > Uhm... are there any bugzilla bugs which describe the "kludges" ?
> No, unfortunately not. Today I worked a little bit more on the freetype issue
> and found some other symbol problems. I will make a separate entry to bugzilla
> for this.
> I may also delete the static freetype module build so that the freetype module 
> that gets used will be an .so which can link against a system supplied 
> freetype library.

Erm... will that mean that I cannot build a Xserver with a statically linked
Freetype module and Freetype library ? Remember that our own Xprint.org releases
always linked Freetype statically for stability and maintaince reasons... and it
will take a couple of years until all distributions have adopted at least
FreeType 2.1.8. Please do not do that...
Comment 15 Egbert Eich 2004-05-06 18:59:08 UTC
Roland Mainz wrote:

> I found the difference yesterday... my fault... but I was preparing a patch for
> the Freetype.org CVS to include that fix... is that no longer needed now ?

Right. It is only needed for the 'static' module build. But for this I've added
a define to myftstdlib.h. For any other case myftstdlib.h will include the
default ftstdlib.h which in turn includes limits.h.

> Erm... will that mean that I cannot build a Xserver with a statically linked
> Freetype module and Freetype library ? Remember that our own Xprint.org > releases
> always linked Freetype statically for stability and maintaince reasons... and it
> will take a couple of years until all distributions have adopted at least
> FreeType 2.1.8. Please do not do that...

That's what I would like to find out before I do the changes. In theory if you
link against a dynamic lib that is later than the one on the system and you
install this lib on your system later on the loader should pick this one over
the system provided one. However you do a 'static' Xprint server anyway so you
should be able to link against a static libfreetype2.a which could be the one
supplied by the freetype2 package as you don't need the ugly module stuff
anyway. I've heared people suggest that once freetype can deal with CID fonts
we should link the server against freetype and forget about all font render
modules anyway.
I don't know if this will happen as companies supplying commercial font
renderers may become pretty upset.
Besides I think as far as freetype versions and 'older systems' are concerned
X'whatever' and Xprint are in the same boat: fontconfig already depends on 
freetype 2.1.7. Only that the Xprint folks have been running into this problem
before as they had to deal with customers while everything else is still rather
experimental and has not hit the mainstream user yet.
Therefore I don't think you should be worried too much ;-)

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.