[asterisk-dev] repost: fixes to zaptel makefile

Kevin P. Fleming kpfleming at digium.com
Mon Nov 6 13:41:29 MST 2006


Tzafrir Cohen wrote:

> * 'make all' should not depend on the menuselect target.

Why not? We will decide which utilities to build based on the dependency
information found by the configure script, which menuselect then turns
into target information for the Makefile.

> * menuselect should be run manually: (to allow running it more than
> * once).

You can already run it as many times as you like.

> * make should not run configure on its own:
>   - Allow passing CFLAGS and other vars to ./configure .
>   - Allow passing custom arguments to ./configure .

You can already run configure yourself before running 'make'.

> One simple source for the list of modules to build: MOD_LIST
> * A simple name: a module in the current directory
> * A name that ends with '/': a subdirectory. So far only 
>   works for kernel 2.6

Looks fine to me, but we will need to ensure that building on kernel 2.4
still works.

> rev 1462: takes a stab at simplifying the name of libtonezone .
> 
> http://svn.digium.com/view/zaptel?rev=1462&view=rev
> 
> Could anybody explain to me why is it overly-complex?

This is standard procedure for installed libraries. The 'real' filename
is the fully-qualified version, and there are symlinks that provide the
shortened (no minor version, no version at all) names for applications
to link against. However, I believe ldconfig itself will create these
links if they do not exist.

Also, the 'soname' in the library is important; if an application links
against 'libtonezone.so' (by using -lso argument to the linker), you
want the resulting binary to actually reference libtonezone.so.1.0. This
way, if a newer (incompatible) version is installed, the application
won't try to use it at runtime, and will fail to link at linktime. This,
again, is standard procedure for userspace libraries.

In spite of the fact that it is highly unlikely that libtonezone will
ever have an incompatible future release, it's still safer to have the
applications have a proper reference to the version-numbered library.


More information about the asterisk-dev mailing list