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

[Egbert Eich]

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. However the question
arises what is an internal header. If you install a header in 
/usr/include/... it is no longer internal.

 > 
 > (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.
 > 
 > > 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.
Or 
Normally upgrading of a library like freetype should not be required.


 > > Effectively this means that it is impossible to build components of
 > > X on a system with with freetype version x that have a dependency on
 > > a version y with y > x.
 > 
 > I wouldn't really agree with that. Upgrading a core system library
 > like FreeType isn't something you want to ask the user to do lightly...
 > but it could be done.

Right. It would be easier if the ABI compatibility issue was resolved.

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

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

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

Cheers,
	Egbert.