building 4.16 for debian (long)

[Michael Tokarev]

28.03.2022 01:45, Andrew Bartlett wrote:
[..]
> https://gitlab.com/samba-team/samba/-/merge_requests/2461 has some
> improved documentation.

This is *excellent*. Thank you *very* much Andrew! Well done!

I'm happy now! *G*

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

In order to solve this I added samba-cluster-support into the deps
in smbd definition in source3/wscript.  But the dependency forest
itself is not trivial, I don't have time/energy now to dig there
further to understand where the dep should go.  The missing symbol
(messaging_ctdb_connection) is used in source3/smbd/{process,server}.c
so this suggests it should be added to smbd link line as a direct
dep. Or, it seems, to smbd_base deps since this is where the
mentioned sources are actually listed.  Should be easy to do for
someone who is more familiar with the set of modules/subsystems
and the rules of the deps.

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

This is an interesting issue by its own, I hit it once again, it
deserves a separate email.

Thank you Andrew!  We're getting close :)

/mjt