Error building GHC 6.12.1 in Tinderbox tracked finally.

Hi everyone, I hope you remember the issue we're facing with GHC 6.12.1 port dying in Tinderbox[1]. I finally tracked it. And following is how I reproduced that error on my box: --8<---------------cut here---------------start------------->8--- chateau.d.if!abbe:ghc-devel % PACKAGES=/tmp/packages make ===> Found saved configuration for ghc-6.12.1 ===> Extracting for ghc-6.12.1 => MD5 Checksum OK for ghc-6.12.1-src.tar.bz2. => SHA256 Checksum OK for ghc-6.12.1-src.tar.bz2. => MD5 Checksum OK for ghc-6.12.1-amd64-ash0-freebsd8-boot.tar.bz2. => SHA256 Checksum OK for ghc-6.12.1-amd64-ash0-freebsd8-boot.tar.bz2. => MD5 Checksum OK for hscolour-1.15.tar.gz. => SHA256 Checksum OK for hscolour-1.15.tar.gz. => MD5 Checksum OK for ghc-paths-0.1.0.6.tar.gz. => SHA256 Checksum OK for ghc-paths-0.1.0.6.tar.gz. => MD5 Checksum OK for alex-2.3.3.tar.gz. => SHA256 Checksum OK for alex-2.3.3.tar.gz. => MD5 Checksum OK for happy-1.18.4.tar.gz. => SHA256 Checksum OK for happy-1.18.4.tar.gz. => MD5 Checksum OK for haddock-2.6.0.tar.gz. => SHA256 Checksum OK for haddock-2.6.0.tar.gz. ===> ghc-6.12.1 depends on file: /usr/local/bin/perl5.10.1 - found ===> Patching for ghc-6.12.1 ===> ghc-6.12.1 depends on file: /usr/local/bin/perl5.10.1 - found ===> Applying FreeBSD patches for ghc-6.12.1 ===> ghc-6.12.1 depends on file: /usr/local/share/xsl/docbook/html - found ===> ghc-6.12.1 depends on file: /usr/local/bin/xsltproc - found ===> ghc-6.12.1 depends on executable: gmake - found ===> ghc-6.12.1 depends on file: /usr/local/bin/perl5.10.1 - found ===> ghc-6.12.1 depends on file: /usr/local/bin/autoconf-2.62 - found ===> ghc-6.12.1 depends on shared library: gmp.10 - found ===> ghc-6.12.1 depends on shared library: iconv.3 - found ===> Configuring for ghc-6.12.1 checking for path to top of build tree... /usr/home/abbe/freebsd-haskell/ports/lang/ghc-devel/work/ghc-6.12.1-boot checking for perl... /usr/bin/perl checking if your perl works in shell scripts... yes checking for a BSD-compatible install... /usr/bin/install -c checking whether ln -s works... yes checking for ar... /usr/bin/ar checking whether /usr/bin/ar is GNU ar... no checking for ar arguments... clqs checking for gcc... gcc checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ISO C89... none needed checking whether ranlib is needed... no checking for sed... /usr/bin/sed checking version of gcc... 4.2.1 checking how to run the C preprocessor... gcc -E checking for extra options to pass gcc when compiling via C... -fwrapv configure: creating ./config.status config.status: creating extra-gcc-opts config.status: creating mk/config.mk config.status: creating mk/install.mk **************************************************** Configuration done, ready to 'make install' (see README and INSTALL files for more info.) **************************************************** gmake -r --no-print-directory -f ghc.mk install BINDIST=YES NO_INCLUDE_DEPS=YES ghc.mk:612: libraries//tmp/packages/ghc.mk: No such file or directory gmake[1]: *** No rule to make target `libraries//tmp/packages/ghc.mk'. Stop. gmake: *** [install] Error 2 *** Error code 2 Stop in /usr/home/abbe/freebsd-haskell/ports/lang/ghc-devel. *** Error code 1 Stop in /usr/home/abbe/freebsd-haskell/ports/lang/ghc-devel. --8<---------------cut here---------------end--------------->8--- I hope this was the only hurdle we'd. Now any ideas how to sanitize the environment ? Using env(1) or any other better way ? References: [1] http://pastie.org/966481 Thanks -- Ashish SHUKLA Sent via Gnus from GNU Emacs

