[Xorg] CVS HEAD -- ftfuncs.c:931: error: structure has nomembernamed `find_sbit_image'

[Owen Taylor]

On Tue, 2004-08-03 at 09:57, Egbert Eich wrote:
> Owen Taylor writes:
>  > On Tue, 2004-08-03 at 04:27, Egbert Eich wrote:
>  > > Owen Taylor writes:
>  > >  > It won't overwrite the distribution's version, no. It *will* cause the
>  > >  > person to submit a Pango bug report 6 months from now because configure
>  > >  > tests are running against one libfreetype and Pango is linking against
>  > >  > the other, or because Pango is linking against one libfreetype and
>  > >  > running against the other, or some other weirdness that the user has
>  > >  > no chance at all of being able to debug correctly.
>  > >  > 
>  > > 
>  > > Thinking about this issue some more:
>  > > 
>  > > In the past FreeType has broken binary compatibility more than once. 
>  > > We may be able to help educate them in for the future but we cannot 
>  > > change the past.
>  > 
>  > It should be noted that ftfuncs.c is including *internal* FreeType
>  > headers, and I believe that changes in these headers are what
>  > caused these problems. The main education that the FreeType developers
>  > perhaps need is that if you install internal headers people will use
>  > them.
> 
> We removed the dependency on internal headers. 

Really? I still see the inclusion in:

http://freedesktop.org/cgi-bin/viewcvs.cgi/xorg/xc/lib/font/FreeType/ftfuncs.c?rev=1.5&view=auto

> However the question
> arises what is an internal header. If you install a header in 
> /usr/include/... it is no longer internal.

And if you install a header into
/usr/include/freetype2/freetype/internal/?

While I wouldn't recommend installing internal headers, I think if
an application does:
 
#include FT_INTERNAL_TRUETYPE_TYPES_H

They are definitely asking for trouble.

>  > (Pango also uses internal headers but with implicit acceptance of
>  > the risk that if you upgrade FreeType you may also need to upgrade
>  > Pango.)
> 
> This issue should be fixed with the freetype folks. If interfaces are
> exposed thru the headers in /usr/include/.. they should not be considered
> internally. If one needs the freetype sources (we did prior to X.Org 6.7)
> to build because he needs a header file that doesn't get installed,
> one should talk to FreeType to make this information public.
> That's what Chisato did.

The Pango question is a little different - Pango includes a big hunk of
table reading code from FreeType 1 ported to Pango 2. The plan is to get
it back into the FreeType project, but that's a long term thing. 
Anyways, not really the subject here...

>  > > This however means that it is not possible to install a later version
>  > > of libfreetype without requiring that all applications that build on it
>  > > need rebuilding.
>  > 
>  > In general I don't think that's a problem.
> 
> What do you mean?
> You don't think it is a problem for the average user if he has to
> rebuild half of the packages he has installed.

I don't think that the rebuilding half the packages installed is
will be necessary. FreeType-2.0 => FreeType-2.1 might have required
rebuilding Pango (I don't recall at this point.) I'm pretty sure
we didn't need to rebuild anything else in the distribution.
And no other upgrades of FreeType required rebuilding packages.

[...]

>  > > This begs the question what we should do:
>  > > 
>  > > I can think of three solutions:
>  > > 
>  > > 1. We add more ifdefs to support earlier versions of freetype.
>  > >    The code can be build against the installed version of the lib
>  > >    and nothing needs to be updated.
>  > 
>  > If you can manage this, this is by far the best. The other thing
>  > I'd strongly advise is figuring out how to avoid using internal
>  > headers in xorg.
> 
> Then we probably should go further back than 2.1.7 as there are still
> many systems installed that use earlier versions of libfreetype.
> 
>  > 
>  > > 2. We ask the freetype folks to use ELF symbol versioning to provide
>  > >    ABI compatibility to earlier versions. This way FreeType has the 
>  > >    trouble and we can keep our code relatively clean.
>  > 
>  > The problem here is changes to internal structures ... not something
>  > that is easily worked around with symbol versioning.
> 
> Then this begs the question why people have to access internal structures
> and why they are exposed thru external headers in the first place.

Well if you look at why ftfuncs.c is using internal headers, I think
it's because new functionality was written as if it was part of 
FreeType - probably so it could be submitted as an addition to FreeType.

We could certainly campaign to have FreeType move more stuff to the
public supported API... to make FreeType a more extensible library.
But I think new functionality is seldom going to be *required* for X,
so a better approach is probably:
 
 - When new functionality is useful, submit a patch to freetype to
   add that functionality.
 - Add conditionalization to X to use that functionality when
   there and fallback when not.

>  > > 3. FreeType bumps the major version number and assures that new versions
>  > >    of their lib will provide binary compatibility as long as this major
>  > >    version number is in use. This will not solve really solve the problems
>  > >    of the past but it allows the user to install a new version of freetype
>  > >    and build against it while still keeping the original one for all
>  > >    older applications.
>  > 
>  > I think if you eliminate uses of internal headers in X the FreeType
>  > maintainers will have no trouble guaranteeing compatibility...
>  > 
>  > The problems I've generally seen with installing new versions of
>  > FreeType aren't backwards compatibility problems but straightforward
>  > problems from having multiple versions of FreeType around. These
>  > are going to occur whether X is installing its copy of FreeType
>  > in /usr/X11R6/lib or the user installs one into /usr/local/lib.
>  > 
> 
> I can see a problem when the later one is used during build while the
> earlier version is used during run time.
> The other way around shouldn't be a problem provided the backward
> compatibility issue is resolved.

If the mismatch happens the right way, there's no problem. But it
happens the wrong way roughly 50% of the time...

>  > [ I'll certainly loudly oppose the motion if you encourage the FreeType
>  >   maintainers to bump the major version number :-). That would be
>  >   a horrible pain for distributors ]
>  > 
> 
> This has happend with other libs before and has forced distributors to
> ship old versions of these libs along with the newest ones anyhow.

Yes, but usually major version number changes go along with significant
API changes. A new major version of a library more than doubles the
maintenance for distributions (I have to *backport* fixes to the
old version...). Having that cost for no real gain isn't pretty.

Regards,
						Owen

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://lists.x.org/archives/xorg/attachments/20040803/89cccc54/attachment.pgp>