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

[Daniel Stone]

On Tue, Aug 03, 2004 at 10:27:07AM +0200, 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.

Right. I think they got the point after 2.1.6/2.1.7, however.

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

... later than a few versions.

> We agree that installing a different version of libfreetype (with the
> same major version number) into another directory calls for trouble.

Yes.

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

Yes, and that reasoning is also true for having a separate shared
library, as well.

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

Yes.

That means that if they have 2.1.6, then it gets built against 2.1.6,
and everyone's happy. If they have 2.1.8, good for them.

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

Yay, yes.

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

(Or stop breaking ABI?)

After 2.1.6/2.1.7, I don't think they're in a hurry to change ABI any
time soon.

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

That would be nifty, but it gets messy. In particular, I think libgal is
already up to soversion 20.x.x or something.

-- 
Daniel Stone                                            <daniel at freedesktop.org>
freedesktop.org: powering your desktop                http://www.freedesktop.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.x.org/archives/xorg/attachments/20040804/84a16045/attachment.pgp>