I can't get quota support to build on samba 4+ using Mac OS X 10.6.8. samba 3.6.8 compiled correctly, and samba 4.0.0 compiles on OS X 10.7+. I can build --without-quotas.
The same error occurs on both 4.0.0 and 4.0.3.
From the build log:
lib/sysquotas_4A.c: In function ‘sys_get_vfs_quota’:
lib/sysquotas_4A.c:107: error: ‘struct dqblk’ has no member named ‘dqb_curblocks’
lib/sysquotas_4A.c:124: error: ‘struct dqblk’ has no member named ‘dqb_curblocks’
lib/sysquotas_4A.c:170: error: ‘struct dqblk’ has no member named ‘dqb_curblocks’
The following command failed:
/usr/bin/gcc-4.2 -Os -w -pipe -march=core2 -msse4 -mmacosx-version-min=10.6 -D_IPP_PRIVATE_STRUCTURES -fno-common -D_REENTRANT -D_POSIX_PTHREAD_SEMANTICS -I. -I/tmp/samba-8ul9/samba-4.0.3/source3 -I/tmp/samba-8ul9/samba-4.0.3/source3/../lib/iniparser/src -Iinclude/autoconf -Iautoconf -Iautoconf/source3 -Iinclude -I./include -I. -I. -I./../lib/replace -I./../lib/tevent -I../lib/ccan/.. -I./librpc -I./.. -I./../lib/tdb_compat -I./../lib/talloc -I../lib/tdb/include -I../lib/ntdb -DHAVE_CONFIG_H -I/usr/local/opt/libtool/include -Iinclude/autoconf -Iautoconf -Iautoconf/source3 -Iinclude -I./include -I. -I. -I./../lib/replace -I./../lib/tevent -I../lib/ccan/.. -I./librpc -I./.. -I./../lib/tdb_compat -I./../lib/popt -DLDAP_DEPRECATED -I/tmp/samba-8ul9/samba-4.0.3/source3/lib -I.. -I./../lib/ldb/include -D_SAMBA_BUILD_=3 -D_SAMBA_BUILD_=3 -fPIE -c lib/sysquotas_4A.c -o lib/sysquotas_4A.o
Here are the full build logs: https://gist.github.com/mistydemeo/50d10380f051b36cc603
This might sound harsh, but OS/X documentation says that the fork(2) syscall is not supported anymore. Samba very much depends on a working multi-process support which OS/X does not provide reliably anymore. See the CAVEATS section in
That manpage even does not exist anymore for 10.8, so Apple probably really pulled the plug on fork.
That caveat has been listed in the fork(2) manpage since 10.5 was released in 2007. samba does function on 10.8; fork is certainly available, and the manpage is the same it's been since 10.5.
This bug is not only completely unrelated to fork, but occurs on 10.6.8, not 10.8 - two major releases earlier. Do you no longer support samba on any version of OS X?
The problem is that OS/X does not support fork reliably anymore, so there is no way to make Samba run reliably on OS/X at all. That's probably the main reason why Apple dropped Samba at some point, replacing it with their own implementation. We would like to, but the assumption that we can fork a process reliably is so deeply embedded into smbd that we can not rip this out with any reasonable amount of work. I would highly recommend to use an operating system that does support fork like for example Linux, FreeBSD or Solaris.
Volker, there has been no change in the state of support for fork(2) in OS X. The manpage has not been removed in 10.8, it just ships with the developer tools instead of the base OS, just like the rest of the API manpages. This has been the case since at least 10.5, just as with the caveat.
Also, it is well known that the reason why Apple dropped Samba is that they did not want to ship GPLv3 software.
I don't think you're willfully making things up, but you need to realize that you're woefully misinformed about the entire situation. And this bug has nothing to do with fork anyway.
(In reply to comment #4)
> I don't think you're willfully making things up, but you need to realize that
> you're woefully misinformed about the entire situation. And this bug has
> nothing to do with fork anyway.
No, I'm not trying to willfully make up things. I was just shocked to see that OS/X only supports the calls in forked processes that other OSes allow in signal handlers only. This is a very severe limitation that Samba can not really live with, sorry.
(In reply to comment #5)
> No, I'm not trying to willfully make up things. I was just shocked to see that
> OS/X only supports the calls in forked processes that other OSes allow in
> signal handlers only. This is a very severe limitation that Samba can not
> really live with, sorry.
BTW, I do know that they don't mean what they write, and that mostly stuff will just work fine. I'm just trying to get the expectations right what Samba can and can not really support reliably.
any reason why you don't use the waf build? The waf build being done in the build farm on a os x 10.6 machine recognices the darwin quota system right. The autoconf system should do it too but the waf build is the preferred one. if you find the autoconf test bug that affects the 4B quota system, please come up with a patch.
Björn, no reason I wasn't using the waf buildsystem aside from knowing about it. It looks like the build settings I was using hadn't been altered since 3.6.8. Sorry about that!
I'm getting the same error building 4.0.3 using the waf buildsystem, though:
../source3/lib/sysquotas_4A.c: In function ‘sys_get_vfs_quota’:
../source3/lib/sysquotas_4A.c:107: error: ‘struct dqblk’ has no member named ‘dqb_curblocks’
../source3/lib/sysquotas_4A.c:124: error: ‘struct dqblk’ has no member named ‘dqb_curblocks’
../source3/lib/sysquotas_4A.c:170: error: ‘struct dqblk’ has no member named ‘dqb_curblocks’
(Done using `./configure --prefix=foo --with-configdir=bar; make` in the top level.)
Am I to understand then that OS X is still supported, contrary to what Volker said?
As for the original issue, I've tracked this down - it turns out that having -w in CFLAGS/CXXFLAGS during configure leads to the build failure during the make step. Removing -w from CFLAGS/CXXFLAGS allows samba to build correctly.
I'd like to get the question of whether samba is unsupported on OS X settled, though.
with CFLAG manually set to -w (Inhibit all warning messages) you are asking for trouble actually. A number of configure tests depend on warnings being issued or not. But thanks for tracking that down and reporting here!
To clarify for others who reference this bug, the 'WONTFIX' resolution on this bug refers only to changing the autoconf build system to handle MacOS quotas. The new build systems based on waf and used in Samba 4.1 appears (see comment #7) to handle this correctly, so there isn't a need to go and fix a now removed build system.
more important, this "bug" is caused by manually set CFLAGS, which messes up the build system tests. Without those flags also the old buildsystem was working correct.