packaging jack - details on "plan B"

[Gabriel M. Beddingfield]

On Sun, 25 Apr 2010, Jonas Smedegaard wrote:

> I notice, though, that above links only mention API, not ABI.  Is it safe to 
> expect library ABI (runtime linkage) to be frozen too if its API (compile 
> time interface) is?

Answer from upstream:

Date: Mon, 26 Apr 2010 09:34:26 -0400
From: Paul Davis <paul at linuxaudiosystems.com>
To: Gabriel M. Beddingfield <gabrbedd at gmail.com>
Cc: Jack-Devel <jack-devel at lists.jackaudio.org>
Subject: Re: [Jack-Devel] packaging jack - details on "plan B" (fwd)

On Mon, Apr 26, 2010 at 9:20 AM, Gabriel M. Beddingfield <gabrbedd at gmail.com> wrote:

Jack Devs:
>
> Please see the below e-mail (from debian packaging list) where Jonas would
> like a clarification about Jack's ABI compatability.  I'm sure the answer is
> "yes"... but I wanted to check with you guys one more time.
>

he asked "I notice, though, that above links only mention API, not ABI.  Is
it safe to expect library ABI (runtime linkage) to be frozen too if its API
(compile time interface) is?"

I think that the answer is "yes". Certainly I am not aware of any cses where
switching from one version of JACK to another has caused ABI issues. We've
never had it as a hard, explicit rule that development would follow this
rule, but its always been an implicit goal and is a fairly natural
consequence of the development pattern for JACK.

again, this clearly only applies in the "upward" case - ABI
back-compatibility has never been assured - if a program was linked against
JACK API M.N.m and the runtime installation is a version earlier than that,
there may be problems as you noted. the new rules on weak symbols post the
0.118.0 API should help address this.

--p