The Samba-Bugzilla – Bug 5716
NetBSD/vax and Resouce Limits
Last modified: 2009-04-06 02:46:23 UTC
I'm trying to build Samba 3.2.1 on NetBSD/vax, version 1.5 or newer and kernel 1.5.2 (custom).
Appearently the compiler (egcs-1.1.2) on this system wastes resources (especially memory) like there's no tomorrow, so the compilation of at least one file failed as follows:
librpc/gen_ndr/ndr_srvsvc.c: In function `ndr_pull_srvsvc_NetSrvInfo':
librpc/gen_ndr/ndr_srvsvc.c:10446: virtual memory exhausted
The problem was resolved by using the ulimit command to set all relevant resources to unlimited (or the maximum value accepted by the system).
It seems appropriate that the configure script should take this into account.
> The problem was resolved by using the ulimit command to set all relevant
> resources to unlimited (or the maximum value accepted by the system).
> It seems appropriate that the configure script should take this into account.
This command is [possibly more than] sufficient to allow completion of the build without hindrance by resource limits:
ulimit -d unlimited && ulimit -s unlimited && ulimit -m unlimited && ulimit -l unlimited
Beware, however, of other bugs that prevent the successful building of samba-3.x on NetBSD/vax 1.5.
make sure you have the very latest gmake, too - otherwise, the error you get looks very similar to what you got here. But all in all, this is more a problem of the build tools, not of Samba. If you have a different build related problem that looks to be Samba's fault please report that as a new bug report with detailed description.
(In reply to comment #2)
> make sure you have the very latest gmake, too - otherwise, the error you get
> looks very similar to what you got here.
Gmake (GNU make) doesn't appear to be present at all on the system in
question. The "make" on NetBSD is sometimes called pmake on Linux, or
at least Slackware.
I don't think it's a "make" problem. I agree it's also not a problem with
the (core) Samba code itself, but rather the build support scripts. It seems
that ./configure might be a good place to test for potential problems of this
nature, since after all, it tests for all sorts of other things. Since
./configure is generated automatically, that process should perhaps generate
some extra code to include in ./configure to detect this issue. Or maybe not, as it may be too rare a problem to be worthwhile.