building 4.16 for debian (long)

Andrew Bartlett abartlet at
Sun Mar 27 22:45:48 UTC 2022

On Sun, 2022-03-27 at 10:50 +0300, Michael Tokarev via samba-technical
> Hi!
> I'm trying to build samba 4.16 for debian. This is my first time to
> build samba, and the first time to create debian packages for it, so
> it is a double-interesting thing to do  :)
> So far I come across several issues during the build process, and I
> need some helping hand here. My current prob, it seems, is that I'm
> not yet familiar with the build process.
> First issue which took quite a lot of my attention was the public
> headers of some support libraries (notable tdb and talloc).  There,
> all API symbols are prefixed with _PUBLIC_ marker (which falls into
> a reserved namespace, btw, it should not be used in public headers).

I can't help on this one, I think you are correct that this suggests
the need for post-processing. 

> Second, in debian we build many internal-to-samba libraries as shared
> libraries, - this were supported by samba in the past, it seems. And
> are
> getting errors while linking, because
> hex_encode_talloc()
> symbol is missing since it is in lib/util/util.o which is not
> included
> into the link line of libsmbconf.

We often find that dependency errors, hidden because of implicit build
dependencies, are seen in custom build configurations.   I'm sorry you
are hitting that.

> Am I right that --bundled-libraries= is the list of libraries to
> build
> as shared libs? Where's the complete list of libs which can be listed
> in there?

No, bundled-libraries is the list of libraries (either maintained by
Samba, or distributed by Samba in third_party) that could be found on
the system, but which we should never use the system version for. has some
improved documentation. 

> Right now, our debian/rules (coming with samba-4.13 debian package)
> has
>   --bundled-
> libraries=NONE,pytevent,iniparser,roken,replace,wind,hx509,asn1,\
> heimbase,hcrypto,krb5,gssapi,heimntlm,hdb,kdc,com_err,compile_et,asn1
> _compile
> I'm not sure it is up-to-date for samba 4.16.

This list is wrong.  Most of the values are for things that we either
do not accept system libraries for - bits of Heimdal - or have since
stopped including in their_party.  But invalid values are currently
ignored (MR welcome on that).

I think you with --bundled-libraries=NONE,pytevent (presuming for some
reason the debian package of tevent does not include the python

> Of the same theme, another question is about
>   --with-shared-modules=idmap_rid,idmap_ad,idmap_adex,idmap_hash,\
>    idmap_ldap,idmap_tdb2,vfs_dfs_samba4,auth_samba4,vfs_nfs4acl_xattr
> I guess this list needs to be updated for 4.16.

This is essentially your choice, as to which things you want as .so
modules.  This may or may not help splitting up dependencies. 

> --------------------------------------------------
> Third, when linking smbd, I'm getting this error:
> /usr/bin/ld: source3/smbd/server.c.147.o: in function `notifyd_req':
> ./bin/default/../../source3/smbd/server.c:366: undefined reference to
> `messaging_ctdb_connection'
> apparently source3/lib/messages_ctdb.o is missing somewhere in the
> link
> line. Maybe this is related to usage of the bundled-libs above.

This is probably a missing entry in 'deps=' in whatever subsystem is
using that. 

> --------------------------------------------------
> And finally (for now), right now I'm stuck at another interesting
> tidbit from where I can't move on.  Somehow it fails to compile
> files using gssapi.h, and it fails to build heimdal sources.  I've
> seen this before already, the prob was intermittent, but now it is
> always here.
> First, the includes.  For example, while compiling
> lib/krb5_wrap/gss_samba.c ,
> the include-path includes -Ithird_party/heimdal/lib
> -Ithird_party/heimdal/lib/gssapi .
> gss_samba.c #includes gss_samba.h which includes
> lib/replace/system/gssapi.h,
> which - based on HAVE_GSSAPI_GSSAPI_H, includes
> <gssapi/gssapi.h>.  The first
> include path which has gssapi/gssapi.h is third_party/heimdal/lib, so
> we include
> third_party/heimdal/lib/gssapi/gssapi.h. But this is a simple
> dispatcher
> file, it merely includes <gssapi/gssapi.h>. Which, as we know
> already, is
> third_party/heimdal/lib/gssapi/gssapi.h. So we end up without all the
> gssapi
> definitions altogether. The correct file to include for
> <gssapi/gssapi.h>
> is third_party/heimdal/lib/gssapi/gssapi/gssapi.h (note the double,
> or even
> triple, gssapi in there) - so the _second_ -I path should be used
> from the
> above.  This is quite messy and not really reliable.

Again, like symbols, header include paths are dependent on the 'deps='
of the subsystems.  So a subsystem is missing a dependency.  We have
had reports (to Heimdal, frustratingly) about this, but someone needs
to chase it down. 


The Heimdal issue is 

> What I don't understand is why I managed to _not_ hit this issue on a
> few
> previous attempts to build samba (using the same configure options
> and the
> build environment).  And next, I don't understand how it is supposed
> to
> work to start with..

I'm not sure, but we should be able to fix it up with a correct

> ------
> Overall, I'm quite shocked by the amount of issues I'm seeing and the
> severity of those issues (the visibility(hidden) thing for one took
> me 3 days to figure out with a help of whole binutils community).
> And the problem becomes worse because I don't quite understand how
> this whole build system - waf - actually works. I see the ideas, but
> taking this heimdal issue above as an example - I need some starting
> point for the beginning of the work of solving this...
> Please excuse me it is so long. This is what I'm hitting while trying
> to build it. Maybe I'm doing something wrongly, - again, I don't know
> what/where.
> is
> the debian build instructions, - the important in there is the
> conf_args
> variable starting at line #37.

On that, I would remove as much complexity as possible, and stick as
close to the tested examples in script/ if possible.

I'll reply to your other mails to the Debian Samba packaging list, I
can help on those as well.

Thank you so much for taking this on, and I'm sorry I wasn't around to
assist over the weekend as you fought your way this far.

Andrew Bartlett

Andrew Bartlett (he/him)
Samba Team Member (since 2001)
Samba Team Lead, Catalyst IT

Samba Development and Support, Catalyst IT - Expert Open Source

More information about the samba-technical mailing list