ABI change in libxft2 and libfreetype6's broken shlibs
Hello libxft maintainers and release managers,
I've been following the development of font related library packages in
Debian, as some of the new features in the recent upstream releases are
important for rendering CJK fonts. So I'm quite happy to see xft
2.1.8.2 entered unstable a few days ago.
However I also noticed that with the current library dependency
handling, the API/ABI changes in the new libxft2 library (the new
features I was looking at) could break testing soon. So I feel I should
raise the alarm here. As I have the tendency of being overly verbose,
let me show the problem first:
On unstable with libfreetype6 2.1.10-1 and libxft2 2.1.8.2-1:
$ objdump -T /usr/lib/libXft.so.2.1.2 | grep "FT_GlyphSlot"
00000000 DF *UND* 0000016b FT_GlyphSlot_Embolden
$ objdump -T /usr/lib/libfreetype.so.6.3.8 | grep "FT_GlyphSlot"
00013d50 g DF .text 0000016b Base FT_GlyphSlot_Embolden
00013cf0 g DF .text 0000005d Base FT_GlyphSlot_Oblique
On sarge with libfreetype6 2.1.7-2.4 and libxft2 2.1.7-1 (testing has
the same versions):
$ objdump -T /usr/lib/libXft.so.2.1.2 | grep "FT_GlyphSlot"
$ objdump -T /usr/lib/libfreetype.so.6.3.5 | grep "FT_GlyphSlot"
(no such symbols in both libraries)
As everybody should already know, freetype's ABI has been changing
wildly from release to release. In this case the related are two new
public functions "FT_GlyphSlot_*" (not in private header, which means
endorsed by upstream) added after freetype 2.1.7. From what I heard,
xft 2.1.7 already had functions that use this API, but it's optional,
and as libxft2 2.1.7-1 was compiled against libfreetype6 2.1.7 (or
earlier), it didn't end up using it. Now unstable has the new
libfreetype6 2.1.10 with such API, when the new xft 2.1.8.2 is built, it
picked up the new API and start using it (it would also happen if we
rebuild the same 2.1.7, as I understand).
So far, no big deal. However besides all the problem libfreetype6 has
(exporting symbols that was intended for private use only, then dropping
and renaming these functions), it also doesn't handle the shlibs
correctly. The currenly libfreetype6 package still has only >= 2.1.5-1,
but it's ABI has changed a lot since 2.1.5-1 (I mentioned this in
#316031). Now libfreetype6 2.1.10-1 is held out of testing for good
reason, libxft2 can slip into testing because of this broken shlibs, but
it uses symbols only available in libfreetype6 2.1.10-1.
I don't know if any other packages are using this feature in libxft2,
but I suppose there is, as the Chinese users are constantly discussing
about the changes this new feature brings. I am even not sure it's as
serious as I think it is, but I believe you are more knowledgable than I
am to decide this, I just want to bring it to your attention. I also
remember similar thing happend for cairo before.
I'm cc:ing #314385 as that seems to be the "libfreetype6 is broken"
blanket bug now. There probably should be a bug filed against libxft2,
but as I said I am not quite sure what sure be done here, I'm not doing
it yet.
(An unrelated issue: it seems strange to me that both 2.1.7 and 2.1.8.2
version of xft build libxft.so.2.1.2. Shouldn't the version number of
the shared library at least change a little bit?)
Thanks for reading this long mail, and also for the great work you've
been doing.
Best wishes,
Ming
2006.01.24
Reply to: