s3-rpc_server: Only support static build.

[Andreas Schneider]

On Tuesday 21 December 2010 12:59:46 Andrew Bartlett wrote:
> On Mon, 2010-12-20 at 14:51 +0100, Andreas Schneider wrote:
> > Hi Team,
> > 
> > we face some issues with the RPC service init and shutdown functions. In
> > the past it was possible to compile RPC services as shared modules or as
> > static modules linked directly into smbd.
> 
> One comment I will make is that Samba4 has been going in the opposite
> direction of late.  Using modules has helped to unravel circular
> dependencies as we strive to have a fine-grained directed acyclic
> dependency graph without multiple instantiation and library loops.

Hi Andrew,

this is the short time solution. In the long term wie should only use modules.
 
> I'm concerned that this may limit our ability to correctly build Samba
> as a series of libraries in future.  As I mention, Samba4 has been going
> in the other direction, and while it does not have these
> cross-dependencies (most things depend directly down on ldb), it seems
> to me that we may wish to solve the init order and subsystem
> dependencies issue distinctly from the creation of RPC server modules.

Yes, the the long term the rpc server should ONLY use modules for rpc 
services. Each RPC module should provide a function which could be called with 
dlopen() to get a list of dependencies.

Example:
Each module requires epmapper
netlogon requires samr and lsarpc
winreg requires samr
spoolss requires winreg

We need to create a dependency tree with these information and start rpc 
services in the right order.

Same to unload modules. If you want to remove an rpc service than this should 
be only possible if it isn't required by another rpc service anymore.

> I should make it clear, lest this discussion get derailed, this isn't a
> matter of 'waf can't handle', but more that 'with waf, we can finally do
> this right'.

Yes, please. Currently it is completely broken. I would like to get this patch 
in and work on a more correct fix of the problem in future.

> Could this init ordering also be solved with proper dependency
> declarations?

See above :)


	-- andreas