s3-rpc_server: Only support static build.

[Andrew Bartlett]

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. 

> This approach has some issues. Some RPC services depend on other RPC services, 
> so the order in which the RPC services are set up matters. That the configure 
> script created only a list of init functions but we need to call the shutdown 
> functions in the reverse order we set it up.
> 
> Maybe you know that we have rewritten large parts of the spoolss code and used 
> winreg instead of tdb files. With these changed and other changes to remove 
> global variables in Samba we had to introduce a way to call functions for 
> maintenance when a RPC service starts. We created a structure called 
> 'rpc_srv_callbacks' where you can set an init and shutdown function and a 
> pointer for userdata. With this structure the function prototype has changed 
> from:
> 
> NTSTATUS rpc_<service>_init(void);
> 
> to
> 
> NTSTATUS rpc_<service>_init(const struct rpc_srv_callbacks *rpc_srv_cb);
> 
> For spoolss we use an init function you can set with the callback structure to 
> migrate the printing tdb's to winreg and we use a shutdown function to clean 
> up memory.
> 
> The shutdown functions were never called and they are needed. Another task of 
> this function is to register or deregister RPC services in smbd.
> 
> So here is a proposed patchset which calls the init functions in the right 
> order, calls the needed shutdown functions and builds the RPC services only 
> staically.

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.

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'.  

For example, Samba4 is built with -Wl,no-undefined (which is the default
on Gentoo), and does not export all symbols from the plugin loading
binary to plugins.  Instead, plugins link against the library that they
are loaded into and any libraries on which they depend, ensuring that
they properly declare exactly what they depend on.  

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

Andrew Bartlett

-- 
Andrew Bartlett                                http://samba.org/~abartlet/
Authentication Developer, Samba Team           http://samba.org
Samba Developer, Cisco Inc.