libraries and the build system

Jelmer Vernooij jelmer at
Wed Nov 17 19:55:06 GMT 2004

Hash: SHA1

Hi Tridge,

tridge at wrote:

| Please don't go crazy with shared library features. There are many
|  cool things that can be done with shared libs, but they come at a
|  cost.
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".

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.

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

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

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

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}

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):

~ 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

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

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?


| 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.
| - installation pain. I really hate the shell script gymnastics that
|  libtool goes through to avoid the nasties of library copy/install
|  on some platforms.
| - 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.
| Note that the recent build changes have already broken the build on
|  several systems. We need to get those systems back and working
| again, and not break more.
Samba 4 currently works again on


Version: GnuPG v1.2.5 (GNU/Linux)
Comment: Using GnuPG with Thunderbird -


More information about the samba-technical mailing list