The core issue here is the autotools detection in libsndfile checks for the headers, and then for the libraries, but the ifdef in the code only considers if the header files are available. It appears that autoconf was able to find the headers, but not the libraries (the output of configure would confirm this) and this is why it is failing on his box. I confirmed that this is also still the case in the 1.0.17 release of libsndfile, although the site does say that this new version does contain some bugfixes, so we should probably update to it. Mike ________________________________ From: Anthony Minessale [mailto:anthmct@yahoo.com] Sent: Wednesday, October 11, 2006 8:58 AM To: freeswitch-dev@lists.freeswitch.org Subject: Re: [Freeswitch-dev] Compiling error - libsndfile.so Ok I'll try this one more time. BEGIN --------------------------------------------------------- Quite simple, When our build process gets to the module building stage, each module has it's own Makefile with targets to build it's own depends. it downloads the tarball with wget and configures it to the same target prefix as all of the others. The lines you pasted reflect that the directories in the install prefix and the cwd at build time contain the word "freeswitch" and does not imply much more than that. snippit of our mod_sndfile's Makefile depends: MAKE=$(MAKE) $(BASE)/build/buildlib.sh $(BASE) install libsndfile-1.0.16.tar.gz --prefix=$(PREFIX) --disable-sqlite Like I said we only host the exact tarball on our server, checksum it if you wish: http://svn.freeswitch.org/downloads/libs/libsndfile-1.0.16.tar.gz Feel free to see for yourself if you still do not believe me. http://svn.freeswitch.org/svn/freeswitch/trunk http://svn.freeswitch.org/svn/freeswitch/trunk/src/mod/formats/mod_sndfi le/ Your library is a welcome addition as a module to our software and we have had little trouble with it, thank you. If you would reccommend we use the newer version let me know: anthmct@yahoo.com END --------------------------------------------------------- Stuart, Since this is a mailing list I am going to talk to some other people to save time on mutiple emails, excuse me a minute: Roman, Here is the downside to your suggestion, this guy is unhappy just because he *thinks* we keep his code in our tree. Anthony Minessale II FreeSWITCH http://www.freeswitch.org/ ClueCon http://www.cluecon.com/ AIM: anthm MSN:anthony_minessale@hotmail.com JABBER:anthony.minessale@gmail.com IRC: irc.freenode.net #freeswitch FreeSWITCH Developer Conference sip:888@66.250.68.194 iax:guest@66.250.68.194/888 googletalk:freeswitch@gmail.com pstn:712-432-7800 ----- Original Message ---- From: Stuart <stuart@stu.org.uk> To: freeswitch-dev@lists.freeswitch.org Sent: Wednesday, October 11, 2006 2:37:26 AM Subject: Re: [Freeswitch-dev] Compiling error - libsndfile.so Anthony Minessale wrote: Reply to him and say We *do* use a pristine copy of thier tarball we just host it on our server to save you the bandwidth of people constantly downloading it we do not ship it with our source code so please do not make that assumption. Reply from libsndfile: Well then someone needs to explain this: > "/usr/local/freeswitch/include" > /usr/bin/install -c -m 644 'sndfile.h' > '/usr/local/freeswitch/include/sndfile.h' > make[5]: Leaving directory `/root/freeswitch/libs/libsndfile-1.0.16/src' > make[4]: Leaving directory `/root/freeswitch/libs/libsndfile-1.0.16/src' > make[3]: Leaving directory `/root/freeswitch/libs/libsndfile-1.0.16/src'

On Wed, 2006-10-11 at 05:58 -0700, Anthony Minessale wrote:

Stuart, Since this is a mailing list I am going to talk to some other people to save time on mutiple emails, excuse me a minute:

Roman, Here is the downside to your suggestion, this guy is unhappy just because he *thinks* we keep his code in our tree.

I sort of disagree. I believe that this guys is unhappy because what we have in FreeSwitch now is kind of worst of both worlds -- we don't really want to rely on preinstalled and prepackaged libraries available on the system, yet we also don't want to bite the bullet and privatize the code. Personally, I think this is one of the greatest myth of OpenSource that all you have to do in order to build a reliable package is: ./configure && make && make install. What we currently have in FreeSwith is an attempt to rely on that. I've used to do lots of packaging for Solaris and believe me -- there's not much else I hate more than autotools complexity. :-( Anyway, it looks like my proposal doesn't really resonate with lots of folks here, which means I have to come up with extra benefits. My angle would be a performance one. Stay tuned... Thanks, Roman.