Ludovic Courtès <ludovic.cour...@inria.fr> writes: > My intent was to remove the *run-time* dependency of openmpi on gcc & > co. (as returned by ‘guix gc --references’ or ‘guix size openmpi’.)
OK, I can send that, though there might still be a case for a separate runtime output. >> Looking at the packaging more closely, I think it needs, or should have, >> various changes. --enable-static clobbers dynamically-loaded MCA >> components, which I think is is a non-starter. One question I have is >> why are builtin atomics turned on? They normally aren't, and I don't >> know what the consequences are. > > No idea, you probably know better than me. I'm afraid not. It's a question for whoever enabled it. >> I assume the store is intended to be on a shared filesystem which >> compute nodes don't duplicate, which helps with space, but I don't think >> that should be required. The stateless systems I've set up used a >> separate compute node image which was much smaller than the login node >> one by omitting non-runtime rpms. > > Yeah the store is typically meant to be shared over NFS or similar. On > the topic of setting up Guix on a cluster, you might want to check: > > https://elephly.net/posts/2015-04-17-gnu-guix.html > https://hal.inria.fr/hal-01161771/en I think I've read both of them, and I'd argue with some of what they say -- but I shouldn't here. >>> I suppose you could to: >>> >>> (define openmpi-with-gfortran7 >>> (package >>> (inherit openmpi) >>> (name "openmpi-gfortran7") >>> (inputs `(("gfortran" ,gfortran-7) >>> ,@(alist-delete "gfortran" (package-inputs openmpi)))))) >> >> Right. >> >>> (That said, if the .mod files are compatible among gfortran versions, it >>> probably doesn’t make sense to do this.) >> >> But they're not compatible, which is a real problem > > It shouldn’t be a problem if you do something like shown above, then. It's a general problem that means you have to do something like the above (which presumably makes the closure big again). >> By the way, I don't want to be an HPC bigot, but HPC requirements seem >> to be largely a superset of most others, and applicable in other areas. > > Agreed! And I think Guix also makes it easier to meet some of the HPC > requirements, from what I’ve seen. Yes, but there are clear trades-off, and from what I've seen the promise isn't really realized yet. I hope it will be, with more engineering effort, and thanks for all the effort on it.