proposal: merge waf build of s4 to master

[tridge at samba.org]

Hi Volker,

 > Multiple builds with history. libtdb-samba4.so being rebuilt
 > with new tdb, old binaries still hanging around linking
 > against the old one. Or will you include the git hash of the
 > build in the library name?

There are several ways to answer this.

I'll start with the simplest, which is how to get the current Samba
build behaviour. You can get it either as a default for building in
source3, or you can get it on a per developer basis.

To get it for just you, you would configure like this:

  ./configure --disable-shared

or like this:

  ./configure --builtin-libraries=ALL

these are equivalent, but the 2nd approach allows you to select a list
of libraries that you are happy to have as shared libraries.

If instead you would like this as the default in source3, then you
could do something like this in source3/wscript, in the set_options()
section: 

    opt.BUILTIN_DEFAULT('replace tdb tevent talloc')

that says to default to having those 4 libraries as 'builtin'
libraries, when building in the source3 directory. It is up to the
person doing the source3 port of waf to decide what those defaults
should be, while consulting with the main Samba3 developers.

ok, so that's the answer assuming you really don't want these shared
libraries.

Now to answer your specific concerns, to try to allay your fears of
shared libs for debugging.

You are right that the way shared libs are done in many projects, that
you can end up using the wrong library with the wrong binary. One of
the things I've tried to do with the waf build is to (as far as
possible) make it very hard to get these sorts of problems.

One of the keys to that is the use of rpath by default for
developers. Using rpath ties the library to use directly into the
binary. So you are not relying on the loader finding the right library
using ld.so.conf or LD_LIBARRY_PATH, instead the binary has the path
to the right library builtin. 

The next key to solving this is strong content based depenencies in
the build system. Each time you run 'make' (or 'waf' if you run it
directly) the contents of all the dependencies are checked, and the
binaries and libraries are relinked if need be. So each build will
ensure that the right rpath is in the binary. 

You could fool it, for example you could (in source4) do something
like:

  cp /usr/local/samba/lib/libgensec-samba4.so bin/default/source4/auth/gensec/

and you would indeed fool the system. If you then ran the bin/samba
binary you'd get the wrong library. That is probably not a very common
thing to do however. In normal development I think you'll find that
getting the wrong library with the wrong binary is quite difficult, as
the rpath tying makes it much harder to do than with non-rpath
linking.

Still, if you are not convinced, then of course you can use one of the
methods I described above to either disable the use of shared libs, or
disable them by default for source3.

Cheers, Tridge