I'm getting this failure on math/hs-Agda after the upgrade to ghc 7.8: 75/tmp/ghc917984_0/ghc917984_1132.s: Assembler messages: /tmp/ghc917984_0/ghc917984_1132.s: Fatal error: can't write /tmp/.haddock-917984/Agda/Compiler/Epic/CompileState.o: No space left on device /usr/libexec/binutils224/elf/as: BFD (GNU Binutils) 2.24 assertion fail /build/boomdata/jails/bleeding-edge/usr/src/gnu/usr.bin/binutils224/libbfd/../../../../contrib/binutils-2.24/bfd/elf.c:2536 /usr/libexec/binutils224/elf/as: BFD (GNU Binutils) 2.24 assertion fail /build/boomdata/jails/bleeding-edge/usr/src/gnu/usr.bin/binutils224/libbfd/../../../../contrib/binutils-2.24/bfd/elf.c:2536 /tmp/ghc917984_0/ghc917984_1132.s: Fatal error: can't close /tmp/.haddock-917984/Agda/Compiler/Epic/CompileState.o: No space left on device At least some of Agda is building in tmp which is set to like 200Mb. Can this be changed to use the normal location of ${WRKDIR} ?
over to haskell maintainer group.
That is due to GHC. Please consult the GHC User's Guide on how to change the location where the temporary files are stored [1]. But I guess some support for this could be added to bsd.cabal.mk as well. [1] https://www.haskell.org/ghc/docs/latest/html/users_guide/separate-compilation.html#temp-files
(In reply to Gabor Pali from comment #2) > That is due to GHC. Please consult the GHC User's Guide on how to change > the location where the temporary files are stored [1]. But I guess some > support for this could be added to bsd.cabal.mk as well. I don't get the "you change it on a per-user basis" advice. The port is misbehaving. A port isn't supposed to build in /tmp. If you know a why to globally fix that (assuming it's happening on all GHC ports (!)) then you should should. It's a systematic flaw. Right?
(In reply to John Marino from comment #3) > I don't get the "you change it on a per-user basis" advice. The port is > misbehaving. A port isn't supposed to build in /tmp. If you know a why to > globally fix that (assuming it's happening on all GHC ports (!)) then you > should should. It's a systematic flaw. > > Right? I never said you are wrong. I just gave you the explanation :-) On the other hand, GHC plainly uses some temporary files which are not the object files but intermediate assembly (.s) files. So, practically, GHC builds the port under WRKDIR, but in this case the intermediate files eat up all the space in the temporary directory as a side effect. Because -- as far as I have experienced -- GHC does not like to clean them up. Since I have been using tmpfs(5) for /tmp, it never really occurred to me as a big problem, but you are right of course. If this is a flaw, the flaw is in lang/ghc, not in the hs- ports, though. Regarding the suggested bsd.cabal.mk change, I was referring to the possibility if we implemented overriding the TMPDIR variable then we could also expose it to the user. The cited section of the manual comes up with an ultimate suggestion anyway: "Set the DEFAULT_TMPDIR make variable when building GHC, and never worry about TMPDIR again." lang/ghc already uses the TMPDIR variable for building itself, so this could be extended to all of its consumers. Unfortunately, TMPDIR is going to vary port by port, so DEFAULT_TMPDIR is not an option for us.
Created attachment 146173 [details] Add GHC TMPDIR support for bsd.cabal.mk Please find a patch attached which aims to fix this problem.
(In reply to Gabor Pali from comment #4) > I never said you are wrong. I just gave you the explanation :-) On the > other hand, GHC plainly uses some temporary files which are not the object > files but intermediate assembly (.s) files. So, practically, GHC builds the > port under WRKDIR, but in this case the intermediate files eat up all the > space in the temporary directory as a side effect. Because -- as far as I > have experienced -- GHC does not like to clean them up. Since I have been > using tmpfs(5) for /tmp, it never really occurred to me as a big problem, > but you are right of course. I am also using tmpfs, but I've limited it to 200Mb, partially to uncover bad citizens. > If this is a flaw, the flaw is in lang/ghc, not in the hs- ports, though. > Regarding the suggested bsd.cabal.mk change, I was referring to the > possibility if we implemented overriding the TMPDIR variable then we could > also expose it to the user. Why not just automatically create TMPDIR directory in WRKDIR and don't even give the user the option. > The cited section of the manual comes up with an ultimate suggestion anyway: > "Set the DEFAULT_TMPDIR make variable when building GHC, and never worry > about TMPDIR again." lang/ghc already uses the TMPDIR variable for building > itself, so this could be extended to all of its consumers. Unfortunately, > TMPDIR is going to vary port by port, so DEFAULT_TMPDIR is not an option for > us. But some bsd.* file could set the DEFAULT_TMPDIR relative to WRKDIR right? Is there a technical problem with doing that? /me reads patch Oh, so the patch tries that with TMPDIR but not with DEFAULT_TMPDIR. I'll try the patch. What % of ghc ports will this affect?
(In reply to John Marino from comment #6) > I am also using tmpfs, but I've limited it to 200Mb, partially to uncover > bad citizens. I have enough problems with my own citizens already :-) But thanks for doing this, it is appreciated. > Oh, so the patch tries that with TMPDIR but not with DEFAULT_TMPDIR. Yes, it does. DEFAULT_TMPDIR should be set at the build time of lang/ghc, which means this is going to be hardwired into the compiler basically. Thus it should be a directory which is always the same like /tmp. I do not think DEFAULT_TMPDIR would be relative to WRKDIR, it is not aware of that concept. > What % of ghc ports will this affect? 100 :-) But I would not bump port revisions just because of this.
(In reply to Gabor Pali from comment #7) > Yes, it does. DEFAULT_TMPDIR should be set at the build time of lang/ghc, > which means this is going to be hardwired into the compiler basically. Thus > it should be a directory which is always the same like /tmp. I do not think > DEFAULT_TMPDIR would be relative to WRKDIR, it is not aware of that concept. Okay, based on that I agree DEFAULT_TMPDIR is not the answer. > What % of ghc ports will this affect? > 100 :-) But I would not bump port revisions just because of this. I agree, the build location won't after the product (at least I hope it doesn't!)
I can build Agda with that patch
Are you guys planning to commit the patch?
(In reply to John Marino from comment #10) > Are you guys planning to commit the patch? Sure. I was just working on some other bug fixes in the development repository [1]. Please be patient it is in progress. [1] https://github.com/freebsd-haskell/ports
The patch was committed as part of r366118.