I have just started to revise the s3-linking of internal subsystems
as static vs. shared libraries.
As a first step, I have cleaned the SMB_LIBRARY mechanism so that
I could remove the @LIBFOO_STATIC@ stuff from the object
collections. (branches master / v3-4-test)
This was based on a patch found in the debian packaging code.
There are a few items that are on my list next:
* I would like to unify the use of external libs:
Therefore I would like to rename the configure parameter
"--with-wbclient" to "--enable-external-libwbclient"
to be consistent with "--enable-external-talloc".
* I would also like to (re-)unify the configuration of libwbclient
with the other libs (libtalloc, libtdb, libnetapi, ...) to be
configured with SMB_LIBRARY().
This means that it will also be possible again to build and link
libwbclient statically, removing the restriction imposed when
libsmbclient was originally created that it should only be
possible to build/link libwbclient statically with
--enable-develper. I think this is artificial. Sometimes you just
want to link a library statically. Vendors are patching the sources
to allow for building and linking statically anyways.
* Finally, I would come up with a linking scheme that copes
better with the fact that our libraries like libtalloc start to
appear as sytem libraries in the distributions (maybe triggered
by our introduction of building libtalloc and friends shared in
A scheme for building (that is basically also what samba4 does)
initially discussed with Jelmer and Lars (among others)
on irc could be the following:
- check wheter libfoo is in the system
and check whether it suits our version requirements
(current checks use pkg-config for this)
- if libfoo is available and version is ok, then
adapt compile / link flags according to pkg-config to
link against that library
- if either the library is not found or version is not ok,
then build libfoo internally and link it in _statically_
This would be the scheme for very isolated libraries like
Other, more samba-specific subsystems that won't find their
way into distributions any time soon could still be built and
linked dynamically internally.
Folks, I would like to hear your comments on the suggestions above.
Cheers - Michael
Michael Adam <ma@xxxxxxxxx> <obnox@xxxxxxxxx>
SerNet GmbH, Bahnhofsallee 1b, 37081 Göttingen
phone: +49-551-370000-0, fax: +49-551-370000-9
AG Göttingen, HRB 2816, GF: Dr. Johannes Loxen
http://www.SerNet.DE, mailto: Info @ SerNet.DE