[PATCHES v2] Fix FreeBSD developer build (was: Re: vfs_zfsacl.c: use of undeclared identifier 'ace')
Timur I. Bakeyev
timur at freebsd.org
Mon Nov 20 22:58:53 UTC 2017
That's quite a jumbo patch, possibly splitting it into smaller chunks could
be easier to review :)
I've noticed mentioning of missing HAVE_INTPTR_T on FreeBSD, need to check
that, but meanwhile:
Also, is that patchset against the HEAD? As traditionally we usually first
work with releases, so at least two patches fail to me...
What are the problems with the patches I sent on Linux? I believe similar
approach is used in couple of other places in wscripts.
On Mon, Nov 20, 2017 at 11:00 PM, Uri Simchoni <uri at samba.org> wrote:
> Attached v2, with 16/35 modified so as not to change the params.
> As for the cflag detection tricks - What I tried changed things on the
> Linux/gcc side, so I propose to leave it at that (with the
> ADDITIONAL_CFLAGS workaround) and attack this later.
> On 11/20/2017 03:26 PM, Timur I. Bakeyev via samba-technical wrote:
> > Thanks, Uri, a great work have been done to chaise all this annoying
> > warnings. Hope those will end up in the master tree.
> > In you "[PATCH 16/35] winbind_nss_freebsd: fix a const discard warning"
> > though you change the signature of the function:
> > int
> > __getgroupmembership(const char *uname, gid_t agroup, gid_t *groups,
> > int maxgrp, int *grpcnt)
> > which should be avoided. Need to fix this warning somewhere else.
> > As for the Clang being liberal regarding unknown options we use the
> > following trick:
> > --- buildtools/wafsamba/samba_autoconf.py.orig 2017-07-04 10:05:25 UTC
> > +++ buildtools/wafsamba/samba_autoconf.py
> > @@ -873,7 +873,7 @@ def SAMBA_CHECK_UNDEFINED_SYMBOL_FLAGS(c
> > conf.env.undefined_ldflags = conf.ADD_LDFLAGS('-Wl,-no-
> > testflags=True)
> > if not sys.platform.startswith("openbsd") and
> > conf.env.undefined_ignore_ldflags == :
> > - if conf.CHECK_LDFLAGS(['-undefined', 'dynamic_lookup']):
> > + if conf.CHECK_LDFLAGS(['-undefined', 'dynamic_lookup'] +
> > conf.env.WERROR_CFLAGS):
> > conf.env.undefined_ignore_ldflags = ['-undefined',
> > 'dynamic_lookup']
> > @conf
> > --- lib/replace/wscript.orig 2017-11-02 11:38:36 UTC
> > +++ lib/replace/wscript
> > @@ -81,7 +81,7 @@ def configure(conf):
> > conf.CHECK_HEADERS('sys/atomic.h')
> > conf.CHECK_HEADERS('libgen.h')
> > - if conf.CHECK_CFLAGS('-Wno-format-truncation'):
> > + if conf.CHECK_CFLAGS(['-Wno-format-truncation'] +
> > conf.env.WERROR_CFLAGS):
> > conf.define('HAVE_WNO_FORMAT_TRUNCATION', '1')
> > # Check for process set name support
> > There are a lot of small fixes like this in the FreeBSD Samba port, hope
> > they'll find their way into master as well.
> > With regards,
> > Timur Bakeyev.
> > On Mon, Nov 20, 2017 at 10:10 AM, Uri Simchoni <uri at samba.org> wrote:
> >> On 11/18/2017 01:35 AM, Jeremy Allison via samba-technical wrote:
> >>> Right now, can you type:
> >>> make test
> >>> on a FreeBSD Samba build and have all the tests pass ? I
> >>> would currently doubt it, as many of the tests (like the
> >>> Linux kernel oplock and change notify ones) require Linux
> >>> specific features. Also, some of the tevent tests require
> >>> epoll etc. etc.
> >> As step 0.1, here's a patch set that make Samba build successfully in
> >> developer mode on FreeBSD 11.1-RELEASE (clang 4.0.0). Most of this is
> >> clang-related, so I suppose it has value beyond FreeBSD.
> >> The configuration command I used was:
> >> ADDITIONAL_CFLAGS="-Wno-unknown-warning-option" ./configure.developer
> >> --with-selftest-prefix=./bin/ab --picky-developer --abi-check-disable
> >> --prefix=<my prefix> --with-profiling-data
> >> This is *almost* the Samba autobuild configuration, except:
> >> 1. No ABI checking - It looks like ABI checking depends on some tool
> >> that emits differently-formatted output on FreeBSD
> >> 2. The no-unknonwn-warning-option - I couldn't figure out how to make
> >> clang, during configuration time, identify whether it supports a warning
> >> option or not, *without* supplying other command line options which
> >> could bread another compiler. Upstream waf simply identifies clang, so
> >> one might use that to insert clang-specific behavior.
> >> I'm not sure when (and if...) I'll be able to continue this and see what
> >> are the make test hurdles. If we can hook this to some CI, we can detect
> >> post-push build breakage and fix it before release.
> >> Thanks,
> >> Uri.
> >>> This is doable, but not an easy change to make.
More information about the samba-technical