[Pkg-samba-maint] nearly built 3.2.0~pre2-1
ma at sernet.de
Mon Mar 31 08:12:17 UTC 2008
Steve Langasek wrote:
> On Thu, Mar 27, 2008 at 09:18:36AM +0100, Michael Adam wrote:
> > That is right, this (along with subsequent commits) is the cause of the
> > libtalloc.so.1 problem. (But spontaneously, I don't know about the symbols
> > missing from the vfs modules.)
> The missing symbols are a non-issue; dpkg-shlibdeps warns about these
> because it has no way of knowing what symbols in a plugin are supposed to
> be resolved by the caller, which is the case here.
> > When there is no system talloc library (as is there at least in
> > SID as Jelmer told me), Samba needs to provide its own. There are
> > several choices:
> Can you help with fixing the Samba build rules so that it will actually
> *use* the system talloc library if present? I can't see any way to specify
> this; the only choices I see are to build against the static in-tree lib,
> build against the shared in-tree lib, or link the individual object files
> directly without first making a lib, there's no way to tell the build rules
> to *not* build libtalloc and instead look for it in the system path. (If I
> could get that working, we would use that solution for both libtalloc and
You are right: that is currently not explicitly supported, which
is a deficiency. This needs fixing and proper handling in the
configure mechanism. I want to put this straight but didn't yet
find the time (and necessary input), but chances are I can do
that soon now... I thought that as workaround, one could build
with libtalloc but then not install libtalloc along with samba
but package libtalloc separately or use an installed libtalloc:
linking agains libtalloc works with "-ltalloc" in the makefile.
If only one puts proper deps in the packages, shouldn't this
work for now.
> > * you can decide to only link libtalloc statically by specifying
> > --with-static-libs=libtalloc
> Doesn't actually work, as mentioned in my previous mail.
Oops, really? - I have to re-check that one.
> > * when you link libtalloc dynamically, you need to provide
> > libtalloc.so on systems that don't have it. it is installed
> > into the $LIBDIR folder by plain samba install.
> Actually, no; it has an soname, so what needs to be provided is
> libtalloc.so.0. The samba build rules are buggy in this regard as well,
> since they install each lib under the "*.so" name, and we have to rename it
> in the Debian packaging to get it under the right name for the runtime
I know. That is another legacy I want to eliminate. The problem
is that I am still thinking of a proper way of handling the
version numbers: The "external" subsystems such as talloc and
tdb have their own version numbers within their subtress.
I also plan to come up with a fix for that soon.
Until then, the build mechanism unfortunately has to change that.
I thought this was not so bad, since it is the same with
libsmbclient: also here "libsmbclient.so" is generated adn the
soname is a link to it which is the wrong way around. So also
here the build mechanism has to do some "moving around of files"
and I thought that could be copied.
> > so you can put it in the samba-common package (e.g.) or
> > build samba3's own libtalloc packages. (by cd'ing to
> > source/lib/talloc and building there).
> These would never belong in the samba-common package. We need packaging
> that's future-proofed against ABI changes, so each shared library we ship
> will get its own package.
Michael Adam <ma at sernet.de> <obnox at samba.org>
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 206 bytes
Desc: not available
Url : http://lists.alioth.debian.org/pipermail/pkg-samba-maint/attachments/20080331/349e809f/attachment.pgp
More information about the Pkg-samba-maint