On Tue, May 18, 2010 at 11:10 PM, Ashish SHUKLA
I hope this was the only hurdle we'd. Now any ideas how to sanitize the environment ? Using env(1) or any other better way ?
Yeah, I remember this nice error message :) I think the problem was around an uninitialized variable (describing packages) in the Makefile. I have managed to fix it back in January, but I do not know where I left the solution :P Anyway, if you find something to patch, it would be nice to post the cvs-ghc. I do not know exactly how to setup a Tinderbox-like jail (perhaps you should consult the sources), but GHC 6.12.x and 6.13 builds without any problems in a clean jailed environment for me. It seems Tinderbox is very picky... which is good for us in the long run. I solution would be to use the "enterBuild" feature of Tinderbox (I think I did that in January to hunt down the problem) but it requires root privileges. Cheers, :g

Gabor PALI writes:
On Tue, May 18, 2010 at 11:10 PM, Ashish SHUKLA
wrote: I hope this was the only hurdle we'd. Now any ideas how to sanitize the environment ? Using env(1) or any other better way ?
Yeah, I remember this nice error message :) I think the problem was around an uninitialized variable (describing packages) in the Makefile. I have managed to fix it back in January, but I do not know where I left the solution :P Anyway, if you find something to patch, it would be nice to post the cvs-ghc.
LoL, and WTF, you should have at least posted it on the list. Anyways, I ain't sure if patching the ghc.mk to initialize PACKAGES is the right way to fix error. But anyways, for now I'm going to patch our Makefile to initialize that variable on the command-line.
I do not know exactly how to setup a Tinderbox-like jail (perhaps you should consult the sources), but GHC 6.12.x and 6.13 builds without any problems in a clean jailed environment for me. It seems Tinderbox is very picky... which is good for us in the long run. I solution would be to use the "enterBuild" feature of Tinderbox (I think I did that in January to hunt down the problem) but it requires root privileges.
Yes, I just looked at the differences in the *environment* of tinderbox, and there I noticed that PACKAGES is being initialized with '/tmp/packages'. Anyways, lets hope everything builds fine now. -- Ashish SHUKLA Sent via Gnus from GNU Emacs

On Wed, May 19, 2010 at 5:20 AM, Ashish SHUKLA
LoL, and WTF, you should have at least posted it on the list.
Sorry, master...
Anyways, I ain't sure if patching the ghc.mk to initialize PACKAGES is the right way to fix error. But anyways, for now I'm going to patch our Makefile to initialize that variable on the command-line.
Well, I would patch ghc.mk, then post it to the Haskell fellows, so they can decide whether that is the correct solution or not. They have proved to be very helpful.
Anyways, lets hope everything builds fine now.
Yeah :) Do not give up! :P Cheers, :g

Gabor PALI writes:
On Wed, May 19, 2010 at 5:20 AM, Ashish SHUKLA
wrote: LoL, and WTF, you should have at least posted it on the list.
Sorry, master...
No problems.
Anyways, I ain't sure if patching the ghc.mk to initialize PACKAGES is the right way to fix error. But anyways, for now I'm going to patch our Makefile to initialize that variable on the command-line.
Well, I would patch ghc.mk, then post it to the Haskell fellows, so they can decide whether that is the correct solution or not. They have proved to be very helpful.
Cool, so I'll patch ghc.mk and will post that to list. Accepting or rejecting it is in their hands. Thanks -- Ashish SHUKLA Sent via Gnus from GNU Emacs
participants (2)
-
Gabor PALI
-
wahjava.ml@gmail.com