On Tue, Jan 19, 2016 at 6:06 AM, Matthew Jordan <[email protected]> wrote:
> > On Tue, Jan 19, 2016 at 6:04 AM, Joshua Colp <[email protected]> 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'd certainly still like a packaged pjproject to take precedence if > available. This allows package maintainers to meet the guidelines of their > distros, and eases their burden. > I understand the packaging issue and I'd like to hear from packagers like Jared Smith. We could simply require a specific version of Asterisk to be statically linked to a specific version of pjproject and let the packaging process insure it's there. For rpms, a BuildRequires would do that. There's be no runtime dependency after that. > > >> >> 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. >> >> >>> 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. >> > > Would we automatically download and link pjproject when someone runs > 'make', or would it require some different make target? > The more I think about it, maybe we don't need to bundle. Maybe it's just enforcing a specific version to be available for static linking. > > -- > Matthew Jordan > Digium, Inc. | Director of Technology > 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA > Check us out at: http://digium.com & http://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
