(cross-com^H^H^Hposting to glasgow-haskell-users@haskell.org)
Well, sorf-of. A few extra unobvious parameters and workarounds
are required in each case, but it's doable, (arguably) simpler
than real cross-compilation and already exhibits problems
that real cross-compilation may in some
On 29/07/2012 07:41, iquiw wrote:
I am trying to build GHC on NetBSD/amd64.
First, I built GHC-6.12.3 by porting from OpenBSD/amd64.
After that, trying to build several versions (6.12.3, 7.0.4, 7.4.2) of
GHC by the stage2 compiler.
Build itself succeeded and compiling by the ghc seems
Hi,
I am trying to build GHC on NetBSD/amd64.
First, I built GHC-6.12.3 by porting from OpenBSD/amd64.
After that, trying to build several versions (6.12.3, 7.0.4, 7.4.2) of
GHC by the stage2 compiler.
Build itself succeeded and compiling by the ghc seems no problem so far.
However, ghci (all
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 and
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/
--with-gcc=/usr/bin/gcc
On Tue, Oct 05, 2010 at 04:25:46PM +0100, 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/
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/
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 and `gmake -dr all_ghc_stage2'
On Oct 5, 2010, at 3:02 PM, 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
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 compiler/main
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
On Thu 08.01 12:22, Simon Marlow wrote:
Markus Barenhoff wrote:
On Mon 15.12 09:26, Simon Marlow wrote:
Yesterday I updated my sources to the current darcs version. Now the build
works
again, but there still seems to exist a problem with memory allocation:
--- snip ---
$ ghci
GHCi,
Markus Barenhoff wrote:
On Mon 15.12 09:26, Simon Marlow wrote:
Hello everyone,
a happy new year first of all.
5.0.2 -package old-time-1.0.0.1 -package process-1.0.1.1 -package
template-haskell-2.3.0.0 -package unix-2.3.1.0 -O -Wall
-fno-warn-name-shadowing -fno-warn-orphans -XCPP
Simon Marlow wrote:
Markus Barenhoff wrote:
On Thu 08.01 12:22, Simon Marlow wrote:
Markus Barenhoff wrote:
On Mon 15.12 09:26, Simon Marlow wrote:
Yesterday I updated my sources to the current darcs version. Now the
build works
again, but there still seems to exist a problem with memory
On Mon 15.12 09:26, Simon Marlow wrote:
Hello everyone,
a happy new year first of all.
5.0.2 -package old-time-1.0.0.1 -package process-1.0.1.1 -package
template-haskell-2.3.0.0 -package unix-2.3.1.0 -O -Wall
-fno-warn-name-shadowing -fno-warn-orphans -XCPP -XMagicHash
-XUnboxedTuples
Markus Barenhoff wrote:
I've updated my source tree today.
But now I've problem while compiling the ghc
Here is the the build output:
[...]
/usr/home/alios/src/haskell/ghc/ghc/ghc/stage1-inplace/ghc
-DGHCI_TABLES_NEXT_TO_CODE -DSTAGE=2 -package-name ghc-6.11.20081211
-hide-all-packages
On Wed 10.12 13:55, Simon Marlow wrote:
Hi!
I checked out and translated the head version of ghc today from darcs.
It compiled fine. When I now try to start the ghci I get the following:
snip
GHCi, version 6.11.20081126: http://www.haskell.org/ghc/ :? for help
ghc: internal
Markus Barenhoff wrote:
On Fri 28.11 09:42, Simon Marlow wrote:
Markus Barenhoff wrote:
On Thu 27.11 09:49, Simon Marlow wrote:
Hi!
I checked out and translated the head version of ghc today from darcs.
It compiled fine. When I now try to start the ghci I get the following:
snip
On Fri 28.11 09:42, Simon Marlow wrote:
Markus Barenhoff wrote:
On Thu 27.11 09:49, Simon Marlow wrote:
Hi!
I checked out and translated the head version of ghc today from darcs.
It compiled fine. When I now try to start the ghci I get the following:
snip
GHCi, version
Markus Barenhoff wrote:
On Thu 27.11 09:49, Simon Marlow wrote:
Brandon S. Allbery KF8NH wrote:
On 2008 Nov 26, at 9:30, Markus Barenhoff wrote:
Because the ports seem not to get updated, I tried to compile ghc 6.10.1
under freebsd 7 on amd64 myself. For compiling I first used the ports ghc
Brandon S. Allbery KF8NH wrote:
On 2008 Nov 26, at 9:30, Markus Barenhoff wrote:
Because the ports seem not to get updated, I tried to compile ghc 6.10.1
under freebsd 7 on amd64 myself. For compiling I first used the ports ghc
The tree's not being updated because 64-bit on freebsd doesn't
On Thu 27.11 09:49, Simon Marlow wrote:
Brandon S. Allbery KF8NH wrote:
On 2008 Nov 26, at 9:30, Markus Barenhoff wrote:
Because the ports seem not to get updated, I tried to compile ghc 6.10.1
under freebsd 7 on amd64 myself. For compiling I first used the ports ghc
The tree's not being
Hi!
Because the ports seem not to get updated, I tried to compile ghc 6.10.1
under freebsd 7 on amd64 myself. For compiling I first used the ports ghc
version (6.8.3) and then, in a second try I used the self build 6.10.1 to
build it again.
I added building of api docs with:
$ echo HADDOCK_DOCS
On 2008 Nov 26, at 9:30, Markus Barenhoff wrote:
Because the ports seem not to get updated, I tried to compile ghc
6.10.1
under freebsd 7 on amd64 myself. For compiling I first used the
ports ghc
The tree's not being updated because 64-bit on freebsd doesn't work
yet, as you found. I
Rahul Kapoor wrote:
Thanks! I think I see the bug. I've just pushed another patch (round the
size up to a page in mmapForLinker() instead of in the caller), if you
could try it out that would be great.
ghci from ghc-6.11.20081120 works without problems on my xen instance!
Nice! Thanks for
Rahul Kapoor wrote:
I've made a speculative fix. If you're able to test it, that would be very
helpful:
http://hackage.haskell.org/trac/ghc/ticket/2063
Cheers,
Simon
I had no luck installing the binary snapshot (libedit problems, which I worked
around by creating a link to the
Attached is the memory map of ghc process running under gdb on a xen instance.
0040-0146 r-xp 08:01 4177923
/home/deploy/ghc-6.11.20081117/ghc/stage2-inplace/libexec/ghc
0166-017e6000 rw-p 0106 08:01 4177923
Rahul Kapoor wrote:
Attached is the memory map of ghc process running under gdb on a xen instance.
Thanks! I think I see the bug. I've just pushed another patch (round the
size up to a page in mmapForLinker() instead of in the caller), if you
could try it out that would be great.
Cheers,
Thanks! I think I see the bug. I've just pushed another patch (round the
size up to a page in mmapForLinker() instead of in the caller), if you
could try it out that would be great.
ghci from ghc-6.11.20081120 works without problems on my xen instance!
Thanks!
I've made a speculative fix. If you're able to test it, that would be very
helpful:
I imagine, I need to download the nightly snapshot and build it.
HEAD or STABLE?
Rahul
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
HEAD
2008/11/18 Rahul Kapoor [EMAIL PROTECTED]:
I've made a speculative fix. If you're able to test it, that would be very
helpful:
I imagine, I need to download the nightly snapshot and build it.
HEAD or STABLE?
Rahul
___
Glasgow-haskell-users
Rahul Kapoor wrote:
I cannot get GHC to work on a fresh ubuntu hardy machine:
On installing using the package manager I get an error when
running ghci:
R_X86_64_32S relocation out of range: - similar to
http://hackage.haskell.org/trac/ghc/ticket/2013, but that bug is
FreeBSD specific.
I
I cannot get GHC to work on a fresh ubuntu hardy machine:
On installing using the package manager I get an error when
running ghci:
R_X86_64_32S relocation out of range: - similar to
http://hackage.haskell.org/trac/ghc/ticket/2013, but that bug is
FreeBSD specific.
I decided to install the
Rahul Kapoor wrote:
I cannot get GHC to work on a fresh ubuntu hardy machine:
On installing using the package manager I get an error when
running ghci:
R_X86_64_32S relocation out of range: - similar to
http://hackage.haskell.org/trac/ghc/ticket/2013, but that bug is
FreeBSD specific.
I
Are you running under Xen by any chance?
Yes I am. This is on a SliceHost instance.
Is there a tentative release date for 6.10.2?
Rahul
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
Rahul Kapoor wrote:
Are you running under Xen by any chance?
Yes I am. This is on a SliceHost instance.
Is there a tentative release date for 6.10.2?
About 3 months after the 6.10.1 release was the tentative plan.
Is anyone with access to a Xen instance able to work on this bug? It would
Is anyone with access to a Xen instance able to work on this bug?
I can setup an login for a GHC developer on my Zen instance, if that
would help.
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
Hi Donn,
On Thu, May 22, 2008 at 09:09:51AM -0700, Donn Cave wrote:
Anyone have an idea what to look for?
This doesn't ring any bells for me. If I were you I'd start by trying to
work out what it's doing, by running in gdb and hitting ^C after a while
to see where it is. Then find the function
I have been trying to get ghc working on the NetBSD AMD64
platform, and there seems to be a little problem with the
integer size. With minInt and maxInt defined as they are
in GHC/Base.lhs, ghc can't compile this file - it cranks
away and just gets bigger until all the memory is gone.
Base.lhs
On Fri, Jan 04, 2008 at 09:54:45PM +0100, Matthias Kilian wrote:
[Note: already shortly discussed with Wilhelm]
On Fri, Nov 23, 2007 at 12:30:06PM +, Wilhelm B. Kloke wrote:
../../compiler/stage1/ghc-inplace -package-name unix-2.2.0.0
-hide-all-packages -i -idist/build/autogen
On Sun, Jan 06, 2008 at 05:20:18PM +, Ian Lynagh wrote:
Prologue junk?: .type s32x_ret, @function
s32x_ret:
pushl %ebp
movl%esp, %ebp
I see nearly the same problem with ghc-6.8.2 on OpenBSD, using the
gcc-3.3.5 included in its base system.
errors on FreeBSD-amd64. This bug is specific for the bootstrap
with crosscompiling i386 - amd64 vi .hc-bundle.
--
Dipl.-Math. Wilhelm Bernhard Kloke
Institut fuer Arbeitsphysiologie an der Universitaet Dortmund
Ardeystrasse 67, D-44139 Dortmund, Tel. 0231-1084-257
PGP: http://vestein.arb-phys.uni
[Note: already shortly discussed with Wilhelm]
On Fri, Nov 23, 2007 at 12:30:06PM +, Wilhelm B. Kloke wrote:
../../compiler/stage1/ghc-inplace -package-name unix-2.2.0.0
-hide-all-packages -i -idist/build/autogen -idist/build -i. -Idist/build
-Iinclude -#include HsUnix.h -#include
Some days ago I announced having success in porting ghc-6.8.1 to
FreeBSD-7.0-amd64. As the compiler seemed to be able to compile itself,
I was confident to make the binary package available to the public. Now
I have found out that the port is rooten in a very weird way.
From the files
Wilhelm B. Kloke wrote:
Simon Marlow [EMAIL PROTECTED] schrieb:
Perhaps you compiled mkDerivedConstants as a 32-bit executable?
Yes. I was not attentive enough.
But now I have got a working compiler on FreeBSD-amd64-7.0. If anybody is
interested, I shall prepare a package of the installed
Simon Marlow [EMAIL PROTECTED] schrieb:
Wilhelm B. Kloke wrote:
However, you might want to wait for 6.8.2 in the next few days, as we fixed
several important bugs.
I have found a couple of small bugs regarding FreeBSD. Changing the
configure process would be helpful.
FreeBSD-amd64
W.B. Kloke wrote:
In my effort to produce a working FreeBSD-amd64 compiler I made some
progress. Now I have a working stage1/ghc-inplace (which is a 32bit
executable producing 64bit code). But the compilation of rts fails in
file Apply.cmm with the following message:
== gmake all -r
Simon Marlow [EMAIL PROTECTED] schrieb:
Perhaps you compiled mkDerivedConstants as a 32-bit executable?
Yes. I was not attentive enough.
But now I have got a working compiler on FreeBSD-amd64-7.0. If anybody is
interested, I shall prepare a package of the installed binaries.
The compiler
In my effort to produce a working FreeBSD-amd64 compiler I made some
progress. Now I have a working stage1/ghc-inplace (which is a 32bit
executable producing 64bit code). But the compilation of rts fails in
file Apply.cmm with the following message:
== gmake all -r;
in /.amd_mnt/vestein/host/usr
As I have got an amd64 machine again, I am returning to my previous
porting effort.
When I try to build to .hc files on i386 system, I
get the following error:
...
gmake[2]: Entering directory `/usr/home/wb/ghc-6.8.1/libraries/unix'
../../compiler/stage1/ghc-inplace -package-name unix-2.2.0.0
On Wed, Nov 14, 2007 at 04:38:28PM -0500, Brian P. O'Hanlon wrote:
Hello, all. I successfully built GHC 6.8.1 on my FreeBSD 7.0_BETA
amd64 machine. I was able to bootstrap it from the GHC 6.6.1 for
FreeBSD 6/amd64 which was posted to this list a while ago (and was
running in FreeBSD 6
Hello, all. I successfully built GHC 6.8.1 on my FreeBSD 7.0_BETA
amd64 machine. I was able to bootstrap it from the GHC 6.6.1 for
FreeBSD 6/amd64 which was posted to this list a while ago (and was
running in FreeBSD 6 compatibility mode), as well as happy 1.15
which I compiled with that same
Hi Gregory,
On Wed, May 30, 2007 at 05:56:31PM -0400, Gregory Wright wrote:
On May 30, 2007, at 4:05 PM, Simon Marlow wrote:
Gregory Wright wrote:
I have put a binary distribution of ghc-6.6.1 for FreeBSD/amd64
at
http://www.haskell.org/ghc/dist/6.6.1/ghc-6.6.1-x86_64-unknown
Gregory Wright wrote:
The x86-64 (or amd64 if you like) Linux port doesn't do relocation of
data references outside 2Gb. It is the subject of this bug:
http://hackage.haskell.org/trac/ghc/ticket/781
the underlying problem is that the relocatable reference is only 32
bits, because we're
Hi,
I have put a binary distribution of ghc-6.6.1 for FreeBSD/amd64
at
http://www.haskell.org/ghc/dist/6.6.1/ghc-6.6.1-x86_64-unknown-
freebsd.tar.bz2
No documentation or ghci. The former might be easily remedied although
using FreeBSD's docbook chain, as suggested in the wiki, fails when
Gregory Wright wrote:
I have put a binary distribution of ghc-6.6.1 for FreeBSD/amd64
at
http://www.haskell.org/ghc/dist/6.6.1/ghc-6.6.1-x86_64-unknown-freebsd.tar.bz2
yay! Ian will supply a link from the download page in due course, I'm sure.
No documentation or ghci. The former might
Hi Simon,
On May 30, 2007, at 4:05 PM, Simon Marlow wrote:
Gregory Wright wrote:
I have put a binary distribution of ghc-6.6.1 for FreeBSD/amd64
at
http://www.haskell.org/ghc/dist/6.6.1/ghc-6.6.1-x86_64-unknown-
freebsd.tar.bz2
yay! Ian will supply a link from the download page in due
Neil Mitchell wrote:
Hi
I'm hoping that by the end of this summer, nhc98 will be able to compile
the whole of ghc. :-) Also, and alternatively, the yhc chaps have
mooted the idea of moving from nhc98's front end to ghc's, which might
eventually give you a fully portable bytecode route to
Claus Reinke wrote:
I'm confused. I thought we copied the configuration from the target
to the host as part of the bootstrapping process, but now I can't see
how this is supposed to happen for HsBaseConfig.h. It looks like
following the instructions in the building guide will result in
Hi
How do you plan to implement unboxed types? AFAIK, implementing unboxed types
requires a typed intermediate language. Maybe you could get away with boxing
all the unboxed types, but then Int would have an extra level of boxing.
Indeed, we intend to box everything. Plus there were
Neil Mitchell wrote:
Hi
How do you plan to implement unboxed types? AFAIK, implementing
unboxed types
requires a typed intermediate language. Maybe you could get away with
boxing
all the unboxed types, but then Int would have an extra level of boxing.
Indeed, we intend to box everything.
I wrote:
So, should I push my patch for building
System.Posix.Types with nhc98 (i.e. without autoconf, with hsc2hs)?
OK, I have pushed a revised patch, which should not alter the behaviour
for ghc at all. I moved the invocation of hsc2hs into the NHC.*
hierarchy, and just re-export that module
Simon Marlow [EMAIL PROTECTED] wrote:
Also after the base
reorg we might find we have no hsc2hs-generated code left in base and
we can disable hsc2hs to prevent this happening again.
Ah. I was about to checkin a replacement for System.Posix.Types (in
base) that uses hsc2hs instead of
Malcolm Wallace wrote:
Simon Marlow [EMAIL PROTECTED] wrote:
Also after the base
reorg we might find we have no hsc2hs-generated code left in base and
we can disable hsc2hs to prevent this happening again.
Ah. I was about to checkin a replacement for System.Posix.Types (in
base) that uses
Simon Marlow [EMAIL PROTECTED] wrote:
I suppose we could add a dependency on another Haskell compiler just to
run hsc2hs, but that's a pain.
I'm hoping that by the end of this summer, nhc98 will be able to compile
the whole of ghc. :-) Also, and alternatively, the yhc chaps have
mooted the
Hi
I'm hoping that by the end of this summer, nhc98 will be able to compile
the whole of ghc. :-) Also, and alternatively, the yhc chaps have
mooted the idea of moving from nhc98's front end to ghc's, which might
eventually give you a fully portable bytecode route to bootstrapping ghc
on new
I'm confused. I thought we copied the configuration from the target to the host
as part of the bootstrapping process, but now I can't see how this is supposed
to happen for HsBaseConfig.h. It looks like following the instructions in the
building guide will result in failure if you try to
Simon Marlow [EMAIL PROTECTED] writes:
Ah. I was about to checkin a replacement for System.Posix.Types (in
base) that uses hsc2hs instead of autoconf.
Anyway, to answer your question, using hsc2hs in System.Posix.Types
will cause problems for bootstrapping GHC, yes, because we can't run
On Thu, Apr 12, 2007 at 04:33:27PM +0100, Simon Marlow wrote:
I'm confused. I thought we copied the configuration from the target to the
host as part of the bootstrapping process, but now I can't see how this is
supposed to happen for HsBaseConfig.h. It looks like following the
On Thu, Apr 12, 2007 at 08:49:03PM +0100, Malcolm Wallace wrote:
Simon Marlow [EMAIL PROTECTED] writes:
Ah. I was about to checkin a replacement for System.Posix.Types (in
base) that uses hsc2hs instead of autoconf.
Anyway, to answer your question, using hsc2hs in System.Posix.Types
Chris Kuklewicz wrote:
Simon Marlow wrote:
Aha. Text/Regex/Posix.hs is generated from Text/Regex/Posix.hsc by
hsc2hs, but this is done on the *host* rather than the *target* when
bootstrapping, and thus generates the wrong results. If you'd run
hsc2hs on the target, then Text/Regex/Posix.hs
Simon Marlow wrote:
Chris Kuklewicz wrote:
Could the solution be to depend on a pure Haskell regex implementation
instead
of on a regex-posix / Posix.hsc and the system regex library?
Yes, as I mentioned, ticket 1160
(http://hackage.haskell.org/trac/ghc/ticket/1160) is for replacing
Just a further note on the FreeBSD/amd64 port. I have the
mangler fixed up now, so the only remaining issue is the linker.
I hope to send patches soon.
Best Wishes,
Greg
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http
Hello Chris,
Wednesday, April 11, 2007, 12:23:35 PM, you wrote:
After I upgrade to 6.6.1 (using OS X on PPC) then I will make new versions of
regex-compat and regex-tdfa. The thing I have to fix is that the current
unstable regex-tdfa depends on the unstable regex-base and I have to make
a
Gregory Wright wrote:
I have ghc-6.6 (darcs version from 20070405) running registerized on
FreeBSD/amd64. The FreeBSD version is 6.2.
The problem with the compiler crash turned out to be simple. In the
FreeBSD header file regex.h, regex_t is defined as
typedef struct {
int re_magic
Simon Marlow wrote:
Aha. Text/Regex/Posix.hs is generated from Text/Regex/Posix.hsc by
hsc2hs, but this is done on the *host* rather than the *target* when
bootstrapping, and thus generates the wrong results. If you'd run
hsc2hs on the target, then Text/Regex/Posix.hs would have been
Hi Olli,
On Apr 10, 2007, at 1:23 PM, Oliver Braun wrote:
Hi Gregory,
* Gregory Wright [EMAIL PROTECTED] [2007-04-09 12:38 -0400]:
I have ghc-6.6 (darcs version from 20070405) running
registerized on
FreeBSD/amd64.
I will certainly provide patches and a binary distribution that
people
On Sun, Apr 08, 2007 at 07:49:24PM -0400, Gregory Wright wrote:
I have ghc-6.6 (darcs version from 20070405) running registerized on
FreeBSD/amd64.
Excellent! Well done, and thanks for persevering!
It would be great if you could let us have a bindist and any necessary
patches.
The fix
Hi Ian,
On Apr 9, 2007, at 12:21 PM, Ian Lynagh wrote:
On Sun, Apr 08, 2007 at 07:49:24PM -0400, Gregory Wright wrote:
I have ghc-6.6 (darcs version from 20070405) running registerized on
FreeBSD/amd64.
Excellent! Well done, and thanks for persevering!
It would be great if you could let
that it seems to
happen
far more frequently on amd64. Perhaps someone has an idea of the top
of their head for this one. I wouldn't be surprised if the fix for
this also
took care of the bug on the less loved linux-ppc platform.
Best Wishes.
Greg
Hi Ian, Simon,
I have ghc-6.6 (darcs version from 20070405) running registerized on
FreeBSD/amd64. The FreeBSD version is 6.2.
The problem with the compiler crash turned out to be simple. In the
FreeBSD header file regex.h, regex_t is defined as
typedef struct {
int re_magic
Hi Ian,
On Apr 1, 2007, at 6:22 PM, Ian Lynagh wrote:
On Sun, Apr 01, 2007 at 06:10:25PM -0400, Gregory Wright wrote:
Ah, remove the #if/#endif around the definition of puts, its
export,
and the GHC.Pack import in libraries/base/GHC/Handle.hs
No such luck. I even copied puts into
Hello Gregory,
Monday, April 2, 2007, 7:57:49 PM, you wrote:
puts :: String - IO ()
puts s = do write_rawBuffer 1 (unsafeCoerce# (packCString# s))
0 (fromIntegral (length s))
return ()
(packCString# come from GHC.Pack)
you may try to call C function
Hi Ian,
On Apr 1, 2007, at 3:57 PM, Ian Lynagh wrote:
Hi Gregory,
Is there a version of print I can use for debugging these
libraries?
Just adding print causes a cycle in module dependencies.
Ah, remove the #if/#endif around the definition of puts, its export,
and the GHC.Pack import
On Sun, Apr 01, 2007 at 06:10:25PM -0400, Gregory Wright wrote:
Ah, remove the #if/#endif around the definition of puts, its export,
and the GHC.Pack import in libraries/base/GHC/Handle.hs
No such luck. I even copied puts into libraries/base/GHC/
ForeignPtr.hs
but I still get I cycle
Hi SImon,
On Mar 29, 2007, at 5:40 AM, Simon Marlow wrote:
Hi Greg,
Good analysis so far. I think you're close to this one.
Thank you for checking over what I've done thus far.
Based on what you said, I looked at Compat.Unicode and there is
indeed a type error in this foreign call:
Hi Ian,
I have made some more progress on understanding the build
failure on FreeBSD/amd64. I could use a check on my understanding
of the problem, though.
The setup: I have an unregisterized ghc-6.4.2 successfully built
on FreeBSD/amd64. It was bootstrapped from .hc files compiled
Ian Lynagh wrote:
I think they should pretty much work with the 6.6 branch, although I'm
also not convinced by the Don't worry if the build falls over in the
RTS, we don't need the RTS yet. comment.
That may well not be true, feel free to replace it with something more accurate.
I haven't
Hi Gregory,
On Thu, Mar 08, 2007 at 11:25:39AM -0500, Gregory Wright wrote:
I fixed up Linker.c by replacing the calls to mmap (which will need
fixing up anyway
on FreeBSD/amd64) with MAP_FAILED and copying the definitions of four
relocation
types for X86_64 from machine/elf.h
Hi Ian,
I have made some progress. Today I got 6.4.2 to build unregisterized on
my FreeBSD/amd64 box. I went back to 6.4.2 because the only actual
report
of success I could find record of was Wilhelm Kloke's. He used 6.4.1.
I made certain I had exactly the same versions of readline
Hi Gregory,
On Tue, Mar 13, 2007 at 05:18:42PM -0400, Gregory Wright wrote:
The 6.4.2 build now runs successfully to the end of the hc-build script.
Ah, good, that'll hopefully make getting 6.6 working less painful.
The interesting thing is that out of the box using the 6.4.2
bootstrap
Hi,
I'm trying to get ghc-6.6 running on my FreeBSD/amd64 box. It seems as
if the build instructions are stale again.
When I run
$ cd /tmp/ghc-6.6/rts gmake boot gmake
it falls over in the RTS, as noted in the documentation. But at the
next step,
when the libraries are built
Gregory Wright schrieb:
cabal fails to build because it requires HSrts. This aborts the library
build
leaving me with an incomplete set of libraries.
Is there a simple way to tell the build not to make cabal?
I think you can simply delete Cabal from:
SUBDIRS = ...
of libraries/Makefile
Hi Christian,
On Mar 2, 2007, at 11:40 AM, Christian Maeder wrote:
Gregory Wright schrieb:
cabal fails to build because it requires HSrts. This aborts the
library
build
leaving me with an incomplete set of libraries.
Is there a simple way to tell the build not to make cabal?
I think
On Wed, Oct 26, 2005 at 06:57:50PM +, Wilhelm B. Kloke wrote:
I am able to make the unregisterised .hc-bundle available on the net
for other users wanting to install ghc on freebsd-amd64.
I would be very grateful if you could make it available.
Or is ist better to generate a new
the unregisterised .hc-bundle available on the net
for other users wanting to install ghc on freebsd-amd64.
Or is ist better to generate a new registerised .hc-bundle?
A binary distribution would be best. You can build one as follows:
- add BIN_DIST=1 to mk/build.mk
- make clean; make
- make
On 24 October 2005 19:04, Wilhelm B. Kloke wrote:
Wilhelm B. Kloke [EMAIL PROTECTED] schrieb:
Simon Marlow [EMAIL PROTECTED] schrieb:
Are you building GHC in a fresh tree now? I'd recommend doing that.
Now I am using a *really* fresh tree. Formerly the compilation of
Apply.cmm did not
On 19 October 2005 20:41, Wilhelm B. Kloke wrote:
Simon Marlow [EMAIL PROTECTED] schrieb:
Are you building GHC in a fresh tree now? I'd recommend doing that.
Now I am using a *really* fresh tree. Formerly the compilation of
Apply.cmm did not render an instructive error message, just
On 20 October 2005 10:35, Simon Marlow wrote:
On 19 October 2005 20:41, Wilhelm B. Kloke wrote:
Simon Marlow [EMAIL PROTECTED] schrieb:
Are you building GHC in a fresh tree now? I'd recommend doing that.
Now I am using a *really* fresh tree. Formerly the compilation of
Apply.cmm did
/compiler/ghc-inplace.
Now I am getting the following really strange error message:
==fptools== gmake all -wr;
in /data/home/wb/Haskell/fptools-amd64/ghc-6.4.1/ghc/compiler
/data/home/wb/Haskell/fptools-amd64/ghc-6.4.1/ghc
1 - 100 of 184 matches
Mail list logo
