| 00:03.02 | *** join/#asterisk-dev pchero_work (~pchero@dhcp-077-249-058-090.chello.nl) |
| 00:23.11 | *** part/#asterisk-dev kharwell (kharwell@nat/digium/x-wuzekdxotwuzisqe) |
| 00:46.24 | coreyfarrell | file: I think I got it sort of working.. unfortunately busy and congested both result in AST_CONTROL_BUSY (apparently an issue with the dsp code) |
| 00:49.17 | *** join/#asterisk-dev tuxd00d (~tuxd00d@unaffiliated/tuxd00d) |
| 00:52.02 | *** join/#asterisk-dev stevedavies (~stevedavi@197.155.252.3) |
| 01:03.20 | *** join/#asterisk-dev stevedavies (~stevedavi@197.155.252.3) |
| 01:14.10 | *** join/#asterisk-dev stevedavies (~stevedavi@197.155.252.3) |
| 03:15.19 | *** join/#asterisk-dev stevedavies (~stevedavi@197.155.252.3) |
| 03:26.06 | *** join/#asterisk-dev stevedavies (~stevedavi@197.155.252.3) |
| 04:09.50 | *** join/#asterisk-dev opticron (~opticron@75.76.209.103) |
| 04:09.50 | *** mode/#asterisk-dev [+o opticron] by ChanServ |
| 05:27.48 | *** join/#asterisk-dev stevedavies (~stevedavi@197.155.252.3) |
| 06:03.49 | *** join/#asterisk-dev stevedavies (~stevedavi@197.155.252.3) |
| 06:14.46 | *** join/#asterisk-dev stevedavies (~stevedavi@197.155.252.3) |
| 06:25.07 | elcontrastador | Using Page() diaplan application, is there a limitation built into Asterisk for how many phones can be bridged? Is it just host resource limitations? I have potentially hundreds of phones...I use multicast with Cisco phones and it works perfectly...Polycoms do not work like that, I've found. |
| 06:42.45 | snuff-work | i'm not sure asterisk would like 100's |
| 06:49.22 | snuff-work | apparently you can do a multicast with page.. |
| 06:50.26 | snuff-work | i've never tried it myself, googling a bit suggests that polycoms of certain types support a multicast page.. |
| 06:52.30 | snuff-work | seems to show all the variables etc u'd need to set 'phone side'.. https://support.polycom.com/global/documents/support/technical/products/voice/Group_Paging_and_PTT_FP62327.pdf |
| 07:00.42 | snuff-work | page has a 'multicastRTP' that you could use.. but probably not 'basic' for polycom phones |
| 07:08.29 | snuff-work | i'm sure if u have the packet dumps or similar for a working polycom multicast page maybe someone might make the additional bits required for asterisk multicastRTP to work with it |
| 07:28.14 | *** join/#asterisk-dev stevedavies (~stevedavi@197.155.252.3) |
| 07:29.03 | *** join/#asterisk-dev pchero_work (~pchero@87.213.240.121) |
| 07:40.37 | *** join/#asterisk-dev jkroon (~jkroon@165.16.203.126) |
| 08:12.36 | pchero_work | Hi Asterisk team, do you guys think this is correct fix? I've submitted patch yesterday, but I put it as WIP. Because of, I couldn't make reproduce wrong RTT again somehow.. -_-;; https://gerrit.asterisk.org/#/c/asterisk/+/10993/ |
| 09:11.21 | *** join/#asterisk-dev stevedavies (~stevedavi@197.155.252.3) |
| 09:41.32 | *** join/#asterisk-dev stevedavies (~stevedavi@197.155.252.3) |
| 09:44.22 | *** join/#asterisk-dev pchero_work (~pchero@87.213.240.121) |
| 09:52.22 | *** join/#asterisk-dev stevedavies (~stevedavi@197.155.252.3) |
| 10:28.56 | *** join/#asterisk-dev stevedavies (~stevedavi@197.155.252.3) |
| 10:40.04 | *** join/#asterisk-dev stevedavies (~stevedavi@197.155.252.3) |
| 11:05.15 | *** join/#asterisk-dev stevedavies (~stevedavi@197.155.252.3) |
| 12:07.09 | pchero_work | Just question, is there any plan for move the rtpengine to the pjsip_media? |
| 12:07.25 | file | no |
| 12:07.39 | file | if something were to do such a thing, then it would be a separate module |
| 12:08.08 | pchero_work | file: So, Asterisk will keep stay to the rtpengine, ah, thanks. :) |
| 12:08.24 | file | if you mean res_rtp_asterisk - I know of noone working on or planning to replace it |
| 12:08.56 | pchero_work | Ah, yes. That's it. |
| 12:20.36 | *** join/#asterisk-dev sh_smith (~sh_smith@cpe-76-174-26-91.socal.res.rr.com) |
| 12:33.54 | *** join/#asterisk-dev stevedavies (~stevedavi@197.155.252.3) |
| 12:59.18 | *** join/#asterisk-dev stevedavies (~stevedavi@197.155.252.3) |
| 13:19.38 | tsearle | @file is smoother actually being used by native bridge? my impression was that it wasn't |
| 13:22.15 | file | you're probably right, but would it make more sense to drop the smoother once when the local bridge is started? |
| 13:22.43 | *** join/#asterisk-dev hehol (~hehol@gatekeeper.loca.net) |
| 13:24.55 | tsearle | thought about that, but since the smoother is so dependent on lasttxformat and in the other code path smoother is deleted when lasttxchanged, I figured keeping the nuke next to the update was better for code validation |
| 13:25.35 | file | if it's not used in the p2p path, then it would just get recreated when returned to the normal path, and should never be recreated while in p2p |
| 13:25.44 | file | so it would only need to be destroyed once |
| 13:26.32 | tsearle | I could wrap the nuke & the ao2_replace both with if (changed) |
| 13:26.58 | file | I basically try to avoid adding more stuff to high use paths if possible >_> |
| 13:31.17 | tsearle | ok, so move code to |
| 13:31.18 | tsearle | native_rtp_bridge_start |
| 13:33.09 | file | it'd be the local_bridge callback in res_rtp_asterisk |
| 13:36.25 | tsearle | ok, and there nuke the smoother on both instance0 and instance1 |
| 13:36.48 | tsearle | I guess locking instance1 when touching it |
| 13:39.21 | tsearle | ah no |
| 13:39.47 | tsearle | the call back will get called on both legs, so just need to focus on instance0 |
| 14:06.25 | *** join/#asterisk-dev cresl1n (uid299068@asterisk/libpri-and-libss7-expert/Cresl1n) |
| 14:06.25 | *** mode/#asterisk-dev [+o cresl1n] by ChanServ |
| 14:17.07 | tsearle | all done! :-) |
| 14:17.10 | tsearle | waves at cresl1n |
| 14:17.17 | cresl1n | hi! |
| 15:11.50 | *** join/#asterisk-dev kharwell (kharwell@nat/digium/x-eylhmynuuahtroyv) |
| 15:11.50 | *** mode/#asterisk-dev [+o kharwell] by ChanServ |
| 15:59.17 | *** join/#asterisk-dev rmudgett (rmudgett@nat/digium/x-hwhzccuqoqfrwnbz) |
| 15:59.17 | *** mode/#asterisk-dev [+o rmudgett] by ChanServ |
| 16:41.49 | coreyfarrell | anyone who deals with the binary modules feel free to disagree with me on the potential for ABI breakage at https://gerrit.asterisk.org/10939. CC rmudgett |
| 16:44.25 | gtjoseph | coreyfarrell: you may be correct. i think we missed the scenario where someone recompiles |
| 16:45.00 | gtjoseph | will need to think a bit |
| 16:46.32 | coreyfarrell | it's obscure but I think that change would force binary modules to be compiled against older versions, then they potentially miss out on bug fixes put into headers. |
| 16:48.22 | coreyfarrell | or the modules would have to say "requires asterisk 13.26.0" instead of working with any 13.x.x. we let some ABI breakage into releases but the strings.h stuff seems like it would be higher impact. |
| 16:54.57 | coreyfarrell | file: re ASTERISK-28289 do you think I should work towards getting submitting func_sit to gerrit and create a separate bug for the DSP issues detecting real life 'info' tones? I have no idea how to even start working on the DSP detection issue. |
| 16:55.29 | file | probably best - and I doubt anyone really knows... the DSP side |
| 17:04.34 | coreyfarrell | also wondering if a dialplan app would be a better option for this? |
| 17:06.18 | file | a blocking one you mean? |
| 17:06.48 | coreyfarrell | no. the app would just create the framehook and return |
| 17:06.55 | file | ah, *shrug* |
| 17:07.06 | file | other similar things use a dialplan function because then you can invoke it other places |
| 17:07.10 | file | like over AMI or ARI |
| 17:07.43 | coreyfarrell | oh so it might be possible to invoke the function using AMI/ARI originate (not sure if you can set a variable to the outbound leg only?) |
| 17:07.53 | file | yes |
| 17:09.12 | *** join/#asterisk-dev hehol (~hehol@gatekeeper.loca.net) |
| 17:12.13 | rmudgett | You can set a variable on any channel at any time with AMI |
| 17:12.58 | rmudgett | I suppose you can do the same thing with ARI |
| 17:17.52 | *** join/#asterisk-dev pchero_work (~pchero@87.213.240.121) |
| 19:03.04 | *** join/#asterisk-dev pchero (~pchero@dhcp-077-249-058-090.chello.nl) |
| 19:32.52 | cresl1n | csavinovich: on the force_inline patch |
| 19:33.22 | cresl1n | can we leave the function definitions in the header files so that we don't break API/ABI, but just remove the force_inline directive? |
| 19:38.20 | rmudgett | cresl1n: A static function in the header will generate a compiler warning about an unused static function if the including file does not use the function. |
| 19:50.36 | cresl1n | does it have to be static? |
| 19:52.00 | coreyfarrell | the definition for force_inline in asterisk/compiler.h does `#define force_inline inline` if the attribute isn't supported. can we just make that avoid the attribute if TEST_FRAMEWORK is defined? |
| 19:53.57 | csavinovich | Hello guys |
| 19:55.11 | csavinovich | <PROTECTED> |
| 19:55.13 | cresl1n | Oh yeah, I forgot about the TEST_FRAMEWORK mandate |
| 19:55.27 | cresl1n | so it only appears if TEST_FRAMEWORK is set? |
| 19:55.45 | cresl1n | or rather, how sure are we of that at this point? |
| 19:59.20 | csavinovich | I already tested this change, and the bug presists: |
| 19:59.37 | csavinovich | ``` |
| 19:59.38 | csavinovich | in include/asterisk/comnpiler.h I removed this entire section: |
| 19:59.38 | csavinovich | #ifdef HAVE_ATTRIBUTE_always_inline |
| 19:59.38 | csavinovich | #define force_inline __attribute__((always_inline)) inline |
| 19:59.38 | csavinovich | #else |
| 19:59.38 | csavinovich | #define force_inline inline |
| 19:59.38 | csavinovich | #endif |
| 19:59.39 | csavinovich | and replaced it with: |
| 19:59.39 | csavinovich | #define force_inline inline |
| 19:59.40 | csavinovich | ``` |
| 20:00.14 | csavinovich | horrible format... there I go again |
| 20:00.26 | csavinovich | ``` |
| 20:00.26 | csavinovich | #ifdef HAVE_ATTRIBUTE_always_inline |
| 20:00.26 | csavinovich | #define force_inline __attribute__((always_inline)) inline |
| 20:00.26 | csavinovich | #else |
| 20:00.26 | csavinovich | #define force_inline inline |
| 20:00.27 | csavinovich | #endif |
| 20:00.27 | csavinovich | ``` |
| 20:00.42 | csavinovich | I replace this whole section with: |
| 20:00.44 | csavinovich | ``` |
| 20:01.01 | csavinovich | ``` |
| 20:01.01 | csavinovich | #define force_inline inline |
| 20:01.01 | csavinovich | ``` |
| 20:01.13 | gtjoseph | may I suggest pastebin.com? |
| 20:01.22 | csavinovich | ``` |
| 20:01.22 | csavinovich | #define force_inline inline |
| 20:01.22 | csavinovich | ``` |
| 20:01.35 | csavinovich | nah, it is just 2 lines |
| 20:02.27 | csavinovich | anyway, point is, the bug still persist even with plain inline |
| 20:03.03 | cresl1n | Can we leave the header functions there and just remove the static attribute? |
| 20:03.17 | cresl1n | (and also remove the force_inline attribute on them)? |
| 20:03.44 | csavinovich | no, compiler complaints |
| 20:03.46 | cresl1n | I don't understand what static would mean for that scenario anyways |
| 20:08.27 | cresl1n | Here's a really crappy question after getting this far on this issue |
| 20:08.45 | cresl1n | Should instead the answer be, "upgrade your compiler"? |
| 20:09.03 | cresl1n | compiler optimizer appears busted |
| 20:09.11 | cresl1n | fix compiler instead? |
| 20:11.31 | csavinovich | Maybe it is easier to bug the heck out of the gcc people to get the bug fixed? (or maybe that's more difficult) :) |
| 20:12.08 | coreyfarrell | add -fno-partial-inline ? |
| 20:12.31 | coreyfarrell | or would that break the ABI anyways? |
| 20:12.51 | csavinovich | no good, we don't want to eliminate partial inline from compiling asterisk |
| 20:14.10 | coreyfarrell | just for dev-mode then? unless I'm misunderstanding the issue only happens with TEST_FRAMEWORK which can only be enabled with dev-mode |
| 20:15.17 | csavinovich | It only happens in TEST_FRAMEWORK |
| 20:15.57 | csavinovich | ...although potentially can happen anywhere else, it's just not been reported |
| 20:23.20 | cresl1n | that's what I was wondering... |
| 20:23.22 | cresl1n | interesting. |
| 20:23.45 | cresl1n | So we only *see* it in TEST_FRAMEWORK due to the failing test |
| 20:23.53 | cresl1n | But it could be happening anyways and we just don't realize it |
| 20:24.38 | cresl1n | Why didn't we want to do eliminate partial inlining (add the -fno-partial-inline) |
| 20:24.43 | csavinovich | correct. and you need is to use the plain inline keyword! |
| 20:24.44 | cresl1n | was that a gtjoseph request? |
| 20:25.24 | gtjoseph | we're sorry but gtjoseph has reached his flight hour limit for the day. please try again tomorrow |
| 20:25.29 | cresl1n | ha! |
| 20:25.42 | csavinovich | I believe so :).... although isn't it kind of overkill? |
| 20:26.14 | coreyfarrell | have bugs been reported against ubuntu/fedora/gcc? |
| 20:26.24 | csavinovich | it's like killing a fly with a shotgun |
| 20:26.29 | cresl1n | To enable -fno-partial-inline? |
| 20:26.37 | csavinovich | yes |
| 20:26.49 | csavinovich | MHO |
| 20:27.05 | cresl1n | But if it saved us from breaking API/ABI... |
| 20:28.17 | coreyfarrell | is -fpartial-inline a new option? I'm not finding docs for it. |
| 20:28.29 | rmudgett | cresl1n: To answer your question about making functions defined in header files non-static. No you can only define a function once otherwise the linker will/should complain. |
| 20:33.08 | coreyfarrell | ahh it's actually -fpartial-inlining, apparently not new |
| 20:34.16 | csavinovich | Actually, it would be -fno-partial-inlining |
| 20:43.22 | cresl1n | So you said that that resolves the issue as well? |
| 20:43.39 | cresl1n | (enabling the -fno-partial-inlining flag)? |
| 20:45.01 | csavinovich | yes, that solves the issue as well |
| 20:45.10 | cresl1n | I like that a lot too |
| 20:45.24 | csavinovich | that was actually my very first proposal |
| 20:45.44 | cresl1n | I'm trying to remember the beginning of this discussion |
| 20:46.03 | csavinovich | you know, we might add to enable it if it is Fedora 28 + dev_mode |
| 20:46.05 | cresl1n | Part of it is I don't think we all understood the potential consquences |
| 20:46.24 | cresl1n | (in the beginning) |
| 20:46.28 | csavinovich | ....cause it only happens in Fedora 28 and Ubuntu |
| 20:46.34 | cresl1n | yeah |
| 21:13.58 | cresl1n | I'm not sure where this leaves us |
| 21:14.53 | cresl1n | I almost would rather take the -fno-partial-inlining route, at least in the release branches (13 and 16) |
| 21:15.30 | cresl1n | But that's cresl1n the engineer speaking, not cresl1n the project lead |
| 21:16.13 | coreyfarrell | I'd prefer `-fno-partial-inlining` as that'll be easier to undo once the broken gcc gotes away. in the long run I feel like it's appropriate for the functions to be inlined. |
| 21:16.37 | cresl1n | I don't think we should be using the force_inline flag anymore though |
| 21:16.52 | cresl1n | it seems like that's a decision a compiler should make |
| 21:17.17 | cresl1n | but I agree, the -fno-partial-inlining seems like the right place to start |
| 21:17.34 | coreyfarrell | but csavinovich said that it happens with normal inline.. point being I think those funcitons should be inlinable rather than being in main/*.c |
| 21:18.39 | cresl1n | +1 to that |
| 21:19.18 | cresl1n | And if we could lock it down to that specific gcc version, that would be even better |
| 21:20.54 | coreyfarrell | ^^ part of why I asked if anyone knew of a bug reported to gcc itself. so we have something to follow for the fix / possibly upstream guidance about exact versions effected. |
| 21:21.17 | seanbright | sorry, just catching up - so is the ABI issue the only thing that complicates it? |
| 21:21.24 | seanbright | if so, i think it's a non-issue. |
| 21:21.45 | cresl1n | how's that? |
| 21:22.08 | coreyfarrell | the current patch also makes the functions non-inlinable. |
| 21:22.49 | seanbright | oh nevermind. i need to read more carefully next time. you'd have to roll 2 different versions of your modules for the same asterisk branch. |
| 21:22.58 | cresl1n | part my concern is that outside modules built against a newer version of the headers won't work against older versions of Asterisk, if I understand it correctly |
| 21:22.59 | cresl1n | yeah |
| 21:23.03 | seanbright | retracts his comments |
| 21:23.26 | cresl1n | not just us, but anybody else that builds out of tree modules |
| 21:23.36 | cresl1n | not a huge club, but there are a few |
| 21:23.38 | seanbright | no one else does that |
| 21:23.52 | seanbright | i'm sure people pretend to |
| 21:23.54 | seanbright | but they don't |
| 21:23.56 | seanbright | heh |
| 21:23.56 | cresl1n | heh |
| 21:26.18 | seanbright | could we just create _new versions of the relevant functions and #define old old_new |
| 21:26.28 | seanbright | and in master undo that |
| 21:26.34 | cresl1n | say what? |
| 21:27.08 | seanbright | i make perfect sense in my head, cresl1n |
| 21:27.19 | cresl1n | I'm beginning to see that |
| 21:27.20 | cresl1n | :-P |
| 21:27.37 | seanbright | ok, i am shutting up now. god bless. |
| 21:28.20 | file | seanbright: you're like mjordan on our Slack - he drops in, says stuff, and then disappears |
| 21:37.10 | cresl1n | So the recommended way forward is: |
| 21:37.31 | cresl1n | 1.) Don't change headers |
| 21:37.40 | cresl1n | (or main/*.c) |
| 21:38.05 | cresl1n | 2.) Enable -fno-partial-inlining conditional on detections of the broken gcc versions |
| 21:38.18 | cresl1n | Does that jive with everybody's understanding? |
| 21:42.51 | snuff-work | elcontrastador: seems they have 'tech spec' on how to do paging with nice breakdown.. but u'd need to implement the extra 'sauce' into asterisk Multicast RTP stuff.. |
| 21:42.56 | snuff-work | https://supportdocs.polycom.com/PolycomService/support/global/documents/support/technical/products/voice/Audio_Packet_Format.pdf |
| 21:46.58 | elcontrastador | @snuff-work: Yeah, I've seen this and wrote the sockets code to init the phones. But if you look at Table 10, the redundant frame and new audio frame, in addition to having each stream packet have the prescribed header makes it impossible to use with MulticastRTP. Thinking of using mcastRTP with Asterisk, write a listener client to receive the stream, rewrite for the damn polycoms, and restreaming on |
| 21:46.58 | elcontrastador | <PROTECTED> |
| 21:49.59 | elcontrastador | Does anybody here write ARI with Ruby? I'd be very interested in pair programming with an experienced dev. I would be happy to discuss compensation for your time |
| 21:50.47 | snuff-work | unsure if the 'capture prev packet' part could be done in ARI.. but then i'm not too far up on ARI capabilities |
| 21:51.36 | elcontrastador | @snuff-work: I'm thinking ARI could just enable the hooks to call outside app in some way... |
| 21:51.38 | snuff-work | now a specific res module that uses audiohooks maybe.. ? to keep 2 frames around to send every time.. seems possible.. but then i don't program enough in asterisk anymore |
| 21:52.39 | snuff-work | one of the 'real' devs prob have better answer =) |
| 21:54.37 | elcontrastador | :-) |
| 21:54.55 | snuff-work | res/res_rtp_multicast.c |
| 21:55.15 | snuff-work | would prob be where you could add the additions.. just taking quick look myself |
| 21:57.36 | elcontrastador | @snuff-work: As were rewriting just for polycoms, seems like a bad idea...damn polycoms should do whatever is needed to init and stop them from listening to a simple rtp mcast stream. I config cisco phones via script before and after send MulticastRTP stream...works flawlessly. Why Polycom needs to be a proprietary bitch with their very own stream type annoys the hell out of me. |
| 21:58.12 | snuff-work | well.. cisco aren't exactly known for being 'standards based' either =) |
| 21:58.31 | snuff-work | they may be the 'de facto' standard.. |
| 21:58.51 | coreyfarrell | cresl1n: agreed, my only question is which versions of gcc are broken. |
| 21:59.04 | cresl1n | yeah |
| 21:59.45 | elcontrastador | @snuff-work: they suck...have to reverse engineer everything...but once they're listening, they just take a stream of audio. |
| 22:01.30 | coreyfarrell | cresl1n: also I'm not sure what RHEL8 has, if they have gcc-8.2.1 they might backport the eventual fix rather than upgrade to a new version. |
| 22:01.41 | cresl1n | that'd work too |
| 22:01.48 | cresl1n | But in the meantime... |
| 22:04.10 | coreyfarrell | well I mean that going by version we could end up blocking partial-inlining for compilers which are fine (admittedly not a worst thing in the world). we do have BUILD_NATIVE menuselect option which if I remember correctly needs to be disabled when building for certain virtual envs, maybe a similar option to disable partial-inlining? |
| 22:04.53 | coreyfarrell | "if you build asterisk with a broken version of gcc you must enable BROKEN_INLINING in menuselect" ? |
| 22:05.05 | coreyfarrell | not sure that's a good idea just putting it out there for consideration |
| 22:14.36 | cresl1n | csavinovich: are you ok with moving forward with the suggested plan? |
| 23:09.50 | *** part/#asterisk-dev kharwell (kharwell@nat/digium/x-eylhmynuuahtroyv) |
| 23:19.30 | *** join/#asterisk-dev pchero_work (~pchero@dhcp-077-249-058-090.chello.nl) |
| 23:40.31 | *** join/#asterisk-dev pchero_work (~pchero@dhcp-077-249-058-090.chello.nl) |
| 23:44.36 | csavinovich | @creslin @creslin Matt, it is great idea, but reading @seanbright almost gave me this other idea: Since we are talking about tops 6 functions in include/asterisk/strings.h and 6 functions in include/asterisk/sem.h, how about if we turn all those into wrapper functions that call the new functions we will place in main/strings.c and main/utils.c?, like this: |
| 23:44.55 | csavinovich | ``` |
| 23:44.56 | csavinovich | include/asterisk/strings.h: |
| 23:44.56 | csavinovich | char *_ast_str_to_lower(char *str); |
| 23:44.56 | csavinovich | static force_inline char *attribute_pure ast_str_to_lower(char *str) |
| 23:44.56 | csavinovich | { |
| 23:44.56 | csavinovich | <PROTECTED> |
| 23:44.56 | csavinovich | } |
| 23:44.57 | csavinovich | main/strings.c: |
| 23:44.57 | csavinovich | char *_ast_str_to_lower(char *str) { |
| 23:44.58 | csavinovich | <PROTECTED> |
| 23:44.59 | csavinovich | <PROTECTED> |
| 23:44.59 | csavinovich | } |
| 23:45.00 | csavinovich | ``` |
| 23:45.53 | csavinovich | ...and case solved |
| 23:46.04 | csavinovich | Please note the following factors: |
| 23:46.38 | csavinovich | 1. When it happens, the bug only affects arithmetic calculations if they are executed inside a function marked inline, by executing the same code outside we will be ok. |
| 23:46.50 | csavinovich | 2. Will buy us a few months until gcc fixes this, cause it is potentially a nasty bug, I can't think of them not fixing it soon. Granted, there needs to be present a special level of multithreding which happens to occur on TEST_CEL, but as much as I have tried to replicate outside test_cel I haven't been able to. |
| 23:47.01 | csavinovich | 3. Searching Google for this gcc bug I have found it documented in previous versions, then it gets fixed, then appears again in newer versions. |
| 23:48.48 | rmudgett | csavinovich: That wrapper isn't going to help as the internal function now will still not be in older asterisk versions |
| 23:49.42 | csavinovich | can't we just put the prototype of the new functions in another header file? |
| 23:51.01 | rmudgett | The new internal function still must be available. |
| 23:51.16 | csavinovich | oh well :) |
| 23:52.46 | *** join/#asterisk-dev pchero_work (~pchero@dhcp-077-249-058-090.chello.nl) |