Before we can advise users to use the waf build for a file server build we need to make sure that all configure checks are ported correctly to waf. We could have a build farm tree that runs both configure versions and compares the resulting config.h. At least one thing that's missing are the quota checks. They're very very tricky and we need to carefully test them.
The diff of the config.h results is now in on the samba_3_master build farm pages. Look for 'Comparing config.h from autoconf and waf' in (for example) https://build.samba.org/build.cgi/build/85725b9ff0371f8e0571b365e4b728fba2040d09 To interpret the differences, here is an the above example, and the context #define HAVE_ATTR_LISTF 1 This is due to avoiding linking -lattr (XFS/IRIX compat wrapper) on linux systems with native xattrs. I can't add it to the exceptions file because on a real IRIX system it would matter. #define HAVE_LINUX_XFS_QUOTAS 1 #define HAVE_NFS_QUOTAS 1 The quota support mentioned above #define HAVE_NO_AIO 1 WAF builds with AIO by default, autoconf does not #define HAVE_QUOTACTL_LINUX 1 #define HAVE_SYS_QUOTAS 1 #define HAVE_XFS_QUOTAS 1 #define WITH_QUOTAS 1 The quota support again.
Status: - quota checks are done - (missing) dmapi checks are tracked in bug 9178 - FreeBSD is missing '#define BSD_STYLE_STATVFS 1' - A number of hosts are missing #define HAVE_ATTRIBUTE_COLD 1 (but this is less important) AIX doesn't build due to _() being undefined and has these different defines: #define BROKEN_STRNDUP 1 #define BROKEN_STRNLEN 1 #define DEFAULT_DOS_CHARSET "ASCII" #define DEFAULT_UNIX_CHARSET "UTF8" #define HAVE_BROKEN_READLINK 1 #define HAVE_DECL_ASPRINTF 0 #define HAVE_DECL_RL_EVENT_HOOK 0 #define HAVE_DECL_VASPRINTF 0 #define HAVE_INT32_FROM_RPC_RPC_H 1 #define HAVE_STRUCT_SECMETHOD_TABLE_METHOD_ATTRLIST 1 #define HAVE_STRUCT_SECMETHOD_TABLE_METHOD_VERSION 1 #define HAVE_SYS_DMAPI_H 1 #define HAVE_VA_COPY 1 #define USE_DMAPI 1 Tru64 doesn't build due to a posix ACL prototype mixup Solaris doesn't build due to a posix ACL prototype mixup These should be easy to fix for someone with real-time access to those hosts.
*** Bug 8649 has been marked as a duplicate of this bug. ***
The dirfd checks are not identical and may fail on platforms where dirfd is a macro.
Just a note, I've reviewed the build farm and the status here is unchanged. I'm re-assigning this to obnox, who can assign this to someone with real-time access to these host OSs.
physical access really does not matter. Every team member has ssh login to the hosts.
Well, I'm not aware of the login details for SerNETs build farm machines, and I'm while I know waf well, I'm hesitant to get started on AIX.
I checked the HAVE_ATTR_LISTF issue. In the waf build we assume, that we have a the full usable set of native xattr funktions if getxattr() is available. In this case we do not check for attr_listf. If there is no native xattr support, attr_listf would we available (if the system provides). In the autoconf build we check for all these functions in any case, so HAVE_ATTR_LISTF is defined, if it's available. In the libreplace-xattr code we check first for the available native xattr function and then, if native support not available, for an alternative way. As far as I see, it is in both cases not critical. Maybe we could save some unnecessary checks and the -lattr in the autoconf build or check additionally for alternative xattr functions in the waf build, risk the -lattr (but support a broken glibc ;-) ) I think we should add the check for native xattr support to the autoconf build and save checks for alternative functions. Are there differing opinions?
Yes, that is (In reply to comment #8) > I checked the HAVE_ATTR_LISTF issue. > > In the waf build we assume, that we have a the full usable set of native xattr > funktions if getxattr() is available. In this case we do not check for > attr_listf. If there is no native xattr support, attr_listf would we available > (if the system provides). > > In the autoconf build we check for all these functions in any case, so > HAVE_ATTR_LISTF is defined, if it's available. > > In the libreplace-xattr code we check first for the available native xattr > function and then, if native support not available, for an alternative way. > > As far as I see, it is in both cases not critical. Maybe we could save some > unnecessary checks and the -lattr in the autoconf build or check additionally > for alternative xattr functions in the waf build, risk the -lattr (but support > a broken glibc ;-) ) > > I think we should add the check for native xattr support to the autoconf build > and save checks for alternative functions. > > Are there differing opinions? Yes, the autoconf build should stop once it finds the native functions, and avoid a link to -lattr. I'm not worried about this difference, and I don't think this library is even very common any more. The autoconf build already uses the native functions - indeed on most linux platforms -lattr isn't even installed.
On the three build farm hosts that currently complete an autoconf build, here are the results: Ubuntu (sn-devel) - Only the HAVE_ATTR_LISTF we discussed already (harmless) OpenBSD: #define HAVE_ATTRIBUTE_COLD 1 - Not very important, but should be fixed (common with FreeBSD) #define HAVE_COPY_AUTHENTICATOR 1 - kerberos related, expected #define HAVE_DECL_RL_EVENT_HOOK 0 - just a different way of expressing that we don't have this #define HAVE_HISTORY_LIST 1 #define HAVE_LIBREADLINE 1 #define HAVE_NEW_LIBREADLINE 1 - Need to investigate readline detection #define HAVE_LIBASN1 1 #define HAVE_LIBCOM_ERR 1 #define HAVE_LIBGSSAPI 1 - All kerberos #define HAVE_MD5_H 1 - Need to investigate (common with FreeBSD) #define HAVE_PRCTL 1 - Need to investigate (common with FreeBSD) #define VALUEOF_SIGRTMAX #define VALUEOF_SIGRTMIN - Need to investigate (common with FreeBSD) FreeBSD 10: #define BSD_STYLE_STATVFS 1 - Need to investigate #define HAVE_ATTRIBUTE_COLD 1 - As above #define HAVE_DECL_RL_EVENT_HOOK 0 - As above #define HAVE_LIBMD5 1 - Need to investigate (common with OpenBSD) #define HAVE_MD5_H 1 - Need to investigate (common with OpenBSD) #define HAVE_PRCTL 1 - Need to investigate (common with OpenBSD) #define VALUEOF__NSIG - Need to investigate The two that seem really important there are BSD_STYLE_STATVFS and HAVE_PRCTL.
(In reply to comment #10) > On the three build farm hosts that currently complete an autoconf build, here > are the results: > > Ubuntu (sn-devel) > - Only the HAVE_ATTR_LISTF we discussed already (harmless) > > OpenBSD: > #define HAVE_PRCTL 1 > - Need to investigate (common with FreeBSD) This seems to be a red herring, and not a waf bug. This is only used when other flags are available (which are not on *BSD), and while it compiles on FreeBSD in configure, it doesn't try and link (which waf does) which is why there is a difference here.
(In reply to comment #10) > > #define VALUEOF_SIGRTMAX > #define VALUEOF_SIGRTMIN > > #define VALUEOF__NSIG > - Need to investigate These are just artefacts of the autoconf build system, and are not used in the code. The waf build doesn't need to put these in config.h to do the maths to produce TEVENT_NUM_SIGNALS.
(In reply to comment #10) > > #define HAVE_ATTRIBUTE_COLD 1 > - Not very important, but should be fixed (common with FreeBSD) This is caused by the waf test requiring no errors, and the build giving: warning: 'cold' attribute directive ignored I think this means the test in the autoconf build is incorrect.
Patches for statvfs and md5 detection are on the list. Once these are reviewed and into master, then all the differences on FreeBSD will either be removed or explained.
(In reply to comment #13) > (In reply to comment #10) > > > > #define HAVE_ATTRIBUTE_COLD 1 > > - Not very important, but should be fixed (common with FreeBSD) > > This is caused by the waf test requiring no errors, and the build giving: > > warning: 'cold' attribute directive ignored > > I think this means the test in the autoconf build is incorrect. Yes, known problem. libccan.m4 contains this comment: # All the configuration checks. Regrettably, the __attribute__ checks will # give false positives on old GCCs, since they just cause warnings. But that's # fairly harmless. Cheers! Rusty.
I'm calling this fixed. There is nothing more that can really be done here. The only remaining potential difference left before autoconf was removed was configure checks to avoid a warning regarding readline on OpenBSD. A new bug can be opened for that if anybody ever notices.
Thanks for working on this, Andrew!