[Freeswitch-dev] DSO library management issues
rvs at sun.com
Sat Sep 30 02:02:01 EDT 2006
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:
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.
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.
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.
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!
More information about the Freeswitch-dev