On Thu, Apr 8, 2010 at 12:50, Reinhard Tartler <siret...@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 _______________________________________________ pkg-multimedia-maintainers mailing list email@example.com http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers