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 <p...@linuxaudiosystems.com> To: Gabriel M. Beddingfield <gabrb...@gmail.com> Cc: Jack-Devel <jack-de...@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 <gabrb...@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 _______________________________________________ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
