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

[Jeffrey Ollie]

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.

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.

-- 
Jeff Ollie
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20160119/cd9089a1/attachment.html>