proposal: merge waf build of s4 to master

[Volker Lendecke]

On Tue, Apr 06, 2010 at 07:33:33PM +1000, tridge at samba.org wrote:
>  > 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.

What blocks us from putting similar capabilities into the
autogen based system?

Volker
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: Digital signature
URL: <http://lists.samba.org/pipermail/samba-technical/attachments/20100406/4ddf78aa/attachment.pgp>