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

[Owen Taylor]

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.

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

> We agree that installing a different version of libfreetype (with the
> same major version number) into another directory calls for trouble.
> 
> There seems to be a consense that linking against libfreetype statically
> is a bad idea as security fixes would require to rebuild any application.
> (Which may have to be done anyway if one chooses to supply fixes by 
> providing a later version of the lib).
> 
> 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.

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

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

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

Regards,
						Owen

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

-------------- 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/9eb7bc3d/attachment.pgp>