[Freeswitch-dev] DSO library management issues

[Michael Jerris]

> From: Roman Shaposhnik [mailto:rvs at sun.com]
> Sent: Saturday, September 30, 2006 2:02 AM
> To: freeswitch-dev at lists.freeswitch.org
> Subject: [Freeswitch-dev] DSO library management issues
> 
> Hi Guys!
> 
> I'm getting pretty close to having FreeSwitch up and running
> on a SPARC Solaris Niagara box (yeah -- that's the one with
> 8 physical cores and 32 threads per CPU) which is a good news.
> The bad news (at least from my POV) is that I think I've
> stumbled upon a particular problem in how FreeSwitch gets
> built and packaged for which I don't really have a good
> solution. So, in order for me to move forward I have
> to make sure that you guys also view this as an issue
> and that you'd be willing to address it.
> 
> Here's the deal -- its no secret that FreeSwitch depends
> on DSOs a *LOT* (in fact, the core of FreeSwitch itself
> is a DSO library with a simple wrapper bin/freeswitch
> around it). In general I would divide these DSOs into
> 3 broad categories:
> 
> 1. Plugin/modules (including CORE)
> 
> These guys posses no problem whatsoever -- they get developed
> within the FreeSwitch SVN repository, they DO NOT get
> distributed outside of FreeSwitch. They also get built
> as part of building FreeSwitch. Always. The only trouble
> with them is that sometimes they depend on functionality
> available only from external libraries. And that leads
> us to the following 2 categories:
> 

This is not entirely the case.  We would like for people to build out of
tree modules against a packaged install of the core.  The fsxs script is
the initial attempt at that, I am sure there is more work to do on this.
The biggest issue I see with this is right now, the core includes among
other things the apr and sqlite headers in it public include chain (so
they are also included in the modules).  One thought to simplify this
was to create freeswitch stub functions in a C file for these, and only
include the apr and sqlite headers in those C files, allowing us to have
a single set of freeswitch include files that do not depend on other
libraries headers being installed in some location when we go to build
out of tree freeswitch modules.  Is there a way on *nix (gcc and sun
studio at least) to optimize out these stub functions when statically
linking so that we don't take a performance hit by doing this?  I think
this would be the best mix as it would allow us to install the single
library for the core with it's include files in a single package,
without name conflicts with other libraries.  We have already run into
quite a few issues with many different versions of for example apr on
the same box, and we have in the past needed to add patches to some of
these libs, which is why we have selected to build them in tree.

> 2. Well-known external DSO libraries
> 
> These are the things you would expect to see on a reasonably
> well configured Linux system these days. Things like
> /usr/lib/libsqlite3.so or /usr/lib/libapr.so.0. Things which
> get developed elsewhere, have their dedicated maintainers
> and packagers. And which are relatively easy to find in
> .RPMs or .DEBs.

The biggest issue we have had with this, is we have had in the past is
that we have had to contribute a lot of patches back to many libraries,
mostly for cross platform issues but also for bugs.  We have frequently
had to temporarily fork a library with a patch in tree to resolve an
issue while waiting for these patches to get back into the maintained
tree.  This for example just happened with libresample for changes
contributed to make it build on solaris.  In order to properly build
against system versions of the libraries, we would need to add a very
significant amount of autoconf magic to properly detect and use specifc
libs.  So far, we have just added a make nodeps target, that would allow
someone to build all the libs manually themselves, thus allowing them to
make those decisions themselves on how to build libraries.  My biggest
concern on this one is colliding with other libraries installed on the
system, which I think linking them statically will resolve, I am still
not clear what the general dislike of this practice is about?  Is it
build time?  Something else?

> 
> 3. DSO libraries originating from the FreeSwitch project itself.
> 
> Now in this category I don't want to discriminate between
> something that Anthony has written (i.e. libteletone) or
> something that just got sucked into FreeSwitch for a lack
> of a better home (i.e. lib/codec/g726). All of these things
> 
> Now, why am I telling you all this ? :-) Well, simply because
> during my Solaris "porting" effort I've really convinced myself
> that we have to have a much better plan for #2 and #3 w.r.t.
> building and packaging than what we have in FreeSwitch now.
> And here's why:
> 
>   1. For the #2 I really don't want to sit through the endless
>   stream of ./configure ; make ; make install if I already
>   have these libraries on my system. What I want instead
>   is a detection mechanism (or --with-<package name>= option
>   for a configure script) that would also warn me about the
>   version FreeSwitch developers deem to be appropriate for
>   each of the packages.

The biggest hold up on this would be someone contributing appropriate
checks that would allow this to happen, and to guarantee that it works
right, right now it "works", so we are a little nervous about adding
another variable to the mix that would mean we could spend a lot of time
troubleshooting an issue, only to find out its because some lib built
outside of our build system was built wrong.  A great example of this is
perl, on most distributions, the perl that is shipped is not built with
multiplicity, and some other option which I can't recall at the moment.
We would need to have autoconf that could totally verify this.  And even
then, people can change libs out from under us, and have issues.  This
is why I tend to like a solution that statically links in what it needs

> 
>   2. As for the #3... my take on it is that we shouldn't really
>   have #3 in FreeSwitch at all. Every single library from that
>   category should either be moved to #1 or to #2. If it ends
>   up being in #2 than it has to be moved to a separate SVN repo.

I don't entirely disagree on this one, it's more been just a matter of
conveinience, even for the codec libs, if we don't start just using
ffmpeg, I plan to make a distribution of these separately, for now,
maybe learning to use svn externals is the best bet?

> 
> So consider all of the above as a preliminary request for
> opinions and lets hope to make FreeSwitch really portable
> and highly configurable at the building and packaging level!
> 
> Thanks,
> Roman.
> 

Please note, we started merging a bunch of changes into several of the
core dependency libs yesterday that are specifically for solaris/sun
studio building.  One of the other major things we are trying to merge
in is the ability to set debug symbols and optimization options from the
core configure and have it flow the rest of the way through the build.
I am not sure there is any good way we could accomplish things like that
if we don't build them on our own, at least from a developer point of
view.  As for packaging, I keep leaning towards statically linking and
not depending on other packages... if this is incredibly stupid for some
reason other than size, I would need to be convinced, as it will greatly
simplify so many other things.

The only other note is any changes that would be made for preference, as
opposed to required changes for porting to Solaris, I want to make sure
that we can do this in a way that does not in any way hamper Tony's
ability to keep coding.  Please let us know what you think about these
comments above.  Also, if you have porting work ongoing that I can merge
in pieces as I go, I would be more than happy to do so.  As it stands
today, it looks like all the dependency libs for the core should be
working for you in tree, with the exception of srtp.  If you would like
me to merge in other changes, you can just commit them to a branch, and
I can work on getting them merged into tree as quickly as possible.

Mike