[Poppler-bugs] [Bug 7054] Fix #4481 for broke ABI

[bugzilla-daemon at freedesktop.org]

http://bugs.freedesktop.org/show_bug.cgi?id=7054





------- Comment #10 from lool+freedesktop at via.ecp.fr  2007-05-31 08:52 PST -------
(In reply to comment #8)
> I'm talking about upgrade compatibility on the same system.

That doesn't change on OSX: each time the ABI breaks, the SONAME changes, and
you have to rebuild everything deping on libpoppler directly (or indirectly on
OSX).  The change is required because if you don't change the SONAME when the
ABI changes, some apps will fail to run, but you will only discover when
running them.

> If I compile my project against /usr/local/lib/libpoppler.1.dylib (or whatever
> the current soname is) and you change ABIs without upping the soname version,
> then my app will no longer run when libpoppler gets updated.  Even if it's an
> indirect dependency from poppler-glib, because my app will have
> "/usr/local/lib/libpoppler.1.dylib" in it's dependencies which are hardcoded
> into the application's binaries (Mach-O preserves the semi-equivalent of RPATH
> always).

Hmm don't get me wrong: I am personally in favor of changing libpoppler's
SONAME each time the ABI change!  But I still would like applications using
libpoppler indirectly to not suffer from the changes by not being linked to
libpoppler (even if that's not possible on OSX).

> As long as you intend to only support ELF platforms (or whatever platforms
> allow indirect linking), this will work.  If you want to support other
> platforms, it will cause binary incompatibility.

That's a pkg-config or libtool problem to solve; by using .private pkg-config
headers, pkg-config should include headers in all cases and include libs only
when linking statically or on platforms not capable of indirect deps.

> As another person suggested, using -release works as well, although it's ugly.

Yeah, I did suggest that :)

> It means that every release of poppler would have to be packaged with it's own
> runtime shared-library package that can never be removed until all things that
> depend on it are removed, but at least it preserves compatibility across
> upgrades.

Exactly; safest but most painful bet -- not so painful if you don't have to
link recursively.


-- 
Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.