Possible JACK ABI changes between 0.118 and 1.9.5

Jonas Smedegaard dr at jones.dk
Thu Apr 8 16:11:39 UTC 2010


On Thu, Apr 08, 2010 at 02:34:37PM +0200, Reinhard Tartler wrote:
>On Thu, Apr 08, 2010 at 13:06:18 (CEST), Adrian Knoth wrote:
>
>> On Tue, Apr 06, 2010 at 07:29:51AM +0200, Reinhard Tartler wrote:
>>
>>> >>>> Can someone fluent in C/C++ please look at this?  Perhaps you, 
>>> >>>> Adrian, since you seem most knowledgeable in JACK around here?
>>> I think I qualify.
>>
>> I'm not sure if I do. ;) Never used the debian symbol files...

I did not expect you to understand the symbol file mechanism, but the 
underlying library symbols that are extracted by that mechanism.

What I believe to have understood but is beyond me to work further on 
(and that I am hoping you guys could help with) is that C++ code (and C 
too?) should be able to mark a symbol as private - which the Debian 
symbol mechanism would then respect.

Even if upstream do not maintain such hints, I would be willing to work 
on applying them as a patch to the Debian packaging, based on canonical 
documentation (i.e. Doxygen-generated documentation, apparently).  But I 
need someone to help educate me on the syntax of such hints, and whether 
or not aplying those could affect the resulting code badly (except off 
course hinting wrongly, so parts of the public API gets hidden).

I cannot code C or C++, but I can skim code, merge known patterns, and 
juggle patch files. :-)


>>> Another source of problem is that presence of machine optimization. 

Commenting on that separately, with changed subject line...



>>> What symbols are supposed to be exposed by libjack? I suppose only 
>>> globals and functions defined in these files are part of this:
>>>
>>> /usr/include/jack
>>> /usr/include/jack/intclient.h
>>> /usr/include/jack/jack.h
>>> /usr/include/jack/ringbuffer.h
>>> /usr/include/jack/statistics.h
>>> /usr/include/jack/thread.h
>>> /usr/include/jack/timestamps.h
>>> /usr/include/jack/transport.h
>>> /usr/include/jack/types.h
>>> /usr/include/jack/midiport.h
>>
>> Exactly. That's the list each client application relies on.
>>
>>> But is there perhaps a more canonical list?
>>
>> There is doxygen output available:
>>
>>    http://jackaudio.org/files/docs/html/index.html
>>
>> Don't know if this qualifies as "more canonical", but this file also 
>> refers to the above header files as "the full API"
>
>Well, I think this counts as canonical list.

ok.


>> Is there more I could do?
>
>I think as long upstream not even makes efford to hide symbols not 
>defined in the JACK API as published at 
>http://jackaudio.org/files/docs/html/index.html, I don't think it makes 
>sense to think about symbol files. Ideally, every line in the symbol 
>file corresponds directly to an API function or global, but this is 
>much work that I don't think can be sensibly finished before squeeze 
>release.
>
>Next steps (just opinion):
>
> - revert the symbol files change
> - upload to experimental ASAP
> - test-rebuild applications against jack2
> - in paralell: review the license issues
> - upload to unstable if all OK

I will not revert the symbol file change, but weaken them to only cause 
warnings (not build failure), when changing.

And yes, if you coding experts (compared to me) consider the symbol 
differences between 1.1.x and 1.9.x not worrying, then I will proceed 
with releasing the current packaging, and postpone polishing the symbol 
file handling till later :-)

If I run into no more problems then I see no problem in releasing 
directly to unstable.  I.e. no need to first do experimental build.

More opinions quite welcome!


  - Jonas

-- 
* Jonas Smedegaard - idealist & Internet-arkitekt
* Tlf.: +45 40843136  Website: http://dr.jones.dk/

  [x] quote me freely  [ ] ask before reusing  [ ] keep private
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.alioth.debian.org/pipermail/pkg-multimedia-maintainers/attachments/20100408/92db4f5b/attachment.pgp>


More information about the pkg-multimedia-maintainers mailing list