On Tue, Apr 06, 2010 at 07:33:33PM +1000, [email protected] 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()
> 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
> 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
> 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
> 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?