From: Roman Shaposhnik [mailto:rvs@sun.com] Sent: Saturday, September 30, 2006 2:02 AM To: freeswitch-dev@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