Possible JACK ABI changes between 0.118 and 1.9.5

[Felipe Sateler]

On Thu, Apr 8, 2010 at 12:50, Reinhard Tartler <siretart at tauware.de> wrote:
> 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.

According to bug #563752, dpkg-gensyms understands them.

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

I agree here. Symbol tracking does not make sense when the
signal/noise ratio is too high, as in this case.

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

Not really, because we are dropping jack1.

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

Painful, error-prone and superfluous. Shlibs files are enough for the
relatively stable jack API, IMO.


-- 

Saludos,
Felipe Sateler