Mark Michelson wrote: > I started thinking about this and I'm not sure how you can check for this at > configure-time or build-time. While it would be easy to check what gcc > version > is being used, it is not so easy (dare I say, not possible) to see if > gsm-formatted sounds are going to be used in this setup. Besides the fact > that > core sounds are not placed on the system until make install is run, we can't > know if there are out-of-tree gsm-formatted sound files which will be used, > too. > Did you have something clever in mind for such a check?
I would approach this an entirely different way: if the system exhibits this problem, then building codec_gsm will produce a module that cannot properly encode (or decode, whichever direction is the issue) GSM streams. It does not matter whether the user plans to use GSM or not; if we tell them their system cannot build a non-broken codec_gsm, and they don't plan to use GSM, then they can disable it and not have to worry about it. If, however, they plan to, or might, use GSM (whether it is sound files or audio streams does not matter), then they will need to address this issue or they could have audio corruption. If we know which specific piece of assembly code is incorrectly compiled or optimized in the GSM library and causes this problem, it is conceivable we could write a configure script test that compiles that same code, runs a test, and checks the output. We avoid writing configure script tests that check for version numbers whenever possible, it's much more reliable to check for the specific feature (or bug) that we are concerned about, because distros frequently backport and forwardport patches, so the version numbers become unreliable. With all that said; if the current releases of Asterisk have a functional workaround for this problem, and users who have this problem can just update to the latest release and the problem will go away, then we need to just write a specific announcement to that effect. The only reason any configure script checking would be needed is if the problem still exists and we cannot fix it in the Asterisk source code. -- Kevin P. Fleming Digium, Inc. | Director of Software Technologies 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA skype: kpfleming | jabber: kpflem...@digium.com Check us out at www.digium.com & www.asterisk.org _______________________________________________ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users