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

http://freedesktop.org/cgi-bin/bugzilla/show_bug.cgi?id=438 would require
freetype 2.1.8 version bump too

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.

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...

Taking bug... I'll try my luck...

Created attachment 246 [details] [review]
Patch part #1

Created attachment 247 [details] [review]
Patch part #2

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.

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.

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.

I forgot to mention that I don't have real good access to my cvs trees right now.

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" ?

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.

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...

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 ;-)