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.hExactly. 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.htmlDon'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
signature.asc
Description: Digital signature
_______________________________________________ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
