<div dir="ltr"><div class="gmail_default" style="font-family:arial narrow,sans-serif"><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jan 19, 2016 at 7:25 AM, Joshua Colp <span dir="ltr"><<a href="mailto:jcolp@digium.com" target="_blank">jcolp@digium.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">George Joseph wrote:<br>
<br>
<snip><span class=""><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<br>
There is the middle ground which is keep the ability to link against<br>
a shared system library if present but also bundle a pjproject and<br>
use it if the system library is not present (or you force the<br>
bundled version).<br>
<br>
<br>
I was also thinking we could statically link against the<br>
system-installed version but we're still back to the same problem where<br>
we have no clue at runtime what we're running against.<br>
</blockquote>
<br></span>
That's a decision with consequences that others have to make (such as the distros).</blockquote><div><br></div><div><div class="gmail_default" style="font-family:'arial narrow',sans-serif">Yep. See my response to Matt.</div></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<br>
pjproject was deeply embedded in 11 and I don't think that was<br>
right but<br>
I think we went too far in 13 by taking the hands-off approach.<br>
Maybe<br>
at the start of 13 it was ok, but we've since put chan_sip into<br>
"extended" support so we're pushing chan_pjsip as the supported<br>
stack,<br>
instead of it just being optional. Not to mention that chan_sip<br>
needs<br>
res_rtp_asterisk which is also dependent on pjproject. Can you see<br>
where I'm going? :)<br>
<br>
<br>
In the current shared library method it is not a hard dependency.<br>
<br>
<br>
Strictly true but if you want ICE, TURN or STUN support, you need<br>
pjproject, no?<br>
</blockquote>
<br></span>
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. ^_^<div><div class="h5"><br></div></div></blockquote><div><div class="gmail_default" style="font-family:'arial narrow',sans-serif">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.</div></div><div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="h5">
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<br>
I propose that we bring pjproject into a new 'third-party'<br>
directory and<br>
statically link our res_pjsip* modules to it. We should NOT<br>
check it<br>
into the Asterisk repository however. Instead we should use scripts<br>
like get_mp3_source to get a specific pjproject version and a<br>
'patches'<br>
directory that IS checked in that has things we've discovered we<br>
need.<br>
The patches should always be proposed upstream.<br>
<br>
It's a lot of work but I'm willing to dig in and I'll bet I<br>
could get a<br>
few volunteers to help.<br>
<br>
<br>
From a technical perspective you can not statically link each<br>
module to PJSIP, each module will end up with its own isolated<br>
running copy. You need to statically link it into one module<br>
(res_pjsip, or res_pjproject for example) and have it export all of<br>
the symbols to everything else. Additionally because all the symbols<br>
aren't actually being used the linker also likes to remove them<br>
unless you do magic to force them to be present regardless. This is<br>
how the PJSIP support was originally developed before shared library<br>
support was added to pjproject. If you go back in time almost<br>
everything needed to make it work in a bundled configuration is<br>
there already.<br>
<br>
<br>
I was nosing around 11 last night and realized that the plumbing is<br>
there. That's why I updated my level of effort. :)<br>
</blockquote>
<br></div></div>
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."</blockquote><div><br></div><div><div class="gmail_default" style="font-family:'arial narrow',sans-serif">Understood.</div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="im HOEnZb"><br>
<br>
-- <br>
Joshua Colp<br>
Digium, Inc. | Senior Software Developer<br>
445 Jan Davis Drive NW - Huntsville, AL 35806 - US<br>
Check us out at: <a href="http://www.digium.com" rel="noreferrer" target="_blank">www.digium.com</a> & <a href="http://www.asterisk.org" rel="noreferrer" target="_blank">www.asterisk.org</a><br>
<br></span><div class="HOEnZb"><div class="h5"><br></div></div></blockquote></div></div></div>