Re: Possible JACK ABI changes between 0.118 and 1.9.5
On Thu, Apr 08, 2010 at 23:25:25 (CEST), Felipe Sateler wrote: We only _assume_ JACK API to be stable - yet we track upstream VCS so should not be certain IMO. The jack API as defined by the doxygen documentation is AFAIUI fairly stable. The exported ABI seems not. The _intended_ exported ABI seems, though. Which is what matters, after all. Applications that use non-public APIs should be considered buggy. -- Gruesse/greetings, Reinhard Tartler, KeyID 945348A4 ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: Possible JACK ABI changes between 0.118 and 1.9.5
On Fri, Apr 09, 2010 at 00:13:59 (CEST), Adrian Knoth wrote: On Thu, Apr 08, 2010 at 05:55:52PM -0400, Felipe Sateler wrote: I've looked a bit into the hiding thing... and jack2 seems to export 2 kinds of symbols. It exports weak symbols (the standard API), and exports several other symbols as default visibility. I'm guessing that Have you seen this comment in jack.h? /* * NOTE: JACK_WEAK_EXPORT ***MUST*** be used on every function * added to the JACK API after the 0.116.2 release. * * Functions that predate this release are marked with * JACK_WEAK_OPTIONAL_EXPORT which can be defined at compile * time in a variety of ways. The default definition is empty, * so that these symbols get normal linkage. If you wish to * use all JACK symbols with weak linkage, include * jack/weakjack.h before jack.h. */ is there a rationale for this? I can guess some reasons, but certainity would help. -- Gruesse/greetings, Reinhard Tartler, KeyID 945348A4 ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: Possible JACK ABI changes between 0.118 and 1.9.5
On Fri, Apr 09, 2010 at 08:25:43AM +0200, Reinhard Tartler wrote: /* * NOTE: JACK_WEAK_EXPORT ***MUST*** be used on every function * added to the JACK API after the 0.116.2 release. * * Functions that predate this release are marked with * JACK_WEAK_OPTIONAL_EXPORT which can be defined at compile * time in a variety of ways. The default definition is empty, * so that these symbols get normal linkage. If you wish to * use all JACK symbols with weak linkage, include * jack/weakjack.h before jack.h. */ is there a rationale for this? I can guess some reasons, but certainity would help. 12:22 torbenh3 adi: it provides binary compatibility of an app built against a higher version of jack against a 0.116.2 jack. 12:24 torbenh3 in other words. a session enabled program will not complain if you downgrade to 0.116.2 .. (you just wont have session support) Cheerio -- mail: a...@thur.de http://adi.thur.de PGP/GPG: key via keyserver ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: Possible JACK ABI changes between 0.118 and 1.9.5
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? Adrian, is there a jackd ABI definition? 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 But is there perhaps a more canonical list? Moreover, I see some functions marked as JACK_DEPRECATED in jack.h. Are they still used by applications and does jack2 still provide them? Ping! - 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
Re: Possible JACK ABI changes between 0.118 and 1.9.5
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...
Another source of problem is that presence of machine optimization. In
your buildlog I see symbols that indicate sse2 enabled functions. Has
anyone made sure that jackd2 really works on non-sse2 enabled machines?
I haven't checked, yet, but I have a Debian 486 machine around, so I
could try it. ;) Or I disassemble the library and check for SSE
instructions.
As long as nobody is calling -msse2 with the appropriate arch/cpu
definition, no SSE2 enabled code would be compiled.
(JFTR: SSE2 is available on all amd64 platforms)
Adrian, is there a jackd ABI definition?
No.
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
Moreover, I see some functions marked as JACK_DEPRECATED in jack.h.
Are they still used by applications and does jack2 still provide them?
The deprecated functions are still provided and even used by
jackd{1,2}'s example clients. ;)
This surely needs fixing, but that's upstream's responsibility. I'll
file a ticket and provide some patches.
Is there more I could do?
--
mail: a...@thur.de http://adi.thur.de PGP/GPG: key via keyserver
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: Possible JACK ABI changes between 0.118 and 1.9.5
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 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
Re: Possible JACK ABI changes between 0.118 and 1.9.5
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 ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: Possible JACK ABI changes between 0.118 and 1.9.5
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 pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: Possible JACK ABI changes between 0.118 and 1.9.5
On Thu, Apr 08, 2010 at 19:24:23 (CEST), Felipe Sateler wrote: 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. yes, these changes look very promising, but are not in unstable (yet), and won't make it into ubuntu lucid :-( 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. probably needless to say, but I agree. -- Gruesse/greetings, Reinhard Tartler, KeyID 945348A4 ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: Possible JACK ABI changes between 0.118 and 1.9.5
On Thu, Apr 08, 2010 at 01:24:23PM -0400, Felipe Sateler wrote: On Thu, Apr 8, 2010 at 12:50, Reinhard Tartler siret...@tauware.de 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. I agree that the *switch* from 1.1.x to 1.9.x is noisy, I raised that as a concern, Reinhard have checked it out and judged it as not worrying, and I am satisfied with that. I do not expect similar noise from here on. If more noise occur due to applied VCS patching, I would want to know, as we then might accidentally include upstream API-breaking changes too new for next upstream stable release. 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. We only _assume_ JACK API to be stable - yet we track upstream VCS so should not be certain IMO. Regards, - 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
Re: Possible JACK ABI changes between 0.118 and 1.9.5
On Thu, Apr 8, 2010 at 15:17, Jonas Smedegaard d...@jones.dk wrote: On Thu, Apr 08, 2010 at 01:24:23PM -0400, Felipe Sateler wrote: On Thu, Apr 8, 2010 at 12:50, Reinhard Tartler siret...@tauware.de 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. I agree that the *switch* from 1.1.x to 1.9.x is noisy, I raised that as a concern, Reinhard have checked it out and judged it as not worrying, and I am satisfied with that. I do not expect similar noise from here on. If more noise occur due to applied VCS patching, I would want to know, as we then might accidentally include upstream API-breaking changes too new for next upstream stable release. The problem is that when the internal implementation changes, you will get more noise. As an aside, the symbols file is not to ease tracking of symbol changes for the maintainer, but for the packaging system. You need to know *before* applying a patch whether it will take an update to the symbols file, and why. 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. We only _assume_ JACK API to be stable - yet we track upstream VCS so should not be certain IMO. Of course we cannot be certain. But our job as package maintainers is to track that and let the packaging system know, not the other way around. Before merging from upstream you (as in a generic you, the person doing the merge) need to know what API and ABI changes it will contain. And for tracking a relatively stable and noisy library like jack, a shlibs file is enough. The noisy part is important because the packaging system (and perhaps the maintainer) might get confused by the irrelevant symbols. -- Saludos, Felipe Sateler ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: Possible JACK ABI changes between 0.118 and 1.9.5
On Thu, Apr 08, 2010 at 21:17:58 (CEST), Jonas Smedegaard wrote: I agree that the *switch* from 1.1.x to 1.9.x is noisy, I raised that as a concern, Reinhard have checked it out and judged it as not worrying, and I am satisfied with that. It seems we are miscommunicating, I don't remember such a statement. I do not expect similar noise from here on. If more noise occur due to applied VCS patching, I would want to know, as we then might accidentally include upstream API-breaking changes too new for next upstream stable release. We seem to talk about different kind of noise. I'm talking about the lines in the symbol files that correspond to symbols that are not part of the export jack API. They will be around until symbol hiding is implemented. We only _assume_ JACK API to be stable - yet we track upstream VCS so should not be certain IMO. The jack API as defined by the doxygen documentation is AFAIUI fairly stable. The exported ABI seems not. -- Gruesse/greetings, Reinhard Tartler, KeyID 945348A4 ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: Possible JACK ABI changes between 0.118 and 1.9.5
On Thu, Apr 8, 2010 at 17:22, Reinhard Tartler siret...@tauware.de wrote: We only _assume_ JACK API to be stable - yet we track upstream VCS so should not be certain IMO. The jack API as defined by the doxygen documentation is AFAIUI fairly stable. The exported ABI seems not. The _intended_ exported ABI seems, though. -- Saludos, Felipe Sateler ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: Possible JACK ABI changes between 0.118 and 1.9.5
I've looked a bit into the hiding thing... and jack2 seems to export 2 kinds of symbols. It exports weak symbols (the standard API), and exports several other symbols as default visibility. I'm guessing that the default symbols are part of the libjackserver API, but for some reason some of them are getting leaked into the client API. -- Saludos, Felipe Sateler ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: Possible JACK ABI changes between 0.118 and 1.9.5
On Thu, Apr 08, 2010 at 05:55:52PM -0400, Felipe Sateler wrote: I've looked a bit into the hiding thing... and jack2 seems to export 2 kinds of symbols. It exports weak symbols (the standard API), and exports several other symbols as default visibility. I'm guessing that Have you seen this comment in jack.h? /* * NOTE: JACK_WEAK_EXPORT ***MUST*** be used on every function * added to the JACK API after the 0.116.2 release. * * Functions that predate this release are marked with * JACK_WEAK_OPTIONAL_EXPORT which can be defined at compile * time in a variety of ways. The default definition is empty, * so that these symbols get normal linkage. If you wish to * use all JACK symbols with weak linkage, include * jack/weakjack.h before jack.h. */ HTH -- mail: a...@thur.de http://adi.thur.de PGP/GPG: key via keyserver ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: Possible JACK ABI changes between 0.118 and 1.9.5
On Mon, Apr 5, 2010 at 11:56, Jonas Smedegaard d...@jones.dk wrote: Hi, I have now switched JACK packaging to use symbols files, to automate tracking of ABI changes. The switch from 0.118 to 1.9.5 causes breakage in that automated tracking, however. snip Can someone fluent in C/C++ please look at this? Perhaps you, Adrian, since you seem most knowledgeable in JACK around here? Could you post the actual problems you found? Perhaps a diff of 0.118 symbols and 1.9.5? -- Saludos, Felipe Sateler ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: Possible JACK ABI changes between 0.118 and 1.9.5
On Mon, Apr 5, 2010 at 14:33, Jonas Smedegaard d...@jones.dk wrote: On Mon, Apr 05, 2010 at 01:37:27PM -0400, Felipe Sateler wrote: On Mon, Apr 5, 2010 at 11:56, Jonas Smedegaard d...@jones.dk wrote: I have now switched JACK packaging to use symbols files, to automate tracking of ABI changes. The switch from 0.118 to 1.9.5 causes breakage in that automated tracking, however. snip Can someone fluent in C/C++ please look at this? Perhaps you, Adrian, since you seem most knowledgeable in JACK around here? Could you post the actual problems you found? Perhaps a diff of 0.118 symbols and 1.9.5? Sorry. Sure. Attached is a build of current Git: I don't have the time right now to make a complete revision, but I looked over the list, and it seems to me that both jack1 and jack2 suck at hiding symbols. Anyway, all the missing symbols I looked at are not part of the jack API. -- Saludos, Felipe Sateler ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
