Possible JACK ABI changes between 0.118 and 1.9.5

[Reinhard Tartler]

On Thu, Apr 08, 2010 at 18:11:39 (CEST), Jonas Smedegaard wrote:

> 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.

I've been investigating symbol files for FFmpeg, which doesn't really do
symbol hiding as well. My conclusion was to not use symbol files of
several reasons (the most important one doesn't apply to jack, but
anyway)

For C++ libraries, I don't see any point in using symbol files until
dpkg-gensyms understands unmangled symbols. Working on demangled symbol
is just too painful IMO.

For jack, I think the amount of symbol files is just too much ATM.
First, I'd strongly suggest to hide the symbols.

> 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've done so for FFmpeg 0.6 by introducing a versioning script. While
symbol versioning is currently not necessary, I think we can use the
mechanism for jack as non-invasive technique as well. AFAIR, it is
possible to mark symbols without version tags, so we should be able to
retain full binary compatibility with other distros.

If versioning script is not going to work for some reason, the other
option is to extend the compilations flags to not export ANY symbols by
default, and extend the public .h files to only export those functions
and globals that are mentioned in the doxygen documentation. As this
work is really tedious and hard to get right, I'd strongly suggest to do
this work upstream; which means two upstreams in this case. :/

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

Strong C/C++ skills are IMO absolutely necessary for properly
maintaining symbol files.

>>> 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.
>
I don't see anything in the jack documentation that would warrant
architecture specific symbol files. This means that some warnings will
always appear on symbols that should be hidden.

> 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 :-)

That's really hard to tell with that much noise. That noise also makes
maintaining the symbol files in future unnecessary hard for my taste.

> 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.

Well, we can do so as well, but I don't think we can use symbol files
here as safety guard to check ABI compatibility. That's why I suggested
to go via experimental.

However, if someone already did a test rebuild of all packages that
build-depend on libjack-dev with jack2, then I agree that we should go
via unstable directly.

-- 
Gruesse/greetings,
Reinhard Tartler, KeyID 945348A4