I'd recommend to search for iconv library in your packaging system. Find
that and install that. Probably it looks like dependency on this is
missing in provided ghc package(s).
Anyway, not osx user here, just general unix user...
Good luck!
Karel
On 10/11/21 11:00 AM, David Duke wrote:
> I
On 06/16/16 12:53 PM, Harendra Kumar wrote:
A thought that came to my mind was whether we should focus on getting
better code out of the llvm backend or the native code generator. LLVM
seems pretty good at the specialized task of code generation and low
level optimization, it is well funded,
Herbert,
what about to extend plan (1) to also include cpphs as a bundled option
with all cpphs advantages except no more fork/exec as the bundle will be
in a form of binary application and not library?
Shall I add it? I would not like to make a mess from your page...
Thanks,
Karel
7.10.1 should IIRC support some kind of DWARF debugging information and
IIRC it was mentioned and decided on ghc devel that the libraries will
ship with some DWARF to easy debugging
-- but takes me lightly on it and verify if this is the case since I may
be completely off and this may apply
BTW, *-testsuite tarball contains bits left from the amd64/linux build
so gmake test is not working due to missing /lib64/ld-linux* library
for ghc-config.
Solaris 11 builds are uploading now...
Karel
On 03/16/15 09:30 PM, Austin Seipp wrote:
We are pleased to announce the third release
IIRC, CFLAGS should be needed only for configure which should detect
your architecture well and generate appropriate settings file. GHC
itself should not use them IIRC. If you need something special, then you
can use mk/build.mk
But I'm not expert for cross-compiling GHC, nor for
On 08/ 2/14 07:04 AM, Michael Jones wrote:
,(target arch,ArchARM {armISA = ARMv7, armISAExt = [VFPv3,NEON], armABI =
HARD})
,(target word size,4)
this looks good, but I hope you got it on clean tree, i.e. without your
configure hack...
Karel
from using the extra
arguments. But I see no reason to run gcc. Seems like that would only be
used at stage0 if at all.
Mike
On Jul 14, 2014, at 10:12 AM, Karel Gardas karel.gar...@centrum.cz
mailto:karel.gar...@centrum.cz wrote:
On 07/14/14 04:58 PM, Michael Jones wrote:
Karel,
Thanks
On 07/12/14 07:27 AM, Michael Jones wrote:
Karel,
I have failed to figure out how to make this happen:
(target arch, ArchARM {armISA = ARMv7, armISAExt = [VFPv3,NEON], armABI =
HARD}”)
This is result of running ./configure on arm/ubuntu12.04 -- so I don't
cross-compile, but rather compile
On 07/14/14 04:58 PM, Michael Jones wrote:
Karel,
Thanks. This helps.
If I understand, you have Linux running on a Panda, and on that Panda
system you have gcc, and you compile GHC on the Panda itself, rather
than build a cross compiler. I can see the advantage of building this
way.
Correct!
I'm not sure if this is already solved, but if you cross-compile to A9,
why do you use ARMv5 platform OS?
(target arch,ArchARM {armISA = ARMv5, armISAExt = [], armABI = HARD})
this looks really strange. armABI HARD, that means FP data in FP regs,
still no VFP in armISAExt and even armISA
On 04/10/14 06:39 PM, Yuras Shumovich wrote:
...and other linker options must come after, like in my case. So what?
Are there any ticket where people complain about the old behavior? I'm
not advocating any specific behavior, I'm just asking why it was
changed.
Hmm, I'm not sure if I'm the
Hi,
Gabor Pali provides his own builder server infrastructure for now when
GHC's HQ is not working. Please have a look at
http://haskell.inf.elte.hu/builders/ and contact Gabor for more details
(he is cced).
Thanks!
Karel
On 04/ 1/14 09:42 AM, harry wrote:
It having been suggested that a
Hi,
I'm curious why not to use what's already written by Ian and others and
which is currently running again? E.g. Janos Gabor Pali was so nice to
start and keep builder server running on
http://haskell.inf.elte.hu/builders/
Just few are there, but others may be added. Just send email to
On 02/ 5/14 03:09 PM, Arie Peterson wrote:
On Monday 03 February 2014 16:35:14 Austin Seipp wrote:
We are pleased to announce the first release candidate for GHC 7.8.1:
[…]
This includes the source tarball and bindists for Windows, Linux, OS
X, FreeBSD, and Solaris, on x86 and x86_64. […]
Has
compatible, one should start the script with:
#!/bin/bash
or (as I've seen elsewhere) better (?)
#!/usr/bin/env bash
Cheers Christian
Am 05.02.2014 23:43, schrieb Karel Gardas:
Hi Christian,
the bindist is compiled on Solaris 11.0 so probably of no use for you on
Solaris 10. Also I needed
On 02/ 6/14 02:36 PM, Joachim Breitner wrote:
Hi,
with RC1 in experimental, the Debian auto-builders have now picked up
building 7.8, and it is failing on armel, hurd-i386, mips and mipsel:
armel
(https://buildd.debian.org/status/fetch.php?pkg=ghcarch=armelver=7.8.20140130-1stamp=1391666879)
On 02/ 5/14 03:09 PM, Arie Peterson wrote:
On Monday 03 February 2014 16:35:14 Austin Seipp wrote:
We are pleased to announce the first release candidate for GHC 7.8.1:
[…]
This includes the source tarball and bindists for Windows, Linux, OS
X, FreeBSD, and Solaris, on x86 and x86_64. […]
Has
On 02/ 5/14 03:56 PM, Joachim Breitner wrote:
Hi,
Am Mittwoch, den 05.02.2014, 15:53 +0100 schrieb Karel Gardas:
Tried, on my ubuntu 12.04.02, but it fails miserably. Modern GHC
requires alex 3.1 and cabal alex fails with (due to QuickCheck template
haskell dependency):
$ cabal install alex
Hi Christian,
the bindist is compiled on Solaris 11.0 so probably of no use for you on
Solaris 10. Also I needed to provide separate tarball of compiled and
installed libgmp.so as the Solaris 11's provided does not satisfy GHC
requirements and GHC refuses to use that...
Karel
On 02/ 5/14
On 02/ 5/14 05:03 PM, Arie Peterson wrote:
On Wednesday 05 February 2014 15:53:41 Karel Gardas wrote:
Tried, on my ubuntu 12.04.02, but it fails miserably. Modern GHC
requires alex 3.1 and cabal alex fails with (due to QuickCheck template
haskell dependency):
[…]
So, well, Catch-22?
You
Hi David,
AArch64 is completely new architecture so it's not about extending
current ARM support but rather write a new beside it -- at least as a
prototype, if there is a lot of synergies you can merge both together
later, but I don't see it having a high chance. Well the situation with
Hello Jeremy,
I'd also like to see GHC compiling for ARM bare metal. Honestly speaking
I've avoided Raspberry Pi, but rather settled on ARMv7. Side note:
BeagleBone is excellent for this as you get all the TI supported tools
together with JTAG debugging just for free from TI (including ARM
On 01/28/13 02:15 AM, Jason Dagit wrote:
I would like to explore making a backend for .NET. I've done a lot of
background reading about previous .NET and JVM attempts for Haskell. It
seems like several folks have made significant progress in the past and,
with the exception of UHC, I can't find
Now, the question is: does QNX use the same ABI as Linux on ARM? See ARM
EABI notes in includes/stg/MachRegs.h
Karel
On 01/24/13 11:59 PM, Stephen Paul Weber wrote:
Somebody claiming to be Nathan Hüsken wrote:
On 01/24/2013 07:26 PM, Stephen Paul Weber wrote:
Somebody claiming to be
On 01/24/13 04:50 PM, Stephen Paul Weber wrote:
Somebody claiming to be Nathan Hüsken wrote:
On 01/24/2013 04:28 PM, Stephen Paul Weber wrote:
Do you think it is specifically the 3.2 that made it work?
Yes. With llvm version 3.1 I was only able to get an unregisterised
build to work.
On 01/24/13 05:51 PM, Stephen Paul Weber wrote:
Doing a registered build with llvm-3.0 I eventually get:
inplace/bin/ghc-stage1 -o utils/hsc2hs/dist-install/build/tmp/hsc2hs
-static -H64m -O0 -fllvm -hide-all-packages -i -iutils/hsc2hs/.
-iutils/hsc2hs/dist-install/build
On 01/24/13 06:51 PM, Stephen Paul Weber wrote:
Somebody claiming to be Stephen Paul Weber wrote:
Somebody claiming to be Nathan Hüsken wrote:
But the symbol not found is __aeabi_memcpy, not memcpy itself ...
I can not find __aeabi_memcpy in the ghc source ...
Maybe it is not linking some
On 01/21/13 04:43 PM, rocon...@theorem.ca wrote:
So the binary-dist has a settings.in file. It is the configure step in
the binary-dist that generates the corrupt settings file.
Perhaps you've forgotten to regenerate bin-dist configure as you did
with build tree configure after applying my
On 01/19/13 11:37 PM, Karel Gardas wrote:
Hi,
I just build 7.6.1 release on my ubuntu 12.04.1 LTS which is hard-float
ABI distro. I used distro provided LLVM 3.0 and configured GHC with:
./configure --with-llc=/usr/bin/llc-3.0 --with-opt=/usr/bin/opt-3.0
Also the testsuite results run
On 01/20/13 07:17 PM, rocon...@theorem.ca wrote:
On Wed, 16 Jan 2013, Karel Gardas wrote:
You should not IMHO. My patch should solve all your issues. :-) The
only issue you may get is that your distro ghc will compile for
soft-float ABI and your compiled GHC will compile to hard-float
On 01/20/13 07:39 PM, Stephen Paul Weber wrote:
Somebody claiming to be Karel Gardas wrote:
I just build 7.6.1 release on my ubuntu 12.04.1 LTS which is
hard-float ABI distro. I used distro provided LLVM 3.0 and configured
GHC with:
Please keep in mind that GHC HEAD is completely different
On 01/20/13 07:50 PM, rocon...@theorem.ca wrote:
Karel, maybe you should try deploying a binary-dist on your panda board?
Sorry? What's binary-dist? And why I should do that? And what
exactly do you mean by deploying? And on what OS? Ubuntu or Raspbian
run in Ubuntu chroot?
What I'm
On 01/20/13 08:27 PM, rocon...@theorem.ca wrote:
Looks like you do have corrupted settings file. Recover it by adding
HARD following armABI = , so result should be:
ArchARM {armISA = ARMv6, armISAExt = [VFPv2], armABI = HARD}
Okay, I patched the settings filed generted by ./configure in the
On 01/21/13 12:49 AM, rocon...@theorem.ca wrote:
On Sun, 20 Jan 2013, Karel Gardas wrote:
Okay, I patched the settings filed generted by ./configure in the
binary-dist and rank make install which completed. However,
pi@raspberrypi /tmp/bindist $ bin/ghc --make Main.hs
[1 of 1] Compiling Main
Hi,
I just build 7.6.1 release on my ubuntu 12.04.1 LTS which is hard-float
ABI distro. I used distro provided LLVM 3.0 and configured GHC with:
./configure --with-llc=/usr/bin/llc-3.0 --with-opt=/usr/bin/opt-3.0
And resulting ghc-stage2 is not only able to complete the build but also
On 01/18/13 05:49 PM, rocon...@theorem.ca wrote:
I don't know much about gdb, but
$ /usr/bin/gdb /tmp/Main
GNU gdb (GDB) 7.4.1-debian
Copyright (C) 2012 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
http://gnu.org/licenses/gpl.html
This is free software: you are free
Guys,
I've installed raspbian into ubuntu chroot on my panda. Now to simulate
what GHC detects on your hardware, could you be so kind and send me
output of:
uname -m
uname -r
uname -s
uname -v
this looks like a needed info for config.guess to detect machine
hardware well.
Also if you
able to merge the patch into your GHC? And rebuild? What was
the result?
Thanks,
Karel
On 01/16/13 08:02 PM, rocon...@theorem.ca wrote:
On Wed, 16 Jan 2013, Karel Gardas wrote:
Guys,
I've installed raspbian into ubuntu chroot on my panda. Now to
simulate what GHC detects on your hardware
On 01/16/13 08:12 PM, rocon...@theorem.ca wrote:
On Wed, 16 Jan 2013, Karel Gardas wrote:
Good! So the patch I already provided is working fine at least w.r.t.
change in configure. I've tested it here on my raspbian chroot on
pandaboard where I've hacked config.guess to print exactly what you
On 15 Jan 2013, at 16:36, rocon...@theorem.ca wrote:
On Mon, 14 Jan 2013, Thijs Alkemade wrote:
Op 14 jan. 2013, om 17:30 heeft rocon...@theorem.ca het volgende
geschreven:
On Thu, 10 Jan 2013, Karel Gardas wrote:
Hmm, are you using Raspbian? I.e. hard-float abi caught my eye in
case
Well, just wild guessing what's needed on RPi, but could you who do have
this board attempt to use attached patch? Don't forget to ./boot as this
change configure. Also testing it on completely clean tree may be wise
idea. Also after configure run please check that you do have VFPv2 in
the
On 01/15/13 08:56 PM, Thijs Alkemade wrote:
Op 15 jan. 2013, om 18:16 heeft Karel Gardaskarel.gar...@centrum.cz het
volgende geschreven:
Well, if you make some board available in DMZ I'm certainly interested to run
at least configure on it from GHC HEAD to see what we need to hack in order
On 01/14/13 06:15 PM, Nathan Hüsken wrote:
In a different thread (Error building ghc on raspberry pi):
On 01/08/2013 12:27 PM, Thijs Alkemade wrote:(...)
I did eventually finish building stage2, but the final executable
segfaulted on start.
I haven't investigated much why that happened, the
On 01/14/13 08:49 PM, Austin Seipp wrote:
Very true. It would be very nice if we could handle this issue
automatically after we figure out the proper way to handle it manually.
I think Karel is right that we may be able to get 90% of the way there
with a short hack in DriverPipeline, with some
On 01/11/13 09:25 PM, rocon...@theorem.ca wrote:
On Thu, 10 Jan 2013, Karel Gardas wrote:
Hmm, are you using Raspbian? I.e. hard-float abi caught my eye in case
of ARMv6/ARM11 chip here...
I'm afraid LLVM is not well guided in your case so could you be so
kind and test if adding -optlc
),
(target has GNU nonexec stack, False),
(target has .ident directive, True),
(target has subsections via symbols, False),
(LLVM llc command, /home/pi/.nix-profile/bin/llc),
(LLVM opt command, /home/pi/.nix-profile/bin/opt)
]
On Wed, 9 Jan 2013, Karel Gardas wrote:
Hi,
find ghc's generated
Hi,
find ghc's generated settings file. What FPU is used there?
Thanks,
Karel
On 01/ 9/13 09:47 PM, rocon...@theorem.ca wrote:
Thanks for the advice; However, it had little effect.
I now have the errors:
===--- building final phase
make -r --no-print-directory -f ghc.mk phase=final all
LD
I've tested this on Ubuntu 12.04 running on ARM (this is using ARM
hard-float ABI) with Ubuntu's provided LLVM 3.0 and it compiles well.
Testsuite summary is attached. We still do have some work to be done on
ARM Linker as majority of failing tests are GHCi related.
Cheers,
Karel
On
On 07/ 9/12 12:06 AM, Austin Seipp wrote:
With 7.4.2, the patches for full ARM linker support were merged and
released. Are there any official builds of GHC for Linux/ARM yet? I
have a PandaBoard ES I'd be willing to contribute for builds and/or
testing/development, but I don't know where to get
Hi,
I've just attached my fix for hard-float ABI build failure on GHC HEAD
to the #5914.
I would be more than glad if you can attempt to merge it to 7.4.x you
are packaging and test if it works for you on both soft and hard float
ABI. Hard seems to be preferred these days at least on
Hi,
sorry for causing this bug. Simon Marlow fixed this in:
commit f0191c559d683b5bac12243c0db3b780b684799e
Author: Simon Marlow marlo...@gmail.com
Date: Wed Aug 10 10:02:55 2011 +0100
default to using @note for saving the linker opts (someone mentioned
that it wasn't working on
Hi,
go for 4 cores if the price is not prohibitive. I'm using Q6600 here and
all cores are quite busy except for the configuration and compilations
which is done by cabal (if only this cabal would be parallel too!). On
ARM/Linux -- 2 cores cortex-a9 (OMAP4430) I've noticed that sometimes
Hello,
recent GHC build times on newer MacBook Pros? thread makes me
wondering if someone already attempted to build GHC on a cluster of
machines using for example PVM GNU make[1] for this or any other tool (
or even custom generated bin/ghc-stageX scripts using rsh?) which is
suitable for
Hello,
I got this here too when I updated GHC tree but forgot to ./sync-all
pull libraries.
Karel
On 08/12/11 12:09 AM, Johan Tibell wrote:
Here's the error I get:
compiler/nativeGen/PprBase.hs:26:8:
Could not find module `Data.Array.Unsafe'
Perhaps you meant
This is laptop so 99% no ECC RAM, however it looks like apple provides
some facility to test memory in single user mode...
http://www.command-tab.com/2008/01/11/how-to-test-ram-under-mac-os-x/
If that's not reliable, then have a look at http://www.memtest.org/ if
this support your hardware
Hello Sergei!
nice to hear from you! In fact I've been dealing with this issue a
little bit and just fixed Adjustor issue myself and then just hour
before your email came I discovered your excellent gentoo patches! Kudos
to zygoloid for his excellent MBlock.h patch! Also you have saved my
there about
this issue to warn potential confused user like me in the future.
Thanks,
Karel
On 01/ 4/11 03:14 PM, Simon Marlow wrote:
On 31/12/2010 19:53, Karel Gardas wrote:
before going to fill some bugreports about broken unregisterised builds
I'd like to be sure I understand the topic and know well
Hello,
[sorry for cross-post, I assume Itanium interest is quite rare these
days so to grab attention of Itanium/Haskell people I send to both
haskell-cafe and ghc list]
I'd like to compile more recent than 6.8.2 GHC on itanium-linux system I
do have access to, but I'm kind of unlucky with
Hello,
I've attempted to update my builder client to the today's source code
and compiled it by GHC 7.0.1 (I've hacked cabal files' versions in order
to do so). When running against GHC builder server with --do-build
option I've got following failure:
Running testing
builder-client-v2:
Duncan and Simon,
thank you very much for dealing with this. After adding -v3 to the
ghc-cabal invocation it reported gcc error on HsBase.h due to missing
math.h file, i.e. system/library/math/header-math package was not
installed yet.
Thanks!
Karel
On 12/16/10 11:16 AM, Duncan Coutts
Hello,
I'm trying to recover my opensolaris builder machine after disk crash,
but after reinstall I'm not able to build any GHC there. I'm trying head
and now also 6.12.3 as a reference (as I'm able to build it on my
workstation with the same OS). The problem I see here is when I invoke
On 10/06/10 00:02, Ian Lynagh wrote:
On Tue, Oct 05, 2010 at 07:21:43PM +0200, Karel Gardas wrote:
On 10/05/10 17:25, Ian Lynagh wrote:
Does the file exist?
If so, make -dr all_ghc_stage2 should show why make thinks it's out of
date, which should point to the problem.
The file exists
On 10/05/10 17:25, Ian Lynagh wrote:
On Sat, Oct 02, 2010 at 08:25:53PM +0200, Karel Gardas wrote:
step which fails with:
gmake -r --no-print-directory -f ghc.mk phase=0 just-makefiles
configure --with-ghc=/export/home/karel/vcs/ghc-target/
--with-ghc-pkg=/export/home/karel/vcs/ghc-target
Hello,
I'm attempting to make unregisterised build of recent GHC head on
Solaris/x86 for Solaris/amd64 platform. I'm closely following:
http://hackage.haskell.org/trac/ghc/wiki/Building/Porting#Cross-compilingtoproduceanunregisterisedGHC
with the only one issue:
mentioned: echo
on OpenBSD/sparc64 - failure at
make all_ghc_stage2' by Benjamin Jansen who seems to get into the same
troubles as me.
Thanks,
Karel
On 10/02/10 20:25, Karel Gardas wrote:
Hello,
I'm attempting to make unregisterised build of recent GHC head on
Solaris/x86 for Solaris/amd64 platform. I'm closely
Hello,
as per GHC wiki (http://hackage.haskell.org/trac/ghc/wiki/BuildBot), its
buildbot should be accessible either on
http://darcs.haskell.org/buildbot or on http://darcs.haskell.org:8010.
The first one return 404 page not found and the second tries to connect
forever. May I ask what's the
Hi,
indeed, I know that and I expect to submit patches later this month.
Thanks,
Karel
Simon Marlow wrote:
Glad you got it going. I notice there are a few test failures, many of
which could be fixed easily, e.g.
--- ./lib/IO/hClose002.stdout.normalisedWed Sep 16 14:08:09 2009
Before going to trace anything I've compared sparky and my setup and it
seems I've had forgotten libiconv library in /usr/local/lib and
LD_LIBRARY_PATH contained this lib. So I've modified LD_LIBRARY_PATH to
exclude /usr/local/lib and now surprisingly base configure fails with:
checking for
/local/include/iconv.h without a
corresponding library.
HTH Christian
Karel Gardas wrote:
Before going to trace anything I've compared sparky and my setup and it
seems I've had forgotten libiconv library in /usr/local/lib and
LD_LIBRARY_PATH contained this lib. So I've modified
Hello,
recently I've found out that my solaris-based GHC buildbot is completely
unusable since it always (when it get to, which means it does not fail
with usual magic number mismatch: old/corrupt interface file?) fails with:
inplace/bin/ghc-stage2 -H32m -O -DNEW_GHC_LAYOUT
-hide-all-packages
Hi Ian,
Ian Lynagh wrote:
The buildbot is putting SplitObjs=NO in mk/build.mk. The above log has
object splitting enabled, which means that there are a lot more .o
files, which is presumably causing some problem with your ar.
If you have both a GNU ar and a Solaris ar then it might be
Christian Maeder wrote:
Testsuite results are bad for ghc-6.10.1.20090314, see
http://hackage.haskell.org/trac/ghc/ticket/3106
Patch for the cygpath not found issue is attached to the ticket. Please
(Windows/Cygwin/Mingw users especially) test it.
Thanks,
Karel
Hello,
interesting but I'm not able to build this on SunOS 5.11/x86. The build
fails with:
(echo dist/build/cbits/PrelIOUtils.p_o dist/build/cbits/WCsubst.p_o
dist/build/cbits/Win32Utils.p_o dist/build/cbits/consUtils.p_o
dist/build/cbits/dirUtils.p_o dist/build/cbits/inputReady.p_o
Don Stewart wrote:
marlowsd:
Ben Lippmeier wrote:
On 12/03/2009, at 12:24 AM, Satnam Singh wrote:
Before making the release I thought it would be an idea to ask people
what other features people would find useful or performance tuning.
So if you have any suggestions please do let us know!
Ian Lynagh wrote:
On Wed, Jan 21, 2009 at 09:36:29PM +0100, Karel Gardas wrote:
cd libffi /usr/sfw/bin/gtar -zxf libffi*.tar.gz
mv libffi/libffi*/ libffi/build
mv: cannot access libffi/libffi*/
gmake[1]: *** [libffi/stamp.ffi.configure] Error 2
gmake: *** [all] Error 2
Aha, can you see
Hello,
I attempt to test new build system on solaris/x86 platform and after
applying patch from here:
http://hackage.haskell.org/trac/ghc/ticket/2951 I've been able to boot
and configure the tree. On the other hand build alone fails with:
checking for unistd.h... yes
checking
Christian Maeder wrote:
Karel Gardas wrote:
Hello,
I need to double check: I'm talking here about new build system. I've
invoked simple `gmake'. Also your builds is fine since editline seems to
find readline header file which seems to satisfy it while this is not in
my case.
Although my
Ian Lynagh wrote:
Can you try the attached patch please?
Your patch solves the problem. Now build fails printing:
mkdir includes/dist-derivedconstants
mkdir includes/dist-derivedconstants/build
/usr/local/ghc-6.8.3/bin/ghc -optc-O -optc-DTABLES_NEXT_TO_CODE
-optc-Iincludes -optc-Irts -H32m
Hello Brian and All,
I'm curious if anyone here attempted building LambdaVM on non-GNU
system. I'm using OpenSolaris/x86 and build fails with:
== Recursively making `depend' for ways: '' ...
PWD = /export/home/karel/vcs/lambdavm/libraries/Cabal
Hello,
short followup, when I also removed Cabal from libraries/Makefile
SUBDIRS, then the build has gone well and I'm able to compile and run
simple Haskell testing programs.
Great work, indeed! I'm looking forward to seeing LambdaVM merged to the
standard GHC.
Thanks!
Karel
Karel Gardas
Hello,
so it seems I'm still not lucky get head compiling well on solaris/x86
bot. This time compilation fails on stage2 at the haddock installation
with following message:
Installing library in
/buildbot/ghc/kgardas/build/utils/haddock/install-inplace/lib/haddock-2.4.2
Installing executable(s)
Matthias Kilian wrote:
On Sun, Jan 11, 2009 at 09:15:51PM +0100, Karel Gardas wrote:
ghc-pkg: /buildbot/ghc/kgardas/build/ghc/inplace-datadir/package.conf:
openFile: does not exist (No such file or directory)
[...]
Do you have any idea what's going wrong this time? Is it a problem of my
bot
Hello,
I've noticed that my GHC head solaris bot is failing with
HsColour needed but wasn't found.
Set HSCOLOUR_SRCS=NO if you don't want to use it
message on stage1 build since Jan 04. Please let me know what I need to
install in order to make head build able again.
Thanks,
Karel
Duncan Coutts wrote:
On Sat, 2009-01-10 at 22:05 +0100, Karel Gardas wrote:
Hello,
I've noticed that my GHC head solaris bot is failing with
HsColour needed but wasn't found.
Set HSCOLOUR_SRCS=NO if you don't want to use it
message on stage1 build since Jan 04. Please let me know what I
Hello,
month or so ago I've noticed that one compiler instance is hanging
around and spending 100% of CPU for nothing after a build of head (I'm
not sure if it also happens on stable) on my Solaris/x86 buildbot. I've
thought that it's my old ghc-6.8.2 from 2008/05/04 and so I've updated
the
Hello,
just verified that this also happens while building stable.
Thanks!
Karel
Karel Gardas wrote:
Hello,
month or so ago I've noticed that one compiler instance is hanging
around and spending 100% of CPU for nothing after a build of head (I'm
not sure if it also happens on stable
Ian Lynagh wrote:
On Wed, Oct 01, 2008 at 02:56:26PM +0200, Karel Gardas wrote:
-bash-3.2$ ps -fU buildbot|grep 4380
buildbot 24480 27081 0 14:50:27 pts/6 0:00 grep 4380
buildbot 4380 641 25 12:38:14 ? 130:33
/buildbot/ghc/kgardas/build/ghc/stage2-inplace/libexec/ghc
-B
Ian Lynagh wrote:
On Wed, Oct 01, 2008 at 08:57:17PM +0200, Karel Gardas wrote:
Does this help?
# pargs 4380
4380: /buildbot/ghc/kgardas/build/ghc/stage2-inplace/libexec/ghc
-B/buildbot/ghc/kgar
argv[0]: /buildbot/ghc/kgardas/build/ghc/stage2-inplace/libexec/ghc
argv[1]: -B/buildbot/ghc
89 matches
Mail list logo
