[poppler] poppler 0.5.3 and soname policy
Kristian Høgsberg
krh at bitplanet.net
Tue May 30 23:25:50 PDT 2006
Hello,
So even for all the bugs fixed in the 0.5.2 release, it was pretty
much a disaster; the splash backend broke, the Qt4 wrapper was missing
a file and type3 font support in the cairo backend got botched because
of my accidental commit of some experimental code. Those changes have
been reverted now, and Jeff even managed to land a fix for #4030 in
the short time since 0.5.2, so with that I give you poppler 0.5.3:
- Add poppler as a private requires of poppler-glib.
- Allow CairoFont creation to fail more gracefully (#4030).
- Back out the rest of krh's type3 font work.
- Revert splashModeRGB8 changes.
- Add missing poppler-annotation-helper.h.
Available from
http://poppler.freedesktop.org/poppler-0.5.3.tar.gz
Also, prompted by #7054, let me just explain the poppler ABI+soname
policy: poppler installs a number of .so files depending on how it's
configured. libpoppler.so is the core PDF rendering code and is
always installed, libpoppler-glib.so, libpoppler-qt.so and
libpoppler-qt4.so are wrapper libraries for glib, qt and qt4,
respectively. The reason for doing the wrapper libraries is that xpdf
was never designed with a application / library split in mind. All
implementation details are exposed in the xpdf header files we
(optionally) install under $prefix/include/poppler, and chances are
that any security fix, regular bug fix or new feature will add or
remove virtual functions or class members, thus breaking the ABI.
The wrappers are designed so as to hide away the implementation and
provide a small maintainable API and ABI, where we actively select
what to expose and how. This shields applications from changes in the
xpdf core code and allows us to realistically provide a guarantee that
the ABI wont change during a stable release series.
On the flip-side, we can't really commit to any kind of API guarantee
for libpoppler.so. Ideally, though we should at least bump the soname
for libpoppler.so when we break the API, but this is problematic.
Thanks to the wonders of libtool, applications that just want to link
to a wrapper library end up also linking to libpoppler.so, and so, if
the libpoppler.so soname is bumped it will break those applications.
So until we figure out how to make this work, API breakage in
libpoppler.so will not get soname bumps. Suggestions welcome.
cheers,
Kristian
More information about the poppler
mailing list