Samba 4 build system (was: Re: Samba3 build farm can't execute smbtorture4 anymore)

Volker Lendecke Volker.Lendecke at SerNet.DE
Mon Dec 24 07:59:02 GMT 2007

On Mon, Dec 24, 2007 at 02:23:00AM +0100, Jelmer Vernooij wrote:

> The current hack (building ldb and its modules as .so's) was enabled to
> work around the fact that the build system didn't handle these circular
> dependencies. I agree this is not optimal and should be fixed at some
> point, although I still don't understand why it is such a huge problem
> to rely on shared libs for now, since all the systems we run on support
> them and setting LD_LIBRARY_PATH or equivalent is sufficient to use the
> shared libraries.

It does work, and thanks to metze (I think..) the build farm
runs samba4 torture again for samba3. The problem I have
with LD_LIBRARY_PATH is that I have multiple installations
on my disk here, and with having to depend on shared libs I
am not able to just call this or that instance without
correctly configuring LD_LIBRARY_PATH. The alternative would
be to make that a relative path, but then I would have to cd
into the correct directory always.

There are always solutions to work with shared libs, but
when debugging stuff I know at some point I will get stuff
wrong and run against the wrong library. For libraries that
are either trivially simple (i.e. libwbclient) or mature
enough to only change very infrequently (i.e. libc or for
example talloc) this is ok even on a development machine,
but anything that still sees considerable change (and I
would consider ldb in that category) this is just a huge
pain. IMO it falls into the same category as the Samba4
single process mode. Everything in one place is far easier
to debug than everything spread around.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url :

More information about the samba-technical mailing list