[asterisk-dev] Proposal to bring pjproject back into the fold

[George Joseph]

On Tue, Jan 19, 2016 at 10:41 AM, Jeffrey Ollie <jeff at ocjtech.us> wrote:

> On Tue, Jan 19, 2016 at 11:18 AM, George Joseph <
> george.joseph at fairview5.com> wrote:
>
>>
>> We already have a --with-pjproject=PATH option in ./configure which I'd
>> default to the one in asterisk/third_party but you could choose any path.
>> The only real difference is that we're always statically linking rather
>> than dynamically linking.  If you don't change the path, the Asterisk build
>> would (smartly) download and build the approved version.
>>
>
> Statically linking against external libraries is frowned upon almost as
> much as bundling.  Statically linking is harmful because:
>
> 1) It's more difficult to determine where each library is used.
> 2) An update to a library means that you have to recompile every
> application that uses the library, rather than just install the new version
> of the library and restart the services.
> 3) Potentially more memory usage because the library code pages can't be
> shared between processes.
>
> The poster child for this has been zlib.  It used to be very common to
> statically link this library into applications, but a number of security
> flaws in zlib and the ensuing chaos while everyone was desperately trying
> to track down and replace all of the copies that had been statically linked
> into an application is part of what has led to distributions' policies
> against bundling and static linking.
>

​I don't think you can compare zlib, ​a small library whose api and
features haven't changed in years, to pjproject and especially pjproject's
relationship to Asterisk.  pjproject is still very much in development and
Asterisk calls 122 DIFFERENT pj_* functrions.


>
> Personally, I think that a better option would be to add a tool that would
> sanity check the version of pjproject being linked against to make sure
> that all of the appropriate options are set and bail out of the Asterisk
> build if they aren't.
>
>
​The bulk of the problem is at runtime though.​  If we don't static link,
we'll never know what's going on.


> --
> Jeff Ollie
>
>
> --
> _____________________________________________________________________
> -- 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20160119/7c1137b9/attachment.html>