[Xorg] CVS HEAD -- ftfuncs.c:931: error: structure has nomembernamed `find_sbit_image'
daniel at freedesktop.org
Tue Aug 3 09:47:03 PDT 2004
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.
> 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.
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.
> 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
> 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...
Size: 189 bytes
Desc: Digital signature
More information about the xorg