6.22.02 build error on macOS 10.15 about root

[cjones051073]

OK, have switch the MacPorts build to use ninja. We run a test to see if this shows the issue or not.

[cjones051073]

Update. The issue appears to be some sort of race-like condition in the build configuration, as disabling parallel builds

cmake --build . 2>&1 | tee ../build.log

works just fine.

[Axel-Naumann]

IIRC that's just the build running out of file (or other) handles. You should be able to do parallel builds, but not as parallel, or raise the limits. Could you try?

[cjones051073]

How would I do that ? As far as I am aware I have no limits set.

Also, why would this only affect 6.22.02 ? The very same machine has no problems with any other ROOT versions ?

[Axel-Naumann]

Right, so here's the Internet's cue: http://gnu-make.2324884.n4.nabble.com/EAGAIN-in-read-jobs-pipe-tp1224p1228.html

ulimit -a shows you "Maximum number of open file descriptors"; for me it shows the macOS default of 256 which is notoriously low. Try setting that tom 1024 and see whether it helps?

As for a less parallel build: cmake --build . -j8 might work?

[cjones051073]

Oberon ~/Projects/MacPorts/ports > ulimit -a
-t: cpu time (seconds)              unlimited
-f: file size (blocks)              unlimited
-d: data seg size (kbytes)          unlimited
-s: stack size (kbytes)             8192
-c: core file size (blocks)         0
-v: address space (kbytes)          unlimited
-l: locked-in-memory size (kbytes)  unlimited
-u: processes                       2784
-n: file descriptors                2560

So no, the limit is not 256.

Please also note even if this is related to the problem, changing ulimit is not a practical solution in terms of fixing our automated builds in MacPorts, as I cannot request every user and the build systems make any changes to these settings. Also note we have NEVER run into an issue with any other port, or ROOT version, prior to 6.22.02, so I still maintain even if this is what is happening the core issue is something in the ROOT build system, new in 6.22.02, that is causing this.

[Axel-Naumann]

Thanks. I'm evaluating what might be the cause, and the number of file handles is the only possible cause that I am aware of. If it's not that then I don't know. I remember this issue in the old days with Cygwin's make. Do you see the same issue with ninja? I suppose you use Macport's make?

[cjones051073]

We use the macOS system make /usr/bin/make, not one supply by macports.

[Axel-Naumann]

Thanks. Does Ninja show the same issue?

I'm asking all these questions because in all our builds we have never seen that error.

[cjones051073]

how do I build with ninja ?

[cjones051073]

also note I also do not see the issue with a default configuration. I only see it when I enabled additional features. I presume you also test these in your builds ?

[Axel-Naumann]

cmake -G Ninja. And you need ninja; you can grab it from https://github.com/ninja-build/ninja/releases but I bet MacPorts already has is?

[Axel-Naumann]

Indeed we have a couple of options enabled - but as MacOS proper doesn't offer a lot we also don't build with a lot. But this part -G "CodeBlocks - Unix Makefiles" is probably crucial. How does -G "Unix Makefiles" work?

[cjones051073]

Honestly, I don't know much about that. I just cloned the cmake configuration from the exact command used internally by the MacPorts build, so its added by that. I will have to investigate the reasons for this.

[cjones051073]

ninja based builds work just fine in parallel, so this does seem a good way to sidestep the gnu make build issues, particularly as I now understand ninja is anyway the primary build system used by ROOT devs.

[Axel-Naumann]

OK closing - let me know if there's something we can do on our side.