On Tue, Jan 19, 2016 at 5:04 AM, Joshua Colp <jc...@digium.com> wrote:
> George Joseph wrote: > >> I'm VERY frustrated with pjproject right now. Not the software itself >> (well maybe a little) but the fact that troubleshooting is a nightmare >> because we can't control what version of pjproject was installed along >> with Asterisk and we can't control what options it was compiled with. >> This leads to issue where we're getting great debugging from Asterisk >> but nothing at all from pjproject because the user installed from their >> distro and it has no debugging info. So now we have to walk them though >> getting pjproject from source, etc, etc. This can also cause issues >> should Teluu change an API or some behavior that we're not prepared for >> and the user just does a 'yum update pjproject' and Asterisk dies. Then >> there's the issue where even though the verison is the same, the >> compiled-in options differ, some of them quite fatally. That unleashes >> a whole other mess. >> > > There is the middle ground which is keep the ability to link against a > shared system library if present but also bundle a pjproject and use it if > the system library is not present (or you force the bundled version). I was also thinking we could statically link against the system-installed version but we're still back to the same problem where we have no clue at runtime what we're running against. > > > pjproject was deeply embedded in 11 and I don't think that was right but >> I think we went too far in 13 by taking the hands-off approach. Maybe >> at the start of 13 it was ok, but we've since put chan_sip into >> "extended" support so we're pushing chan_pjsip as the supported stack, >> instead of it just being optional. Not to mention that chan_sip needs >> res_rtp_asterisk which is also dependent on pjproject. Can you see >> where I'm going? :) >> > > In the current shared library method it is not a hard dependency. Strictly true but if you want ICE, TURN or STUN support, you need pjproject, no? > >> I propose that we bring pjproject into a new 'third-party' directory and >> statically link our res_pjsip* modules to it. We should NOT check it >> into the Asterisk repository however. Instead we should use scripts >> like get_mp3_source to get a specific pjproject version and a 'patches' >> directory that IS checked in that has things we've discovered we need. >> The patches should always be proposed upstream. >> >> It's a lot of work but I'm willing to dig in and I'll bet I could get a >> few volunteers to help. >> > > From a technical perspective you can not statically link each module to > PJSIP, each module will end up with its own isolated running copy. You need > to statically link it into one module (res_pjsip, or res_pjproject for > example) and have it export all of the symbols to everything else. > Additionally because all the symbols aren't actually being used the linker > also likes to remove them unless you do magic to force them to be present > regardless. This is how the PJSIP support was originally developed before > shared library support was added to pjproject. If you go back in time > almost everything needed to make it work in a bundled configuration is > there already. I was nosing around 11 last night and realized that the plumbing is there. That's why I updated my level of effort. :) > > > -- > Joshua Colp > Digium, Inc. | Senior Software Developer > 445 Jan Davis Drive NW - Huntsville, AL 35806 - US > Check us out at: www.digium.com & www.asterisk.org > >
-- _____________________________________________________________________ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev