George Joseph wrote:
<snip>
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 was also thinking we could statically link against the
system-installed version but we're still back to the same problem where
we have no clue at runtime what we're running against.
That's a decision with consequences that others have to make (such as
the distros).
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.
Strictly true but if you want ICE, TURN or STUN support, you need
pjproject, no?
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. ^_^
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.
I was nosing around 11 last night and realized that the plumbing is
there. That's why I updated my level of effort. :)
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."
--
Joshua Colp
Digium, Inc. | Senior Software Developer
445 Jan Davis Drive NW - Huntsville, AL 35806 - US
Check us out at: www.digium.com & www.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
