On Tue, Jan 19, 2016 at 7:25 AM, Joshua Colp <[email protected]> wrote:
> George Joseph wrote: > > <snip> > > >> >> 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. >> > > That's a decision with consequences that others have to make (such as the > distros). Yep. See my response to Matt. > > > >> >> 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? >> > > Yes, but in the grand scheme of things the part of the user base using > those features is much smaller than the rest. If they get it as a result of > pulling pjproject in more then *shrug* it's fine. I just don't consider it > a reason for doing this. ^_^ > > Agreed. I'd never propose this on this basis only. It's just one more thing to add to the mix and there are going to be more things added I'm sure. > > >> >> 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. :) >> > > Not quite, 11 is easy because it's all in one module (res_rtp_asterisk). > 13 is hard because multiple modules use it, so you have to do what I said. > I spent a few days making it work so we could write functionality before it > was in a shared library form. "WHY ARE THESE SYMBOLS NOT IN HERE?!?" "Oh, > the linker decided they weren't used and took them out. Great." Understood. > > -- > 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
