<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jan 20, 2016 at 11:04 AM, Tzafrir Cohen <span dir="ltr"><<a href="mailto:tzafrir.cohen@xorcom.com" target="_blank">tzafrir.cohen@xorcom.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Wed, Jan 20, 2016 at 09:49:32AM -0600, Matthew Jordan wrote:<br>
> On Wed, Jan 20, 2016 at 8:22 AM, Jared Smith <<a href="mailto:jaredsmith@jaredsmith.net">jaredsmith@jaredsmith.net</a>><br>
<br>
</span><span class="">> So why is pjproject such a pain?<br>
><br>
> There's probably a number of reasons, and I'm probably forgetting some, but<br>
> I'd boil the top ones down to the following:<br>
><br>
> * pjproject embeds third party libraries.<br>
><br>
> Some of those third party libraries are also libraries that Asterisk can<br>
> use; if Asterisk needs to use them, you have to tell pjproject to not use<br>
> its embedded version. While it is easy to say that pjproject should "just<br>
> not do that", that misses the original - and still one of the most common -<br>
> use cases of pjproject; namely, as an embedded systems library. For people<br>
> building SIP devices on embedded platforms, having embedded versions of<br>
> GSM, SRTP, and other useful libraries is actually advantageous. Packages<br>
> are not usually available for, say, VxWorks, and if I know pjproject can be<br>
> built using my esoteric toolchain, I don't have to try and make libsrtp<br>
> build as well with it.<br>
><br>
> As a result, pjproject is highly unlikely to ever remove their embedding of<br>
> third party libraries, despite our attempts at convincing them to do that.<br>
> They serve *more* than just the Asterisk project, and our needs are not<br>
> always going to match 100% with theirs.<br>
><br>
> The implications of that are that we're going to need to work around and/or<br>
> deal with the third party libraries they embed in some fashion.<br>
<br>
</span>I'm not sure what your exact issue is here.<br>
<br>
Is there any specific library that pjproject currently embeds that can't<br>
be trivially disabled? Do you think there is an issue with pjproject not<br>
defaulting enough to using system libraries where possible?<br>
<span class=""><br>
> * pjproject static/shared libraries is confusing for many people<br>
><br>
> It is not uncommon for people to build static libraries of pjproject the<br>
> first time around (missing the instructions to not do that), install them,<br>
> and run Asterisk. Asterisk then will crash or do something terrible. They<br>
> will then attempt to install the shared object libraries, not removing the<br>
> static libraries. Asterisk will still run, and now crash in a different<br>
> fashion. They will then attempt to remove the static libraries, and now<br>
> Asterisk will complain that it can't find pjproject because you're using<br>
> RHEL and your pkg-config path isn't set up correctly.<br>
<br>
</span>Hang on. This is RHEL. A stable platform. Why can't they just use<br>
pjproject packages and be done with it?<br>
<br></blockquote><div><br></div><div>The same question could be asked of why they choose to build Asterisk from source.<br><br></div><div>I won't get into why a user may choose to build from source versus install from packages, nor am I going to blame a user for choosing to do so. The user experience in that situation is sub-optimal.<br><br></div><div>Matt<br></div><br></div>-- <br><div class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div>Matthew Jordan<br></div><div>Digium, Inc. | Director of Technology<br></div><div>445 Jan Davis Drive NW - Huntsville, AL 35806 - USA</div><div>Check us out at: <a href="http://digium.com" target="_blank">http://digium.com</a> & <a href="http://asterisk.org" target="_blank">http://asterisk.org</a></div></div></div></div></div>
</div></div>