libraries and the build system

[Stefan (metze) Metzmacher]

Jelmer Vernooij schrieb:

> |
> I'm not saying we should use shared libraries everywhere - rather that
> I would like to abstract away the difference between shared libs,
> static libs and "object lists".

I think like this:
there are many differences between them, they need other compiler and linker flags,
and other stuff.

I'm ok with abstract SMB_SUBSYSTEM() and SMB_EXT_LIB(),

maybe we could also abstract SMB_BINARAY() and SMB_LIBRARY(), but I don't think that makes much sense.

I'm also ok with PRELINKING (for faster build/linnking) or PREPACKING(for smaller binaries) of 
subsystems
here I mean creating a big subsystem.o or subsystem.a
(I think we first should not allow subsystem.so here, maybe we could add that when the whole 
buildsystem is complete, but not for now!)

I want the register_subsystem() register_backend() back!


> 
> What I would like to do (in chronological order):
> 
> 1. Support the constructor attribute on init functions for gcc builds
> (keep using init function lists for other compilers). I'm almost done
> with a patch for this.
> 
> An example (internal) init function could be something like:
> 
> void CONSTRUCTOR(foo_init) (void)
> {
> ~    NTSTATUS status = register_bar(&blah);
> ~     if (NT_STATUS_IS_ERR(status)) {
> ~       MODULE_LOAD_ERROR(status);
> ~    }
> }
> 
> CONSTRUCTOR either gets translated to the constructor attribute or
> will be used to generate the list of init functions.

to use a list of init functions all time is better so we can controll the order!

for each SMB_BINARY()
we should rename the current main() functions to a binary_<name>_main() function

and generate a
main()
{
	init_bla();
	init_blu();

	return binary_<name>_main();
}

and for each SMB_LIBRARY()

we should also generate a library_<name>_init() function, which should look simular.
And here we can use the CONSTRUCTOR or __init() symbol depending of the compiler/linker/loader.
otherwise don't allow th a build of the SMB_LIBRARY()

> 
> 2. Continue with the 'buildtest' branch and get it running on the
> buildfarm (still need to trim it down)

good!

> 
> 3. Fix the support for static libraries (if supported by the OS), that
> can then become the default (rather then the object lists as used
> now). This will give us smaller binaries as well

also libraries which will be used by thrid-party apps should be not build by the same rule
as prepacked subsystems...!

> 
> 4. (Re-) add support for creating shared libraries (whether these are
> used by default for subsystems is up to the user).

as above we should seperate module shared libs which will be loaded into samba (SMB_MODULE() )
and shared libs which can later accessed by third-party apps (SMB_LIBRARY() )

so we need to readd support for shared SMB_MODULE()'s

> 
> We might want to have a list of Samba-parts that can be built as a
> shared library so they can be used by 3rd-party tools, though this
> wouldn't have to be used by the main binaries. Perhaps something like :
> 
> ~ ./configure --prefer-output-type={static,objlist,shared}

we should use SMB_LIBRARY() for that and let the configure check decide if we build .a and/or .so


> 5. Re-add support for loading shared modules run-time. The
> "init_plugin" function needs to be called if the constructor attribute
> is not available. We can make sure that modules don't call unresolved
> symbols by two ways (pick one):

we should always use the init_module function symbol!

> 
> ~ a. Linking against the subsystems the module requires. The linker
> will take care of loading the subsystems the module depends on
> ~ b. Using dlsym to check if the symbol is available. Example init
> function:
> 
> void CONSTRUCTOR(my_auth_plugin_init) (void)
> {
> ~    void *handle = dlopen(NULL, 0);  /* Open the current program */
> ~    if (dlsym(handle, "auth_register") != NULL) {
> ~        auth_register(&my_auth_plugin);
> ~    }
> ~    dlclose(handle);
> }
> 
> (the dlsym() trick could of course be put into a FUNCTION_AVAILABLE()
> macro or function).

I don't like that trick

> 
> These changes wouldn't make library support a requirement for building
> Samba nor would they use shared libraries by default.
> 
> Of course, I would make sure that the main build keeps running while
> playing with the build system changes in the buildtest branch...
> 
> What do you think?
> 
> Jelmer
> 
> | The costs include:
> |
> | - managing shared lib versioning. This is a _major_ pain. We would
> |  need someone to take responsibility long term for shared library
> | versioning of Samba libs. That will be a lot of work.

because of this we should allow this only for SMB_LIBRARY() and which welldefined interfaces

> |
> | - installation pain. I really hate the shell script gymnastics that
> |  libtool goes through to avoid the nasties of library copy/install
> |  on some platforms.

me too!

> |
> | - portability. every system seems to have their own way of doing
> | everything.
> |
> |
> | I am not against the possibility of _optionally_ supporting shared
> |  libs, but I would be most certainly against making them the
> | default without very careful consideration.
as above we may can think of adding this feature when all the hard work in the buildsystem is done



-- 
metze

Stefan Metzmacher <metze at samba.org> www.samba.org