[Freeswitch-dev] DSO library management issues

Sat Sep 30 13:09:18 EDT 2006

There are a few good explanations (I hope).

I have chosesn to build all of the code used in the program for a few reasons:

1) To ensure proper configuration and versioning.
   a) We have no control over what options the default system libs 
      were built with (thread saftey options etc).
   b) As a side-effect of our extensive push on our dependancies,
      we often need the code to be modified to work properly 
      due to necessary modifications or bugfixes that only exist
      in our private tarball while we wait for a new version to be released. 
   c) Most distros do not provide cutting edge releases of libraries
      which be necessary due to results from sub-reason (b)

2) To create a atonomous environment.
    a) The defualt install prefix is /usr/local/freeswitch all of the depends
       are installed in this dir so you can subsequently tar up that directory
       and move it to another machine without installing it again.

    b) Some systems have slightly different versions of the same
       libraries that do not co-exist well we never need to look outside
       of our own lib dir for these libraries.

I am fairly concerned with making huge initiatives in the build process
during a time where I am still coding 12 hours a day on the core but I am open
to improvement as long as the tangent does not impeed my development effort.
Imagine if someone wanted to install superior scafolding while the guy is on top of it building the house still.  Once development shifts to higher level
stuff my concerns will most likely subside.

One bright note is if you dont watch during the endless stream of ./configure make ; make install, it goes faster (a watched pot never boils) =D
And that only happens the first time, subsequent builds go much faster.

I am truely anxious to see what happens on this super sun box
and I'd like to thank you for your efforts and your valuable time I really
appriciate your help.

Anthony Minessale II

FreeSWITCH http://www.freeswitch.org/
ClueCon http://www.cluecon.com/

AIM: anthm
MSN:anthony_minessale at hotmail.com
JABBER:anthony.minessale at gmail.com
IRC: irc.freenode.net #freeswitch

FreeSWITCH Developer Conference
sip:888 at 66.250.68.194
iax:guest at 66.250.68.194/888
googletalk:freeswitch at gmail.com
pstn:712-432-7800

----- Original Message ----
From: Roman Shaposhnik <rvs at sun.com>
To: freeswitch-dev at lists.freeswitch.org
Sent: Saturday, September 30, 2006 1:02:01 AM
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:

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!

Thanks,
Roman.

_______________________________________________
Freeswitch-dev mailing list
Freeswitch-dev at lists.freeswitch.org
http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev
UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev
http://www.freeswitch.org

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-dev/attachments/20060930/f273d557/attachment.html 