Curious issue with -b output when building Samba master branch

Andrew Bartlett abartlet at samba.org
Mon Feb 9 13:42:44 MST 2015


On Mon, 2015-02-09 at 12:39 -0800, Richard Sharpe wrote:
> On Sat, Feb 7, 2015 at 11:07 AM, Andrew Bartlett <abartlet at samba.org> wrote:
> > On Wed, 2015-02-04 at 15:47 -0800, Richard Sharpe wrote:
> >> On Wed, Feb 4, 2015 at 1:40 PM, Richard Sharpe
> >> <realrichardsharpe at gmail.com> wrote:
> >> > Hi,
> >> >
> >> > when I run my own configure.xxx script that passes essentially what
> >> > RedHat passes to configure on a Samba 4.1.x build, I see the following
> >> > in the configure log,
> >> >
> >> > Dynconfig[SOCKET_DIR]:
> >> >            : '/var/run'
> >> > Dynconfig[MODULESDIR]:
> >> >            : '/usr/lib64/samba'
> >> > Dynconfig[WINBINDD_PRIVILEGED_SOCKET_DIR]:
> >> >            : '/var/lib/samba/winbindd_privileged'
> >> >
> >> > but MODULESDIR is different when I run smbd -b:
> >> >
> >> >    LMHOSTSFILE: /etc/samba/lmhosts
> >> >    LIBDIR: /usr/lib
> >> >    MODULESDIR: /home/rsharpe/somedir/samba/bin/modules
> >> >    SHLIBEXT: so
> >> >    LOCKDIR: /var/lib/samba
> >> >
> >> > Why is this? How can I force the binary to have the correct thing
> >> > because I want to be able to copy these binaries to the correct place
> >> > on a remote node and have things work correctly.
> >>
> >> OK, I think I have found the source of this disturbing behavior. In
> >> dynconfig/wscript I see this little snippet of code:
> >>
> >> def get_override(bld):
> >>     override = { 'MODULESDIR'    : 'bin/modules',
> >>                  'PYTHONDIR'     : 'bin/python',
> >>                  'PYTHONARCHDIR' : 'bin/python',
> >>                  'BINDIR'        : 'bin',
> >>                  'SBINDIR'       : 'bin',
> >>                  'CODEPAGEDIR'   : 'codepages',
> >>                  'SCRIPTSBINDIR' : 'source4/scripting/bin',
> >>                  'SETUPDIR'      : 'source4/setup'
> >>                  }
> >>     return override
> >>
> >> def dynconfig_cflags(bld, list=None):
> >>     '''work out the extra CFLAGS for dynconfig.c'''
> >>     cflags = []
> >>     for varname in dynconfig.keys():
> >>         if list and not varname in list:
> >>             continue
> >>         value = bld.env[varname]
> >>         if not Options.is_install:
> >>             override = get_override(bld)
> >>             if varname in override:
> >>                 value = os.path.join(bld.env.srcdir, override[varname])
> >>         cflags.append('-D%s="%s"' % (varname, value))
> >>     return cflags
> >>
> >> Which would seem to be overriding a bunch of things if you are not
> >> doing a make install.
> >>
> >> Can anyone explain to me the reason for this?
> >
> > This is so that when we run 'make test', the in-tree binaries are used,
> > so you don't have to be root and run 'make install' first, and so you
> > always test the code you just built.
> >
> >> In the environment I am working in I have a bunch of people who want
> >> to have reasonable turn-around for changes and will want to copy the
> >> just built binary to a set of other machines.
> >
> > Given Samba is no longer has a static smbd, copying the
> > just-built-binary is going to give much pain - almost none of the file
> > server is in smbd for example (look how tiny that is these days).
> >
> >> Having to go through an rpmbuild or a make install just to get one
> >> changed binary is an enormous pain.
> >
> > Picking the wrong changed binary is also going to be an even more
> > enormous pain.
> >
> >> Is there some other way rather than hacking out that piece of code?
> >
> > They should do a make install, using DESTDIR=/tmp/my-prefix trick that
> > our packages use to avoid needing to install as root.  That way an rsync
> > of the whole install tree (which is what I would suggest you really
> > want) will be possible.
> 
> Can you be more specific about the trick?
> 

The standard pattern (which we support) is:

DESTDIR=/tmp/xxx make install



-- 
Andrew Bartlett
http://samba.org/~abartlet/
Authentication Developer, Samba Team  http://samba.org
Samba Developer, Catalyst IT          http://catalyst.net.nz/services/samba






More information about the samba-technical mailing list