[getdns-api] Capability and version checking

Phil Pennock getdns-api-phil at spodhuis.org
Mon Jan 28 19:36:52 MST 2013


On 2013-01-28 at 17:36 -0800, Paul Hoffman wrote:
> On Jan 28, 2013, at 5:08 PM, Phil Pennock <getdns-api-phil at spodhuis.org> wrote:
> > I'm not seeing guaranteed compile-time constants for detecting
> > compile-vs-runtime differences?
> 
> Please say more about these differences.

% exim -d --version
Library version: SQLite: Compile: 3.7.14
                         Runtime: 3.7.14.1

More generally, you're currently documenting an API, not an ABI.  A
release change could move something to be a macro around a function with
a different name and the API would be preserved.

In theory, there would be a .so version bump.  In practice: that doesn't
always happen, especially if folks are building from source and don't
have OS packagers watching out for this and doing forced reversioning
for them, as folks like Debian do when this problem arises.

Most of our user-reported problems have come from OpenSSL, which is why
that was the first library for which I added this reporting, years ago,
and then more recently made it generic for any library I could find.
OpenSSL has often managed to preserve API without preserving ABI.  Most
recently that comes to mind, 1.0.1a to 1.0.1b changed the value of
SSL_OP_NO_TLSv1_1.  They needed to change it, the value used in 1.0.1a
was a mistake, but it meant that I've had to explicitly warn folks away
from the 1.0.1a release in README.UPDATING.

Generally, I view the cost/price of adding macro constants to be very
low and the gain to be high, as it quickly isolates what has or has not
changed and makes problem diagnosis faster.  In the above, I'm running
with Exim built against sqlite 3.7.14 but am running 3.7.14.1; if sqlite
calls started failing (unlikely, stable well-managed ABI), that would
point me to a recompile as the first test to see if that fixes issues
and whether it did or not, I'd have more data to go on.

> Would a PTR lookup on 127.0.0.1 be sufficient for you? If so, I can
> add that in as the suggested way to get the information at startup.

Sure.

-Phil


More information about the getdns-api mailing list