Compiling freeswitch for Dragonfly BSD
Hi. I have been searching for an alternative PBX to asterisk (which has not been all that stable) to run on Dragonfly BSD. I spent a fair amount of time a couple months ago trying to compile freeswitch without success. I have since tried Yate, but it consumes 85-95% of the cpu when idle (not processing any calls). I am considering revisiting freeswitch. I have included below my notes of all the various problems I encountered before, which ones I resolved and how, up to the point where I left off. I am in hopes of getting feedback on whether any of the issues have been fixed or are planned to be fixed and/or suggestions on getting it working. Also, perhaps these notes on my experiences will be helpful for the developers to improve freeswitch. Keep in mind that Dragonfly is a branch from Freebsd and stays fairly compatible. I am able to compile most software, that is ported to FreeBSD, with few problems. Here are my notes ================= To compile on dragonfly BSD 1.10.1-RELEASE ========================================== I had to add -D__FreeBSD__ to CPPFLAGS ln sh to bash or zsh because I got "unexpected operator" errors from "test" during configure with the bsd shell. ln make to gmake Their scripts were calling make even though I ran the build using gmake. Must have apr-0.9.16.2.0.61 and apr-util-0.9.16.2.0.61 installed apr-0.xxx has headers, which freeswitch is including, that apr-1.xxx does not have. I sym-linked the apr-util libs from apr-util-1.2.8nb1 because apr-util-0.9.16.2.0.61 was not available as a binary package. The freeswitch-1.0.3.tar.gz release did not have bootstrap.sh, which is required for building from the svn repository. Somebody on the #freeswitch IRC suggested I get it from the subversion repository and run the bootstrap script. bootstrap.sh is not in the release. ========================================== Tue Mar 31 00:12:37 CDT 2009 I posted on the freeswitch mailing list asking about the compilation errors Got no responses. This first set of apr_... warnings turned out to clearly be from not having the correct apr-util package installed, I should have gotten a response on the list about it, considering it is a clear dependency that they do not directly specify on the web site or the source docs. apr-util is a dependency of subversion. They list SVN as a dependency of freeswitch, which is the utility in the subversion package, not the package name. svn should not be a dependency to build from a release archive that is not retrieved from the svn repository. As it turns out, it had to be apr-util version 0.9.15. See notes below. ========================================== Tue Mar 31 22:22:58 CDT 2009 I tried the freeswitch-snapshot.tar.gz from the freeswitch site, which is a 03/30/2009 snapshot from the svn trunk. *concern* It was nearly twice as big as the release for some reason. 27016871 Mar 28 13:08 freeswitch-1.0.3.tar.gz 52854882 Mar 31 18:25 freeswitch-snapshot.tar.gz Running bootstrap.sh produced a bunch of these errors from automake: Use of uninitialized value in exists at /usr/pkg/bin/automake line 4823, <GEN0> line 1. Use of uninitialized value in concatenation (.) or string at /usr/pkg/bin/automake line 4823, <GEN0> line 1. automake: #################### automake: ## Internal Error ## automake: #################### automake: unrequested trace `' automake: Please contact <bug-automake@gnu.org>. at /usr/pkg/share/automake-1.10/Automake/Channels.pm line 570 Automake::Channels::msg('automake', '', 'unrequested trace `\'') called at /usr/pkg/share/automake-1.10/Automake/ChannelDefs.pm line 191 Automake::ChannelDefs::prog_error('unrequested trace `\'') called at /usr/pkg/bin/automake line 4823 Automake::scan_autoconf_traces('configure.ac') called at /usr/pkg/bin/automake line 5046 Automake::scan_autoconf_files() called at /usr/pkg/bin/automake line 781 ========================================== Thu Apr 2 20:51:44 CDT 2009 Going back to the 1.0.3 release. I was getting a a bunch of apr_... warnings like Compiling src/switch_apr.c ... src/switch_apr.c: In function `switch_thread_self': src/switch_apr.c:74: warning: implicit declaration of function `apr_os_thread_current' src/switch_apr.c:74: warning: return makes pointer from integer without a cast ... Then gmake[3]: *** [libfreeswitch_la-switch_apr.lo] Error 1 I finally got past that by installing apr-0.9.16.2.0.61 and apr-util-0.9.15. I compiled apr-util-0.9.15 myself because it was not available as a binary package. Source files are including headers from apr-util-0.9.15 that do not exist in the binary package, apr-util-1.2.8nb1.tgz. I also got past the "Cannot guess build type" error during configure by adding "--build=i386" instead of having to use the uname wrapper to fake FreeBSD. ========================================== New error: (This one is not the fault of freeswitch) Compiling src/switch_core.c ... src/switch_core.c: In function `switch_core_setrlimits': src/switch_core.c:795: error: `RLIMIT_AS' undeclared (first use in this function) Turns out RLIMIT_AS is defined in /usr/include/sys/resource.h on some other systems including FreeBSD but not Dragonfly. It is used in the source like this #if !defined(__OpenBSD__) && !defined(__NetBSD__) setrlimit(RLIMIT_AS, &rlp); It is defined in resource.h in FreeBSD like this #define RLIMIT_AS RLIMIT_VMEM /* standard name for RLIMIT_VMEM */ I created a patch for src/switch_core.c which fixed this error. Since then, I discussed this on the Dragonfly BSD mailing list and it is apparently going to be fixed on a future release of Dragonfly now that they are aware of it. ========================================== New error: Tons of warnings like warning: return makes pointer from integer without a cast (this needs cleaned up) Then error'd with gmake[8]: *** No rule to make target `iptsec/libiptsec.la', needed by `libsofia-sip-ua.la'. Stop. I cd'd to libs/sofia-sip/libsofia-sip-ua/su and ran make there. It completed successfully in spite of the same warnings. Then ran make again form the top. Got further until ========================================== New error: making all mod_spidermonkey cd config; gmake -j1 export cd pr; gmake -j1 export cd include; gmake export cd md; gmake export ../../../config/./nsinstall: cannot make symbolic link /u1/falcon/ports/freeswitch-1.0.3/work/freeswitch-1.0.3/libs/js/nsprpub/dist/include/nspr/.: File exists Why would it be trying to make a sym-link of '.' ?? ========================================== Giving up for now.
You are way off base in a few places, let me see if I can clarify a bit. Here are at least 2 pointers: 1) The release tarballs do not come with bootstrap because they already are bootstrapped. 2) FreeSWITCH does not depend on system libs so all the stuff about apr is barking up the wrong tree. we build our own apr and apr-utils I suggest you try latest svn trunk of FS and follow the BSD build guidelines on the WIKI since you say it's closely compatible. On Mon, Jun 22, 2009 at 11:08 PM, Vincent Stemen < vince.freeswitch@hightek.org> wrote:
Hi.
I have been searching for an alternative PBX to asterisk (which has not been all that stable) to run on Dragonfly BSD. I spent a fair amount of time a couple months ago trying to compile freeswitch without success.
I have since tried Yate, but it consumes 85-95% of the cpu when idle (not processing any calls).
I am considering revisiting freeswitch. I have included below my notes of all the various problems I encountered before, which ones I resolved and how, up to the point where I left off. I am in hopes of getting feedback on whether any of the issues have been fixed or are planned to be fixed and/or suggestions on getting it working. Also, perhaps these notes on my experiences will be helpful for the developers to improve freeswitch.
Keep in mind that Dragonfly is a branch from Freebsd and stays fairly compatible. I am able to compile most software, that is ported to FreeBSD, with few problems.
Here are my notes =================
To compile on dragonfly BSD 1.10.1-RELEASE ========================================== I had to add -D__FreeBSD__ to CPPFLAGS ln sh to bash or zsh because I got "unexpected operator" errors from "test" during configure with the bsd shell. ln make to gmake Their scripts were calling make even though I ran the build using gmake. Must have apr-0.9.16.2.0.61 and apr-util-0.9.16.2.0.61 installed apr-0.xxx has headers, which freeswitch is including, that apr-1.xxx does not have. I sym-linked the apr-util libs from apr-util-1.2.8nb1 because apr-util-0.9.16.2.0.61 was not available as a binary package.
The freeswitch-1.0.3.tar.gz release did not have bootstrap.sh, which is required for building from the svn repository.
Somebody on the #freeswitch IRC suggested I get it from the subversion repository and run the bootstrap script. bootstrap.sh is not in the release.
========================================== Tue Mar 31 00:12:37 CDT 2009
I posted on the freeswitch mailing list asking about the compilation errors Got no responses.
This first set of apr_... warnings turned out to clearly be from not having the correct apr-util package installed, I should have gotten a response on the list about it, considering it is a clear dependency that they do not directly specify on the web site or the source docs. apr-util is a dependency of subversion. They list SVN as a dependency of freeswitch, which is the utility in the subversion package, not the package name. svn should not be a dependency to build from a release archive that is not retrieved from the svn repository.
As it turns out, it had to be apr-util version 0.9.15. See notes below. ==========================================
Tue Mar 31 22:22:58 CDT 2009
I tried the freeswitch-snapshot.tar.gz from the freeswitch site, which is a 03/30/2009 snapshot from the svn trunk.
*concern* It was nearly twice as big as the release for some reason. 27016871 Mar 28 13:08 freeswitch-1.0.3.tar.gz 52854882 Mar 31 18:25 freeswitch-snapshot.tar.gz
Running bootstrap.sh produced a bunch of these errors from automake:
Use of uninitialized value in exists at /usr/pkg/bin/automake line 4823, <GEN0> line 1. Use of uninitialized value in concatenation (.) or string at /usr/pkg/bin/automake line 4823, <GEN0> line 1. automake: #################### automake: ## Internal Error ## automake: #################### automake: unrequested trace `' automake: Please contact <bug-automake@gnu.org>. at /usr/pkg/share/automake-1.10/Automake/Channels.pm line 570 Automake::Channels::msg('automake', '', 'unrequested trace `\'') called at /usr/pkg/share/automake-1.10/Automake/ChannelDefs.pm line 191 Automake::ChannelDefs::prog_error('unrequested trace `\'') called at /usr/pkg/bin/automake line 4823 Automake::scan_autoconf_traces('configure.ac') called at /usr/pkg/bin/automake line 5046 Automake::scan_autoconf_files() called at /usr/pkg/bin/automake line 781
========================================== Thu Apr 2 20:51:44 CDT 2009
Going back to the 1.0.3 release.
I was getting a a bunch of apr_... warnings like
Compiling src/switch_apr.c ... src/switch_apr.c: In function `switch_thread_self': src/switch_apr.c:74: warning: implicit declaration of function `apr_os_thread_current' src/switch_apr.c:74: warning: return makes pointer from integer without a cast ... Then gmake[3]: *** [libfreeswitch_la-switch_apr.lo] Error 1
I finally got past that by installing apr-0.9.16.2.0.61 and apr-util-0.9.15. I compiled apr-util-0.9.15 myself because it was not available as a binary package. Source files are including headers from apr-util-0.9.15 that do not exist in the binary package, apr-util-1.2.8nb1.tgz.
I also got past the "Cannot guess build type" error during configure by adding "--build=i386" instead of having to use the uname wrapper to fake FreeBSD.
========================================== New error: (This one is not the fault of freeswitch)
Compiling src/switch_core.c ... src/switch_core.c: In function `switch_core_setrlimits': src/switch_core.c:795: error: `RLIMIT_AS' undeclared (first use in this function)
Turns out RLIMIT_AS is defined in /usr/include/sys/resource.h on some other systems including FreeBSD but not Dragonfly.
It is used in the source like this #if !defined(__OpenBSD__) && !defined(__NetBSD__) setrlimit(RLIMIT_AS, &rlp);
It is defined in resource.h in FreeBSD like this #define RLIMIT_AS RLIMIT_VMEM /* standard name for RLIMIT_VMEM */
I created a patch for src/switch_core.c which fixed this error.
Since then, I discussed this on the Dragonfly BSD mailing list and it is apparently going to be fixed on a future release of Dragonfly now that they are aware of it.
========================================== New error:
Tons of warnings like warning: return makes pointer from integer without a cast (this needs cleaned up)
Then error'd with gmake[8]: *** No rule to make target `iptsec/libiptsec.la', needed by ` libsofia-sip-ua.la'. Stop.
I cd'd to libs/sofia-sip/libsofia-sip-ua/su and ran make there. It completed successfully in spite of the same warnings.
Then ran make again form the top.
Got further until
========================================== New error:
making all mod_spidermonkey cd config; gmake -j1 export cd pr; gmake -j1 export cd include; gmake export cd md; gmake export ../../../config/./nsinstall: cannot make symbolic link /u1/falcon/ports/freeswitch-1.0.3/work/freeswitch-1.0.3/libs/js/nsprpub/dist/include/nspr/.: File exists
Why would it be trying to make a sym-link of '.' ??
==========================================
Giving up for now.
_______________________________________________ Freeswitch-users mailing list Freeswitch-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
-- Anthony Minessale II FreeSWITCH http://www.freeswitch.org/ ClueCon http://www.cluecon.com/ AIM: anthm MSN:anthony_minessale@hotmail.com <MSN%3Aanthony_minessale@hotmail.com> GTALK/JABBER/PAYPAL:anthony.minessale@gmail.com<PAYPAL%3Aanthony.minessale@gmail.com> IRC: irc.freenode.net #freeswitch FreeSWITCH Developer Conference sip:888@conference.freeswitch.org <sip%3A888@conference.freeswitch.org> iax:guest@conference.freeswitch.org/888 googletalk:conf+888@conference.freeswitch.org<googletalk%3Aconf%2B888@conference.freeswitch.org> pstn:213-799-1400
Thanks for the response Anthony. On Tue, Jun 23, 2009 at 08:29:13AM -0500, Anthony Minessale wrote:
You are way off base in a few places, let me see if I can clarify a bit.
Here are at least 2 pointers:
1) The release tarballs do not come with bootstrap because they already are bootstrapped. 2) FreeSWITCH does not depend on system libs so all the stuff about apr is barking up the wrong tree. we build our own apr and apr-utils
Interesting. I do not know why I got the errors I mentioned before then until I installed the exact versions of those packages it seemed to need.
I suggest you try latest svn trunk of FS and follow the BSD build guidelines on the WIKI since you say it's closely compatible.
Ok. I did this. Compilation still failed but there are significant improvements since the last time. Here is what I did and the results: ==================================================== Checked out the current trunk with svn. Patched /usr/include/sys/resource.h Since Dragonfly has fixed or will be fixing this future releases I patched the system header to add RLIMIT_AS rather than patching freeswitch to use RLIMIT_VMEM. Compilation still failed but there are significant improvements. bootstrap.sh seems to have been successful this time. I seems to have worked with the bsd shell this time. I also did not have to link make to gmake. It appears to have properly called gmake when building in sub-directories when gmake was run from the top. Configure completed successfully but there were these warnings: checking dlfcn.h usability... no checking dlfcn.h presence... yes configure: WARNING: dlfcn.h: present but cannot be compiled configure: WARNING: dlfcn.h: check for missing prerequisite headers? configure: WARNING: dlfcn.h: see the Autoconf documentation configure: WARNING: dlfcn.h: section "Present But Cannot Be Compiled" configure: WARNING: dlfcn.h: proceeding with the preprocessor's result configure: WARNING: dlfcn.h: in the future, the compiler will take precedence checking for dlfcn.h... yes I do not know if this is going to cause a problem. I did not have to use the "--build=i386" option to configure this time. Compiling ========= Still lots of warnings of: warning: return makes pointer from integer without a cast Errors: It is apparently not checking return codes from make. It continues even when there are errors. Is this intentional?? su_alloc.c: In function `su_salloc': su_alloc.c:1518: warning: return makes pointer from integer without a cast gmake[9]: *** [su_alloc.lo] Error 1 gmake[8]: *** [all] Error 2 Making all in features LTCOMPILE features.lo ... Making all in sresolv LTCOMPILE sres.lo LTCOMPILE sres_cache.lo LTCOMPILE sres_blocking.lo LTCOMPILE sresolv.lo LTCOMPILE sres_sip.lo sres_sip.c: In function `sres_sip_new': sres_sip.c:267: warning: return makes pointer from integer without a cast gmake[8]: *** [sres_sip.lo] Error 1 Making all in ipt LTCOMPILE base64.lo LTCOMPILE token64.lo LINK libipt.la ... There are about 12 errors of this nature before ending with Making all in nua LTCOMPILE nua.lo nua.c: In function `nua_create': nua.c:141: warning: return makes pointer from integer without a cast nua.c:144: warning: return makes pointer from integer without a cast gmake[9]: *** [nua.lo] Error 1 gmake[8]: *** [all] Error 2 gmake[8]: *** No rule to make target `iptsec/libiptsec.la', needed by `libsofia-sip-ua.la'. Stop. gmake[7]: *** [all-recursive] Error 1 Making all in packages gmake[6]: *** [all-recursive] Error 1 gmake[5]: *** [all] Error 2 gmake[4]: *** [/u1/falcon/ports/freeswitch-20090623/work/freeswitch-20090623/libs/sofia-sip/libsofia-sip-ua/libsofia-sip-ua.la] Error 2 gmake[3]: *** [mod_sofia-all] Error 1 gmake[2]: *** [all-recursive] Error 1 Making all in build +-------- FreeSWITCH Build Complete -----------+ + FreeSWITCH has been successfully built. + + Install by running: + + + + gmake install + +----------------------------------------------+ gmake[1]: *** [all-recursive] Error 1 gmake: *** [all] Error 2 It says it has been successfully built. Apparently part of the same problem of not checking the return codes. It does not say what most of the errors are except for near the last when it says No rule to make target `iptsec/libiptsec.la' It just says "Error 1" or Error 2" which does not tell me what the problem is.
On Tue, Jun 23, 2009 at 09:15:30PM -0500, Vincent Stemen wrote:
Ok. I did this.
Compilation still failed but there are significant improvements since the last time.
Here is what I did and the results:
It looks like some the games that sofia plays with errno makes Dragonfly unhappy. I also noticed that where the code checks for BSD-like systems (*BSD and OSX) in libsofia-sip-ua/su/sofia-sip/su_errno.h, DragonFly is omitted, so obviously one of the first steps would be to fix that (if applicable). If you disable mod_sofia in modules conf, do the rest of the default modules build OK? For the record, DragonFly and FreeBSD have rather seriously diverged at this point, DragonFly forked from FreeBSD back in the 4.10 days or so and has changed a *lot* of things since, so I don't think it's gonna be quite as easy as you expected (but it's far from impossible either). Andrew
On Tue, Jun 23, 2009 at 11:19:51PM -0400, Andrew Thompson wrote:
On Tue, Jun 23, 2009 at 09:15:30PM -0500, Vincent Stemen wrote:
Ok. I did this.
Compilation still failed but there are significant improvements since the last time.
Here is what I did and the results:
It looks like some the games that sofia plays with errno makes Dragonfly unhappy. I also noticed that where the code checks for BSD-like systems (*BSD and OSX) in libsofia-sip-ua/su/sofia-sip/su_errno.h, DragonFly is omitted, so obviously one of the first steps would be to fix that (if applicable).
If you disable mod_sofia in modules conf, do the rest of the default modules build OK?
OK. I commented out endpoints/mod_sofia. It looks like that eliminated all the errors except the one I get at the end. making all mod_spidermonkey cd config; gmake -j1 export cd pr; gmake -j1 export cd include; gmake export cd md; gmake export ../../../config/./nsinstall: cannot make symbolic link /u1/falcon/ports/freeswitch-20090623/work/freeswitch-20090623/libs/js/nsprpub/dist/include/nspr/.: File exists gmake[9]: *** [export] Error 1 gmake[8]: *** [export] Error 2 gmake[7]: *** [export] Error 2 gmake[6]: *** [export] Error 2 gmake[5]: *** [/u1/falcon/ports/freeswitch-20090623/work/freeswitch-20090623/libs/js/libjs.la] Error 2 gmake[4]: *** [all] Error 1 gmake[3]: *** [mod_spidermonkey-all] Error 1 gmake[2]: *** [all-recursive] Error 1 So, it looks like most all the problems, except for that symlink error, including the pointer cast warnings, are related to the sofia module. I notice a lot of the modules seem to be redirecting the output somewhere. Not only do they just say Error 1 or Error 2 when there is an error, they also do not show the compile commands. They just output something like "Making built-sources in su" or "Compiling src/switch_apr.c ...". Is there a log file somewhere that contains the actual compile commands and error output so you can find out what happened when there is a error? Or perhaps a configuration to enable it to come out on the console?
For the record, DragonFly and FreeBSD have rather seriously diverged at this point, DragonFly forked from FreeBSD back in the 4.10 days or so and has changed a *lot* of things since, so I don't think it's gonna be quite as easy as you expected (but it's far from impossible either).
Andrew
True, architecturally Dragonfly is becoming very different. They seem to be trying to maintain fairly good API compatibility though. Enough to constantly allow them to bring across major sub-systems, such as sound and SATA drivers, etc, from FreeBSD. So far, they have been pretty good about correcting it as soon as possible whenever one of us finds an incompatibility (Such as the RLIMIT_AS issue). Usually, all I have to do is add "-D__FreeBSD__" to CFLAGS and CPPFLAGS to compile packages that do not natively know about Dragonfly yet. Which is what I am doing with freeswitch.
On Jun 25, 2009, at 5:49 PM, Vincent wrote:
On Tue, Jun 23, 2009 at 11:19:51PM -0400, Andrew Thompson wrote:
On Tue, Jun 23, 2009 at 09:15:30PM -0500, Vincent Stemen wrote:
Ok. I did this.
Compilation still failed but there are significant improvements since the last time.
Here is what I did and the results:
It looks like some the games that sofia plays with errno makes Dragonfly unhappy. I also noticed that where the code checks for BSD-like systems (*BSD and OSX) in libsofia-sip-ua/su/sofia-sip/su_errno.h, DragonFly is omitted, so obviously one of the first steps would be to fix that (if applicable).
If you disable mod_sofia in modules conf, do the rest of the default modules build OK?
OK. I commented out endpoints/mod_sofia. It looks like that eliminated all the errors except the one I get at the end.
making all mod_spidermonkey cd config; gmake -j1 export cd pr; gmake -j1 export cd include; gmake export cd md; gmake export ../../../config/./nsinstall: cannot make symbolic link /u1/falcon/ ports/freeswitch-20090623/work/freeswitch-20090623/libs/js/nsprpub/ dist/include/nspr/.: File exists gmake[9]: *** [export] Error 1 gmake[8]: *** [export] Error 2 gmake[7]: *** [export] Error 2 gmake[6]: *** [export] Error 2 gmake[5]: *** [/u1/falcon/ports/freeswitch-20090623/work/ freeswitch-20090623/libs/js/libjs.la] Error 2 gmake[4]: *** [all] Error 1 gmake[3]: *** [mod_spidermonkey-all] Error 1 gmake[2]: *** [all-recursive] Error 1
you can also comment out that module and see if you get further.
So, it looks like most all the problems, except for that symlink error, including the pointer cast warnings, are related to the sofia module.
I notice a lot of the modules seem to be redirecting the output somewhere.
Not only do they just say Error 1 or Error 2 when there is an error, they also do not show the compile commands. They just output something like "Making built-sources in su" or "Compiling src/switch_apr.c ...". Is there a log file somewhere that contains the actual compile commands and error output so you can find out what happened when there is a error? Or perhaps a configuration to enable it to come out on the console?
VERBOSE=1 gmake
For the record, DragonFly and FreeBSD have rather seriously diverged at this point, DragonFly forked from FreeBSD back in the 4.10 days or so and has changed a *lot* of things since, so I don't think it's gonna be quite as easy as you expected (but it's far from impossible either).
Andrew
True, architecturally Dragonfly is becoming very different. They seem to be trying to maintain fairly good API compatibility though. Enough to constantly allow them to bring across major sub-systems, such as sound and SATA drivers, etc, from FreeBSD. So far, they have been pretty good about correcting it as soon as possible whenever one of us finds an incompatibility (Such as the RLIMIT_AS issue).
Usually, all I have to do is add "-D__FreeBSD__" to CFLAGS and CPPFLAGS to compile packages that do not natively know about Dragonfly yet. Which is what I am doing with freeswitch.
On Thu, Jun 25, 2009 at 06:06:04PM -0400, Michael Jerris wrote:
Is there a log file somewhere that contains the actual compile commands and error output so you can find out what happened when there is a error? Or perhaps a configuration to enable it to come out on the console?
VERBOSE=1 gmake
Thanks. That was helpfull.
On Jun 23, 2009, at 10:15 PM, Vincent Stemen <vince.freeswitch@hightek.org
wrote:
Thanks for the response Anthony.
On Tue, Jun 23, 2009 at 08:29:13AM -0500, Anthony Minessale wrote:
You are way off base in a few places, let me see if I can clarify a bit.
Here are at least 2 pointers:
1) The release tarballs do not come with bootstrap because they already are bootstrapped. 2) FreeSWITCH does not depend on system libs so all the stuff about apr is barking up the wrong tree. we build our own apr and apr-utils
Interesting. I do not know why I got the errors I mentioned before then until I installed the exact versions of those packages it seemed to need.
I suggest you try latest svn trunk of FS and follow the BSD build guidelines on the WIKI since you say it's closely compatible.
Ok. I did this.
Compilation still failed but there are significant improvements since the last time.
Here is what I did and the results:
==================================================== Checked out the current trunk with svn.
Patched /usr/include/sys/resource.h
Since Dragonfly has fixed or will be fixing this future releases I patched the system header to add RLIMIT_AS rather than patching freeswitch to use RLIMIT_VMEM.
Can we make a patch ifdefing on RLIMIT_AS to make this always work without patches to system header files?
Compilation still failed but there are significant improvements.
bootstrap.sh seems to have been successful this time.
I seems to have worked with the bsd shell this time. I also did not have to link make to gmake. It appears to have properly called gmake when building in sub-directories when gmake was run from the top.
Configure completed successfully but there were these warnings:
checking dlfcn.h usability... no checking dlfcn.h presence... yes configure: WARNING: dlfcn.h: present but cannot be compiled configure: WARNING: dlfcn.h: check for missing prerequisite headers? configure: WARNING: dlfcn.h: see the Autoconf documentation configure: WARNING: dlfcn.h: section "Present But Cannot Be Compiled" configure: WARNING: dlfcn.h: proceeding with the preprocessor's result configure: WARNING: dlfcn.h: in the future, the compiler will take precedence checking for dlfcn.h... yes
This is probably fine, it means what it says, it won't try to compile with them bit the issue should probably be reported to distro maintainers
I do not know if this is going to cause a problem.
I did not have to use the "--build=i386" option to configure this time.
Compiling =========
Still lots of warnings of: warning: return makes pointer from integer without a cast
Errors: It is apparently not checking return codes from make. It continues even when there are errors. Is this intentional??
su_alloc.c: In function `su_salloc': su_alloc.c:1518: warning: return makes pointer from integer without a cast gmake[9]: *** [su_alloc.lo] Error 1 gmake[8]: *** [all] Error 2 Making all in features LTCOMPILE features.lo ...
Making all in sresolv LTCOMPILE sres.lo LTCOMPILE sres_cache.lo LTCOMPILE sres_blocking.lo LTCOMPILE sresolv.lo LTCOMPILE sres_sip.lo sres_sip.c: In function `sres_sip_new': sres_sip.c:267: warning: return makes pointer from integer without a cast gmake[8]: *** [sres_sip.lo] Error 1 Making all in ipt LTCOMPILE base64.lo LTCOMPILE token64.lo LINK libipt.la ...
There are about 12 errors of this nature before ending with
Making all in nua LTCOMPILE nua.lo nua.c: In function `nua_create': nua.c:141: warning: return makes pointer from integer without a cast nua.c:144: warning: return makes pointer from integer without a cast gmake[9]: *** [nua.lo] Error 1 gmake[8]: *** [all] Error 2 gmake[8]: *** No rule to make target `iptsec/libiptsec.la', needed by `libsofia-sip-ua.la'. Stop. gmake[7]: *** [all-recursive] Error 1 Making all in packages gmake[6]: *** [all-recursive] Error 1 gmake[5]: *** [all] Error 2 gmake[4]: *** [/u1/falcon/ports/freeswitch-20090623/work/ freeswitch-20090623/libs/sofia-sip/libsofia-sip-ua/libsofia-sip- ua.la] Error 2 gmake[3]: *** [mod_sofia-all] Error 1 gmake[2]: *** [all-recursive] Error 1 Making all in build +-------- FreeSWITCH Build Complete -----------+ + FreeSWITCH has been successfully built. + + Install by running: + + + + gmake install + +----------------------------------------------+ gmake[1]: *** [all-recursive] Error 1 gmake: *** [all] Error 2
Can you post a bug to Jira.freeswitch.org with all these warnings, even better with patches to fix it.
It says it has been successfully built. Apparently part of the same problem of not checking the return codes.
Patches to fix this appreciated
It does not say what most of the errors are except for near the last when it says No rule to make target `iptsec/libiptsec.la'
It just says "Error 1" or Error 2" which does not tell me what the problem is.
_______________________________________________ Freeswitch-users mailing list Freeswitch-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
On Wed, Jun 24, 2009 at 12:53:23AM -0400, Michael Jerris wrote:
On Jun 23, 2009, at 10:15 PM, Vincent Stemen <vince.freeswitch@hightek.org> wrote:
Here is what I did and the results:
==================================================== Checked out the current trunk with svn.
Patched /usr/include/sys/resource.h
Since Dragonfly has fixed or will be fixing this future releases I patched the system header to add RLIMIT_AS rather than patching freeswitch to use RLIMIT_VMEM.
Can we make a patch ifdefing on RLIMIT_AS to make this always work without patches to system header files?
Thanks for the responses Michael. I did this for attempting to compile freeswitch-1.0.3 and trunk as of a couple months ago. It would not apply to the current freeswitch trunk though. Apparently there have been changes to that area of the code. Since RLIMIT_AS is apparently a posix standard definition, I think this is fixed in Dragonfly HEAD and should not be a problem with future releases. I could go ahead and make a new patch when I get a chance if you still want me to, for compatibility with older Dragonfly releases.
Compiling =========
Still lots of warnings of: warning: return makes pointer from integer without a cast
Errors: It is apparently not checking return codes from make. It continues even when there are errors. Is this intentional??
su_alloc.c: In function `su_salloc': su_alloc.c:1518: warning: return makes pointer from integer without a cast gmake[9]: *** [su_alloc.lo] Error 1 gmake[8]: *** [all] Error 2 Making all in features LTCOMPILE features.lo ...
Making all in sresolv LTCOMPILE sres.lo LTCOMPILE sres_cache.lo LTCOMPILE sres_blocking.lo LTCOMPILE sresolv.lo LTCOMPILE sres_sip.lo sres_sip.c: In function `sres_sip_new': sres_sip.c:267: warning: return makes pointer from integer without a cast gmake[8]: *** [sres_sip.lo] Error 1 Making all in ipt LTCOMPILE base64.lo LTCOMPILE token64.lo LINK libipt.la ...
There are about 12 errors of this nature before ending with
Making all in nua LTCOMPILE nua.lo nua.c: In function `nua_create': nua.c:141: warning: return makes pointer from integer without a cast nua.c:144: warning: return makes pointer from integer without a cast gmake[9]: *** [nua.lo] Error 1 gmake[8]: *** [all] Error 2 gmake[8]: *** No rule to make target `iptsec/libiptsec.la', needed by `libsofia-sip-ua.la'. Stop. gmake[7]: *** [all-recursive] Error 1 Making all in packages gmake[6]: *** [all-recursive] Error 1 gmake[5]: *** [all] Error 2 gmake[4]: *** [/u1/falcon/ports/freeswitch-20090623/work/ freeswitch-20090623/libs/sofia-sip/libsofia-sip-ua/libsofia-sip- ua.la] Error 2 gmake[3]: *** [mod_sofia-all] Error 1 gmake[2]: *** [all-recursive] Error 1 Making all in build +-------- FreeSWITCH Build Complete -----------+ + FreeSWITCH has been successfully built. + + Install by running: + + + + gmake install + +----------------------------------------------+ gmake[1]: *** [all-recursive] Error 1 gmake: *** [all] Error 2
Can you post a bug to Jira.freeswitch.org with all these warnings, even better with patches to fix it.
It says it has been successfully built. Apparently part of the same problem of not checking the return codes.
Patches to fix this appreciated
Heh :-) OK. If I get it working and we end up using freeswitch, I will probably take a look at seeing if I can fix some or all of these warnings and create patches.
It does not say what most of the errors are except for near the last when it says No rule to make target `iptsec/libiptsec.la'
It just says "Error 1" or Error 2" which does not tell me what the problem is.
On Wed, Jun 24, 2009 at 12:53:23AM -0400, Michael Jerris wrote:
Can you post a bug to Jira.freeswitch.org with all these warnings, even better with patches to fix it.
OK. I think I have narrowed the problem down to 3 issues. 1. The build system is treating even a single warning as a critical error and aborting compilation in that directory. 2. Compilation continues into the next directory even though compilation of the previous directory was aborted, as you can see in the make output below where it went on to build "features". This can cause a chain reaction of other errors because stuff it expects to be there did not get built in previous stages. I suspect that is also the source of the 'symbolic link' error I was getting. I did not get that on this last compilation after fixing some of the warnings (see below). It can also make it possible to get to the end of the build and not know that stuff did not get compiled further back, leaving the package incomplete. 3. Lots of "return makes pointer from integer without a cast" warnings throughout the sofia-sip tree. This one, of course, is not the actual show stopper but is triggering the above problems and needs cleaned up none the less. ================= Making all in su LTCOMPILE su.lo LTCOMPILE su_errno.lo LTCOMPILE su_addrinfo.lo LTCOMPILE su_alloc.lo su_alloc.c: In function `sub_alloc': su_alloc.c:428: warning: return makes pointer from integer without a cast su_alloc.c:511: warning: return makes pointer from integer without a cast su_alloc.c: In function `su_home_new': su_alloc.c:555: warning: return makes pointer from integer without a cast su_alloc.c:557: warning: return makes pointer from integer without a cast su_alloc.c: In function `su_home_clone': su_alloc.c:730: warning: return makes pointer from integer without a cast su_alloc.c:732: warning: return makes pointer from integer without a cast su_alloc.c: In function `su_realloc': su_alloc.c:1315: warning: return makes pointer from integer without a cast su_alloc.c:1319: warning: return makes pointer from integer without a cast su_alloc.c: In function `su_salloc': su_alloc.c:1518: warning: return makes pointer from integer without a cast gmake[9]: *** [su_alloc.lo] Error 1 gmake[8]: *** [all] Error 2 Making all in features ... ================= I confirmed the abort on warning issue (1) by fixing all warnings in su_alloc.c. As you can see below, it went past it just fine until it got a warning in su_sprintf.c. ================= Making all in su LTCOMPILE su.lo LTCOMPILE su_errno.lo LTCOMPILE su_addrinfo.lo LTCOMPILE su_alloc.lo LTCOMPILE su_alloc_lock.lo LTCOMPILE su_strdup.lo LTCOMPILE su_sprintf.lo su_sprintf.c: In function `su_vsprintf': su_sprintf.c:98: warning: return makes pointer from integer without a cast gmake[9]: *** [su_sprintf.lo] Error 1 gmake[8]: *** [all] Error 2 Making all in features ... ================= The issue below of saying it was successfull, when it was not, is apparently part of issue 2. It continued into the "build" directory after the previous errors. ================= Making all in packages gmake[6]: *** [all-recursive] Error 1 gmake[5]: *** [all] Error 2 gmake[4]: *** [/u1/falcon/ports/freeswitch-20090623/work/freeswitch-20090623/libs/sofia-sip/libsofia-sip-ua/libsofia-sip-ua.la] Error 2 gmake[3]: *** [mod_sofia-all] Error 1 gmake[2]: *** [all-recursive] Error 1 Making all in build +-------- FreeSWITCH Build Complete -----------+ + FreeSWITCH has been successfully built. + + Install by running: + + + + gmake install + +----------------------------------------------+ gmake[1]: *** [all-recursive] Error 1 gmake: *** [all] Error 2 ================= I went ahead and established an account on jira.freeswitch.org. I see there are separate projects for "FreeSWITCH-Buildsystem" and "sofia-sip". I am guessing I should post two separate reports, one for issues 1 and 2 for the Buildsystem and one in sofia-sip for issue 3 since all the warnings seem to be from that code. I do not know the build system well enough to solve issues 1 and 2 at this time. However, I already have a patch I will provide for su_alloc.c and can continue working on resolving more of the casting warnings if somebody else can work on the build issue, which is the real show stopper.
On Jun 26, 2009, at 10:17 PM, Vincent Stemen <vince.freeswitch@hightek.org
wrote:
On Wed, Jun 24, 2009 at 12:53:23AM -0400, Michael Jerris wrote:
Can you post a bug to Jira.freeswitch.org with all these warnings, even better with patches to fix it.
OK. I think I have narrowed the problem down to 3 issues.
1. The build system is treating even a single warning as a critical error and aborting compilation in that directory.
As intended.
2. Compilation continues into the next directory even though compilation of the previous directory was aborted, as you can see in the make output below where it went on to build "features". This can cause a chain reaction of other errors because stuff it expects to be there did not get built in previous stages. I suspect that is also the source of the 'symbolic link' error I was getting. I did not get that on this last compilation after fixing some of the warnings (see below). It can also make it possible to get to the end of the build and not know that stuff did not get compiled further back, leaving the package incomplete.
I've looked for this one and have not been able to nail it down. I must be missing an || exit somewhere in the module makefiles? Everytime I go to reproduce this issue I can't reproduce it.
3. Lots of "return makes pointer from integer without a cast" warnings throughout the sofia-sip tree. This one, of course, is not the actual show stopper but is triggering the above problems and needs cleaned up none the less.
I am sure these are trivial enough to fix but am a bit puzzled why I don't see them on. Any other platform. What version of gcc is this? Does dragonfly patch gcc to report more warnings than other platforms?
=================
Making all in su LTCOMPILE su.lo LTCOMPILE su_errno.lo LTCOMPILE su_addrinfo.lo LTCOMPILE su_alloc.lo su_alloc.c: In function `sub_alloc': su_alloc.c:428: warning: return makes pointer from integer without a cast su_alloc.c:511: warning: return makes pointer from integer without a cast su_alloc.c: In function `su_home_new': su_alloc.c:555: warning: return makes pointer from integer without a cast su_alloc.c:557: warning: return makes pointer from integer without a cast su_alloc.c: In function `su_home_clone': su_alloc.c:730: warning: return makes pointer from integer without a cast su_alloc.c:732: warning: return makes pointer from integer without a cast su_alloc.c: In function `su_realloc': su_alloc.c:1315: warning: return makes pointer from integer without a cast su_alloc.c:1319: warning: return makes pointer from integer without a cast su_alloc.c: In function `su_salloc': su_alloc.c:1518: warning: return makes pointer from integer without a cast gmake[9]: *** [su_alloc.lo] Error 1 gmake[8]: *** [all] Error 2 Making all in features ...
================= I confirmed the abort on warning issue (1) by fixing all warnings in su_alloc.c. As you can see below, it went past it just fine until it got a warning in su_sprintf.c. =================
Making all in su LTCOMPILE su.lo LTCOMPILE su_errno.lo LTCOMPILE su_addrinfo.lo LTCOMPILE su_alloc.lo LTCOMPILE su_alloc_lock.lo LTCOMPILE su_strdup.lo LTCOMPILE su_sprintf.lo su_sprintf.c: In function `su_vsprintf': su_sprintf.c:98: warning: return makes pointer from integer without a cast gmake[9]: *** [su_sprintf.lo] Error 1 gmake[8]: *** [all] Error 2 Making all in features ...
================= The issue below of saying it was successfull, when it was not, is apparently part of issue 2. It continued into the "build" directory after the previous errors. =================
Making all in packages gmake[6]: *** [all-recursive] Error 1 gmake[5]: *** [all] Error 2 gmake[4]: *** [/u1/falcon/ports/freeswitch-20090623/work/ freeswitch-20090623/libs/sofia-sip/libsofia-sip-ua/libsofia-sip- ua.la] Error 2 gmake[3]: *** [mod_sofia-all] Error 1 gmake[2]: *** [all-recursive] Error 1 Making all in build +-------- FreeSWITCH Build Complete -----------+ + FreeSWITCH has been successfully built. + + Install by running: + + + + gmake install + +----------------------------------------------+ gmake[1]: *** [all-recursive] Error 1 gmake: *** [all] Error 2
=================
I went ahead and established an account on jira.freeswitch.org. I see there are separate projects for "FreeSWITCH-Buildsystem" and "sofia-sip". I am guessing I should post two separate reports, one for issues 1 and 2 for the Buildsystem and one in sofia-sip for issue 3 since all the warnings seem to be from that code.
I do not know the build system well enough to solve issues 1 and 2 at this time. However, I already have a patch I will provide for su_alloc.c and can continue working on resolving more of the casting warnings if somebody else can work on the build issue, which is the real show stopper.
_______________________________________________ Freeswitch-users mailing list Freeswitch-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
On Fri, Jun 26, 2009 at 11:19:02PM -0400, Michael Jerris wrote:
On Jun 26, 2009, at 10:17 PM, Vincent Stemen <vince.freeswitch@hightek.org
wrote:
On Wed, Jun 24, 2009 at 12:53:23AM -0400, Michael Jerris wrote:
Can you post a bug to Jira.freeswitch.org with all these warnings, even better with patches to fix it.
OK. I think I have narrowed the problem down to 3 issues.
1. The build system is treating even a single warning as a critical error and aborting compilation in that directory.
As intended.
Interesting. I don't think I have seen any other projects force the build to fail on warnings. Although, I think that is better than allowing warnings to accumulate and never get cleaned up like I see on a lot of the projects out there.
2. Compilation continues into the next directory even though compilation of the previous directory was aborted, as you can see in the make output below where it went on to build "features". This can cause a chain reaction of other errors because stuff it expects to be there did not get built in previous stages. I suspect that is also the source of the 'symbolic link' error I was getting. I did not get that on this last compilation after fixing some of the warnings (see below). It can also make it possible to get to the end of the build and not know that stuff did not get compiled further back, leaving the package incomplete.
I've looked for this one and have not been able to nail it down. I must be missing an || exit somewhere in the module makefiles? Everytime I go to reproduce this issue I can't reproduce it.
Since you are aware of it and working on it, do you still want me to take the time to create a problem report on jira for this? If so, do you want to add a platform option for Dragonfly BSD first? Or should I just select FreeBSD?
3. Lots of "return makes pointer from integer without a cast" warnings throughout the sofia-sip tree. This one, of course, is not the actual show stopper but is triggering the above problems and needs cleaned up none the less.
I am sure these are trivial enough to fix but am a bit puzzled why I don't see them on. Any other platform. What version of gcc is this? Does dragonfly patch gcc to report more warnings than other platforms?
Hmm.. It could be that you guys are all running gcc-4 (?). I am working on a bit older installation that is running gcc 3.4.6. Although, I was told on the dragonfly irc that gcc-4 generates more warnings by default than gcc-3. So I don't know. They said they did not know of any special gcc configurations or patches for gcc on Dragonfly. There was one thing unanimous though. Everybody I spoke with on the #c and the #dragonflybsd irc did not like the way the lines are coded that are generating most of the errors :-). e.g. return (void)(errno = EINVAL), NULL; I went ahead and posted a bug report on jira under the sofia-sip project, with a patch that fixes all the warnings for the first file (su_alloc.c). More patches will follow. I went ahead and selected FreeBSD as the platform. I thought I would point that out in case you guys want to add Dragonfly BSD and change the platform on this issue report.
On Wed, Jun 24, 2009 at 12:53:23AM -0400, Michael Jerris wrote:
Can we make a patch ifdefing on RLIMIT_AS to make this always work without patches to system header files?
I have attached a patch to src/switch_core.c that fixes this.
Update: I tested compiling on my Dragonfly leaf development account which is running DragonFly 2.2.1-RELEASE with gcc-4.1.2. I did not get any of the cast warnings. It is apparently a gcc issue since I am running gcc-3.4.6 on my workstation with an older Dragonfly installation. Apparently gcc-3 does not like the "return x, y;" syntax that is used all over the sofia code. That is the source of most of the warnings (except 1 or 2 so far that just needed a cast). So, on DF 2.2.1, it appeared to compile almost successfully until near the end. It still has that sym link error and still has the build bug where it does not know there was an error and goes on to tell you it was successful. Here is the final output: making all mod_spidermonkey cd config; gmake -j1 export cd pr; gmake -j1 export cd include; gmake export cd md; gmake export ../../../config/./nsinstall: cannot make symbolic link /home/vince/freeswitch/freeswitch-20090623/libs/js/nsprpub/dist/include/nspr/.: Invalid argument gmake[9]: *** [export] Error 1 gmake[8]: *** [export] Error 2 gmake[7]: *** [export] Error 2 gmake[6]: *** [export] Error 2 gmake[5]: *** [/home/vince/freeswitch/freeswitch-20090623/libs/js/libjs.la] Error 2 gmake[4]: *** [all] Error 1 gmake[3]: *** [mod_spidermonkey-all] Error 1 gmake[2]: *** [all-recursive] Error 1 Making all in build +-------- FreeSWITCH Build Complete -----------+ + FreeSWITCH has been successfully built. + + Install by running: + + + + gmake install + +----------------------------------------------+ gmake[1]: *** [all-recursive] Error 1 gmake: *** [all] Error 2
participants (5)
-
Andrew Thompson
-
Anthony Minessale
-
Michael Jerris
-
Vincent
-
Vincent Stemen