use system libraries instead of bundled libraries

The current build system makes it really long and hard to compile freeswitch for no apparent good reason. A lot of libraries are being built that are already available on the target system. On Debian, the following are already present:

apr
apr-util
curl
iksemel
libsndfile
pcre
portaudio
sofia-sip
speex
sqlite
spandsp
srtp
tiff
udns
yaml?

In addition, the following are downloaded during the build process and built on the fly: celt-0.7.0-1, json-c-0.8, lame-3.97, libmemcached-0.32, libshout-2.2.2 and mpg123

That will keep freeswitch from being bundled with the next Debian release. I really appreciate the work that has been done here to try to package FreeSWITCH to Debian, but as it stands, the package cannot enter the archive for three reasons:

 1. it bundles copies of code already shipped in other packages (this is the issue at hand here)
 2. it installs files in a non-standard location (/opt, i'll open a separate issue about this)
 3. it packages non-free components (mpg123 and lame come to mind, there may be others, that's a Debian issue that doesn't have to be addressed here)

As it stands, the issue I'm wishing to address here is #1. The issue is twofold:

 a. we need to be able to build freeswitch by linking to existing libraries, not the bundled ones
 b. ideally, we would need a reduced source distribution that wouldn't bundle those libraries

I understand the wish for the developers here to ensure a controlled environment in the distribution of the software, but really, a 75M archive is way too big for freeswitch. This build system will impede inclusion in Debian, but I suspect it will be a problem in other distributions as well.

Before build, the freeswitch-specific code only makes 279M of the total uncompressed 364M of source code. After build, that's 482M out of 710M. Really, that should be factored out.

But for the resolution of this issue, I think we can settle with just fixing the build system by adding a make target that would use existing libraries... Then the debian/rules file can be fixed to use that target.

I would understand if you guys don't want to change the build system that way, in which case that would mean the debian package would need to divert away from the standard build system, which will involve duplicate work and more confusion, so I'd rather avoid that.

The Debian packaging effort takes place here: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=389591

Thanks and happy new year.