IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
Use the more general mechanism.
The enable_developer-check is preserved, of course.
Michael
(This used to be commit 4321d5aba7ec808aee473c1123027f14bfa19f19)
This, too, can be turned to static linking by providing the configure
parameter --with-static-libs=netapi.
Michael
(This used to be commit a4c773de0fbd303f633e120e817b4c88fcff2064)
Formerly this was only needed for libwbclient, but now that we start
using more shared libs internally, this is needed more globally
to support linking internal libs dynamically on systemy without winbindd.
Michael
(This used to be commit ec793572187228deda7210dab02882e4e09f1972)
smbd doesn't need $(WBCOMMON_OBJ) anymore,
it works with any libwbclient.so now
and may talk to an older winbindd.
metze
(This used to be commit e3435930a307cff3066fe2047ed8c5c48911f001)
And only link in wb_common.o directly into binaries
which really need it.
Note: It's important that $(WBCOMMON_OBJ) comes before
@LIBWBCLIENT_STATIC@ overwise we may try to
link in wb_common.o twice.
metze
(This used to be commit 135d9dd6d830ce6ae5c7917468763aa9a148d76a)
This call is completely broken. For now, just make sure that we return the exact same
data as before the conversion to pidl.
Guenther
(This used to be commit 243bdaeea7900ab6a65edfda877e8c225ec7b213)
This also establishes a general configure mechanism to control static vs
dynamic linking of internal subsystems built as libraries:
This first simple approach is as follows.
* It applies only to "subsystems" that we build as libraries and for
that linking samba against the libraries (as opposed to linking in
the plain object files) has been configured in Makefile.in.
* If we do build the shared library, then we link dynamically by default.
* We only link statically if we don't build shared or if the library
appears in the new --with-static-libs configure option
(comma-separated list).
Example (currently only one):
--with-static-libs=talloc makes use of libtalloc.a instead
of linking the dynamic variant with -ltalloc.
A possilble way to setup linking against libraries in Makefile.in is this:
For a subsystem, "mylib" say, we build bin/libmylib.a and bin/libmylib.so.
The subsystem usually has a MYLIB_OBJ definition in Makefile.in. Define
LIBMYLIB_STATIC=bin/libmylib.a and and LIBMYLIB_LIBS=-lmylib in configure.in
as controlled by presence of "mylib" in the list given to --with-static-libs
and change uses of $(MYLIB_OBJ) to @LIBMYLIB_STATIC@ in Makefile.in and
add @LIBMYLIB_LIBS@ to the link targets as needed.
In the example of talloc, which is needed everywhere, I have simply
added @LIBTALLOC_LIBS@ to the definition of "LIBS" in Makefile.in.
For other subsystems, one will have to be more careful.
Michael
(This used to be commit 71b990d9d687b517dec3d4eff67b6a3fe417a12a)
