Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 3 Next »

Environment Tips

  • Send the build output to a different directory than the source code. This has 3 advantages: easy to start over, easy to see source changes, allows for multiple sets of build settings. To direct output to different directory, simple run ./configure script from another directory.
  • This is handy when you want to mass delete all build output when you want to start over. Its also handy for creating multiple build with differnent configuration
    Example:
     mkdir my-build-output
     cd my-build-output
     ../configure 
    
  • Used ccache when same rebuilding source tree often. For CentOS or Redhat install ccache rpm from dag wiers repository at: http://dag.wieers.com/packages/ccache/. For Fedora use sudo yum install ccache. To enable ccache, add the following settings to your environment before running any make targets
     export CC="/usr/bin/ccache gcc"
     export CXX="/usr/bin/ccache g++"
    
  • After running autoreconf -if once, subsequent times you can just run autoreconf to speed things up a bit.
  • If you edit a Makefile.am, you may not have to re-run autoreconf or configure. Built into the Makefile is the ability to regenerate itself, simply run your target as you normally would. If you make a change that is of improper syntax, you will have to rerun autoreconf and configure
  • If you want to rerun ./configure command with the same arguments, you can just run ./config.status --recheck && ./config.status

./configure Tips

./configure script run as part of the build proccess is used to define build settings and enable or disable options. Here are some useful settings and modes of operation you may find useful.

  • If you have installed the openfire RPM in a non standard location (i.e. other than /opt/openfire) :
       OPENFIRE_HOME=path-to-openfire
    
  • If you plan to install multiple builds, you can direct the installation to a directory other than
    /usr/local/sipx
    by adding this switch. You can use any directory name
      --prefix=/opt/sipx
    
  • If you want CDR support, add the following option. (Requires ruby and development tools like gem and rake)
     --enable-cdr
    
  • To speed up
    configure
    step, this can decrease the time by 40%. You can use any file name
     --cache-file=/tmp/ac-cache-file
    

make Tips

  • To supress some (but not nearly all) extraneous output make -s
  • Running make with no targets will return useful list of targets. This is useful if you're unfamiliar with building sipXecs or if you often forget a target name or exact syntax.

Troubleshooting

  • If autoreconf produces error messages containing symbols that contain "CXX", you probably don't have the autoconfigure support for C++ sources installed. This may mean you need to install the C++ support for your distro, or that your installed autoconfigure needs updating.
  • If your build reports errors on named related tests, you do not have the nameserver running or your nameserver is mis-configured. In this case edit out the offending tests.
  • If you are running on older harware some of the timer related tests may report errors. Ignore these errors.
  • Keep your build environment clean. It is best to not have the sipx*devel tools installed on the machine ( or virtual machine file system ) where you want to build your source code. You can pick up stale libraries and includes that can drive you up the wall. If you are building RPMS, note that RPMS are also installed when you build them. You can list all the installed RPMS using rpm -q -all.
  • No labels