[Freeswitch-users] Compiling freeswitch for Dragonfly BSD

Tue Jun 23 21:53:23 PDT 2009

On Jun 23, 2009, at 10:15 PM, Vincent Stemen <vince.freeswitch at 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 at lists.freeswitch.org
> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
> http://www.freeswitch.org