> case you
> know what is wrong off the top of your head.
>
> I'll be away next week so I won't be able to easily test things on my
> amd64 box.
> I will be able to look at code, if you can point me to the right
> places. (Should I be
> looking at 6.4.2/6.6 d
-function-cast -I../includes -I. -
Iparallel -DCOMPILING_RTS -fomit-frame-pointer -optc-g -DNOSMP -I/usr/
local/include -fno-strict-aliasing -O2 -DDEBUG -DNOSMP -I /usr/local/
include -I . -I /tmp/ghc/includes -fwrapv
Using built-in specs.
Configured with: FreeBSD/amd64 system compiler
Thread model: po
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 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
> bootstr
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 readlin
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
Hi,
I have made some progress in compiling ghc-6.6 unregisterised for
freebsd/amd64,
but I am stuck again.
To get the build on the host (freebsd/i386) to go through, I had to
fix up Linker.c so
that it would build. (Linker.c seems to define at least one utility
function required
by
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 you
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/Makefi
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,
w
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 gener
to install darcs.
>
> I am able to make 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:
-
on the net
for other users wanting to install ghc on freebsd-amd64.
Or is ist better to generate a new registerised .hc-bundle?
Of course, I would like to add the missing two things: object splitting
and ghci interactive before releasing a FreeBSD package.
--
Dipl.-Math. Wilhelm Bernhard Klok
On 25 October 2005 10:01, Wilhelm B. Kloke wrote:
> Simon Marlow <[EMAIL PROTECTED]> schrieb:
>> On 24 October 2005 19:04, Wilhelm B. Kloke wrote:
>>
>> Is it that it does not find the libraries, or does it find the
>> libraries but still gets a bunch of undefined references? If the
>> latter, t
Simon Marlow <[EMAIL PROTECTED]> schrieb:
> On 24 October 2005 19:04, Wilhelm B. Kloke wrote:
>
> Is it that it does not find the libraries, or does it find the libraries
> but still gets a bunch of undefined references? If the latter, then
> there could be an issue with the mangler. Try an 'nm'
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
>> A
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 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
>
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,
don't know how to mangle assembly language for: x86_64-unknown-freebsd
gmake[2]: *** [Apply.o] Fehler 1
gmake[1]: *** [all] Fehler 1
gmake[1]: Leaving directory `/data/home/wb/Haskell/ghc-6.4.1-amd64/ghc'
gmake: *** [build] Fehler 1
I am looking myself how to add this info, but quick help by an
.e. with ./configure
>> --with-ghc=/path/to/bootstrap/ghc/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
>
-
w 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/compiler/ghc-inplace -H16m -
ause I have a working 32bit happy on the system.
>
>>> But ghc-inplace seems to work pretty good now on amd64.
>
> I reached the end of hc-build successfully. Now there is a new
> problem.
> I tried (as root) make install at this point. This fails with error
> messages
;> because
>>> Fake happy is not happy!
>
> You mean on the target system? Can you give more details?
Yes. Sorry for any confusion. The happy error messages was an easy one,
because I have a working 32bit happy on the system.
>> But ghc-inplace seems to work pretty good now on
ch for this, I'll update the docs.
> Don't forget to delete Linker.c (for ghci). The stage on teh host
> system
> where the process fails jsut now is
>> $MAKE -C libraries boot all
> because
>> Fake happy is not happy!
You mean on the target system? Can yo
em back whenever that happened.
This is not really sufficient. I use "chflags uchg" to protect these
files. At least you you will be noticed, when the overwrite tries to happen.
> I've been trying to crosscompile for amd64-freebsd from Mac OS X, but
> although I seem to ge
s been overwritten by the host version in your tree.
Those files got overwritten several times for me, too, despite following the
instructions... I ended up watching for them to get overwritten and copying
them back whenever that happened.
I've been trying to crosscompile for amd64-fre
On 12 October 2005 17:34, Wilhelm B. Kloke wrote:
> Simon Marlow <[EMAIL PROTECTED]> schrieb:
>
>> Just doing 'make -k' in ghc/rts should leave all the .hc files
>> behind, because you already have the -keep-hc-files flag in your
>> command line, so GHC won't delete the intermediate .hc files even
Simon Marlow <[EMAIL PROTECTED]> schrieb:
> On 25 September 2005 18:54, Wilhelm B. Kloke wrote:
>
>> bash-2.05b$ (cd ghc/rts; gmake PrimOps.o )
>> ../../ghc/compiler/ghc-inplace -H16m -O -H32m -keep-hc-files -static
>> -I. -#include Prelude.h -#include Rts.h -#include RtsFlags.h
>> -#include RtsUti
On 25 September 2005 18:54, Wilhelm B. Kloke wrote:
> Though I have reported some sort of success on this in the last days,
> I was too early. The ghc-inplace does not work on the target system.
> It compiled because I have been too lax in following the instructions.
> Here is the report, where th
Though I have reported some sort of success on this in the last days,
I was too early. The ghc-inplace does not work on the target system.
It compiled because I have been too lax in following the instructions.
Here is the report, where the crossport fails on the i386host system:
tar czf ghc-6.4.1-
On 22 September 2005 09:49, Simon Marlow wrote:
> On 21 September 2005 21:14, Wilhelm B. Kloke wrote:
>
>> Simon Marlow <[EMAIL PROTECTED]> schrieb:
>>>
>>> Int64# primitive type (it's the same as Int#). You might want to
>>> make sure that ghc/includes/ghcautoconf.h on the host machine is the
On 9/21/05, Wilhelm B. Kloke <[EMAIL PROTECTED]> wrote:
Now I have an unregisterised ghc-inplace. What is the fastest way to testits usability?
Great! Could you put it somewhere on the web?
I have FreeBSD 5.4 here, and you?
Best regards
Tomasz
___
Glasg
it, like
so:
$ cat >hello.hs
main = putStrLn "hello world!"
^D
$ $target/ghc/compiler/ghc-inplace hello.hs
$ ./a.out
hello world!
> The next failure is at Control/Arrow.hc after reconfiguration in
> hc-build:
>
> ==fptools==
utoconf.h had been rebuilt accidentally.
Now I have an unregisterised ghc-inplace. What is the fastest way to test
its usability?
The next failure is at Control/Arrow.hc after reconfiguration in hc-build:
==fptools== gmake all -wr;
in /data/home/wb/Haskell/fptools-amd6
On 20 September 2005 12:24, Wilhelm B. Kloke wrote:
> Deletion of Linker.c and manual build of some AutoApply files make
> the crossbuild work on i386 side. I have a copy of the
> resulting hc-bundle ready. If anybody wants them, send me a mail.
> They don't work on the amd64 s
t;.
> I have further information now. When compiling Linker.c,
> the compilation fails, because there is no MAP_32BIT in FreeBSD-amd64.
> Perhaps just removing this could make it work. I have no idea
> why it is needed on linux-x86_64.
Deletion of Linker.c and manual build of some AutoAp
compiling Linker.c,
> the compilation fails, because there is no MAP_32BIT in FreeBSD-amd64.
> Perhaps just removing this could make it work. I have no idea
> why it is needed on linux-x86_64.
MAP_32BIT is quite important: it tells mmap() to return memory in the
lower 2Gb of the address space,
gt; ipattern of the last steps before, but this destroys genapply.
>
> Don't quite understand this - could you elaborate?
I tried
> (cd ghc/rts ; gmake all)
after (cd ghc/compiler ; gmake stage=2 )
I have further information now. When compiling Linker.c,
the compilation fails, because t
uild those files. Also, I needed to have happy
> and alex
> on the target system, because make boot fails without them (catch 22).
When things are working properly, you don't need Happy or Alex on the
target system. I suspect things have gone wrong earlier.
> A final glitch is that (a
Simon Marlow <[EMAIL PROTECTED]> schrieb:
> On 12 September 2005 12:53, Wilhelm B. Kloke wrote:
>
>> BTW, should I hold my breath for 6.4.1?
>
> You should certainly bootstrap using a 6.4.1 snapshot source tree,
> because there have been plenty of amd64-related fixes.
On 12 September 2005 12:53, Wilhelm B. Kloke wrote:
> Simon Marlow <[EMAIL PROTECTED]> schrieb:
>> On 06 September 2005 15:33, Wilhelm B. Kloke wrote:
>>
>>> I have a FreeBSD box running FreeSD-amd64-6.0. Is there anybody who
>>> can give me a set of .h
Simon Marlow <[EMAIL PROTECTED]> schrieb:
> On 06 September 2005 15:33, Wilhelm B. Kloke wrote:
>
>> I have a FreeBSD box running FreeSD-amd64-6.0. Is there anybody who
>> can give me a set of .hc files (probably from linux x86_64) to build
>> GHC? I tried to follow
On 06 September 2005 15:33, Wilhelm B. Kloke wrote:
> I have a FreeBSD box running FreeSD-amd64-6.0. Is there anybody who
> can give me a set of .hc files (probably from linux x86_64) to build
> GHC? I tried to follow the instructions to crossbuild from
> FreeBSD-i386,
> but my
I have a FreeBSD box running FreeSD-amd64-6.0. Is there anybody who
can give me a set of .hc files (probably from linux x86_64) to build GHC?
I tried to follow the instructions to crossbuild from FreeBSD-i386,
but my attempts failed for reasons I don't understand.
--
Dipl.-Math. Wilhelm Ber
John Skaller wrote:
On Tue, 2005-07-05 at 17:08 +0100, Simon Marlow wrote:
Thanks, downloading it now.. will try. What exactly is
a 'registered' build?
An "unregisterised" build generates plain C which is compiled with a C
compiler. The term "registerised" refers to a set of optimi
On Tue, 2005-07-05 at 17:08 +0100, Simon Marlow wrote:
> > Thanks, downloading it now.. will try. What exactly is
> > a 'registered' build?
>
> An "unregisterised" build generates plain C which is compiled with a C
> compiler. The term "registerised" refers to a set of optimisations
> which requ
On 05 July 2005 16:25, John Skaller wrote:
> On Tue, 2005-07-05 at 12:39 +0100, Simon Marlow wrote:
>> On 05 July 2005 10:38, John Skaller wrote:
>>
>>> Can someone comment on the Debian package for Ubuntu Hoary
>>> providing ghc-6.2.2 wit
On Tue, 2005-07-05 at 12:39 +0100, Simon Marlow wrote:
> I hope you're not going to conclude *anything* based on the performance
> of ackermann and tak! :-)
Well .. whatever a 'registered' build is it does this,
the test is ackermann(3,n), the number in [] is the number
of data points, and (min,
On Tue, 2005-07-05 at 12:39 +0100, Simon Marlow wrote:
> http://www.haskell.org/ghc/dist/stable/dist/ghc-6.4.1.20050704-x86_64-un
> known-linux.tar.bz2
>
> This build is registerised, but doesn't have the native code generator.
BTW: I get this:
for i in `(cd share; find . -type f )`; do \
/u
On Tue, 2005-07-05 at 12:39 +0100, Simon Marlow wrote:
> On 05 July 2005 10:38, John Skaller wrote:
>
> > Can someone comment on the Debian package for Ubuntu Hoary
> > providing ghc-6.2.2 with binary for amd64?
>
> You're probably running an unregis
On 05 July 2005 10:38, John Skaller wrote:
> Can someone comment on the Debian package for Ubuntu Hoary
> providing ghc-6.2.2 with binary for amd64?
You're probably running an unregisterised build, which is going to be
generating code at least a factor of 2 sl
Can someone comment on the Debian package for Ubuntu Hoary
providing ghc-6.2.2 with binary for amd64?
I'm asking because I'm unexpectedly getting really bad
performance as you can see here:
http://felix.sourceforge.net/cur
On 13 May 2005 23:11, [EMAIL PROTECTED] wrote:
>> That's a new one on me. Does your 6.2.2 build otherwise work, i.e.
>> can you build & run programs with it?
>
> ghc won't even compile a 'main = putStrLn "hello world"' program:
>
>> # ghc --make Main.hs
>> Chasing modules from: Main.hs
>> Compi
> That's a new one on me. Does your 6.2.2 build otherwise work, i.e. can
> you build & run programs with it?
ghc won't even compile a 'main = putStrLn "hello world"' program:
| # ghc --make Main.hs
| Chasing modules from: Main.hs
| Compiling Main ( Main.hs, Main.o )
| Linking ...
|
/
On 10 May 2005 16:29, [EMAIL PROTECTED] wrote:
> When trying to compile ghc-6.4 from source on my amd64 using a 6.2.2
> binary (obtained via gentoo portage), I get the following error
> message:
>
> #
> make all
> [...]
> /usr/bin/ghc -o ghc-pkg.bin -H16m -O -cp
Hi,
When trying to compile ghc-6.4 from source on my amd64 using a 6.2.2
binary (obtained via gentoo portage), I get the following error message:
#
make all
[...]
/usr/bin/ghc -o ghc-pkg.bin -H16m -O -cpp -Wall -fno-warn-name-shadowing
-fno-warn-unused-matches -i../../lib/compat -Rghc-timing
3
Submitted By: Thomas Pasch (aanno)
Assigned to: Nobody/Anonymous (nobody)
Summary: amd64: adjustor creation not supported
Initial Comment:
Hello,
when trying to use wxhaskell on ghc-6.2.2 on an amd64
(unregistered gentoo build) the following happend:
$ ./a.out
a.out: internal err
3
Submitted By: Thomas Pasch (aanno)
Assigned to: Nobody/Anonymous (nobody)
Summary: amd64: adjustor creation not supported
Initial Comment:
Hello,
when trying to use wxhaskell on ghc-6.2.2 on an amd64
(unregistered gentoo build) the following happend:
$ ./a.out
a.out: internal err
3
Submitted By: Thomas Pasch (aanno)
Assigned to: Nobody/Anonymous (nobody)
Summary: amd64: adjustor creation not supported
Initial Comment:
Hello,
when trying to use wxhaskell on ghc-6.2.2 on an amd64
(unregistered gentoo build) the following happend:
$ ./a.out
a.out: internal err
3
Submitted By: Thomas Pasch (aanno)
Assigned to: Nobody/Anonymous (nobody)
Summary: amd64: adjustor creation not supported
Initial Comment:
Hello,
when trying to use wxhaskell on ghc-6.2.2 on an amd64
(unregistered gentoo build) the following happend:
$ ./a.out
a.out: internal err
sed
Priority: 3
Submitted By: Thomas Pasch (aanno)
Assigned to: Nobody/Anonymous (nobody)
Summary: amd64: adjustor creation not supported
Initial Comment:
Hello,
when trying to use wxhaskell on ghc-6.2.2 on an amd64
(unregistered gentoo build) the following happend:
$ ./a.out
a.out: internal
3
Submitted By: Thomas Pasch (aanno)
Assigned to: Nobody/Anonymous (nobody)
Summary: amd64: adjustor creation not supported
Initial Comment:
Hello,
when trying to use wxhaskell on ghc-6.2.2 on an amd64
(unregistered gentoo build) the following happend:
$ ./a.out
a.out: internal err
Priority: 3
Submitted By: Thomas Pasch (aanno)
Assigned to: Nobody/Anonymous (nobody)
Summary: amd64: adjustor creation not supported
Initial Comment:
Hello,
when trying to use wxhaskell on ghc-6.2.2 on an amd64
(unregistered gentoo build) the following happend:
$ ./a.out
a.out: internal err
3
Submitted By: Thomas Pasch (aanno)
Assigned to: Nobody/Anonymous (nobody)
Summary: amd64: adjustor creation not supported
Initial Comment:
Hello,
when trying to use wxhaskell on ghc-6.2.2 on an amd64
(unregistered gentoo build) the following happend:
$ ./a.out
a.out: internal err
Submitted By: Thomas Pasch (aanno)
Assigned to: Nobody/Anonymous (nobody)
Summary: amd64: adjustor creation not supported
Initial Comment:
Hello,
when trying to use wxhaskell on ghc-6.2.2 on an amd64
(unregistered gentoo build) the following happend:
$ ./a.out
a.out: internal error: adjus
>Priority: 3
Submitted By: Thomas Pasch (aanno)
Assigned to: Nobody/Anonymous (nobody)
Summary: amd64: adjustor creation not supported
Initial Comment:
Hello,
when trying to use wxhaskell on ghc-6.2.2 on an amd64
(unregistered gentoo build) the following happend:
$ ./a.out
a.out: internal
Gabriel Ebner ([EMAIL PROTECTED]) wrote:
> ghc-6.2.1 works fine, but unregisterised. That means it's pretty
> slow, and the code it generates isn't any faster, of course.
Any eta for registered/native port?
>
> Debian packages are available, a gentoo ebuild is in bugzilla, OpenBSD
> ports/pack
On 05 September 2004 22:36, Gabriel Ebner wrote:
> Gour <[EMAIL PROTECTED]> writes:
>
>> Since I plan to upgrade my computer to amd64, I'm interested what is
>> the current status of ghc on amd64 platfrom?
>
> ghc-6.2.1 works fine, but unregisterised. Tha
Gour <[EMAIL PROTECTED]> writes:
> Since I plan to upgrade my computer to amd64, I'm interested what is the
> current status of ghc on amd64 platfrom?
ghc-6.2.1 works fine, but unregisterised. That means it's pretty
slow, and the code it generates isn't any faster,
Since I plan to upgrade my computer to amd64, I'm interested what is the
current status of ghc on amd64 platfrom?
Sincerely,
Gour
--
Gour| [EMAIL PROTECTED]
Registered Linux User | #278493
GPG Public Key | 8C4
make install' :-)
> >
> > For some platforms unregistered builds are even being distributed in the
> > native package format, openbsd/amd64 for one, and Ian Lynagh has a
> > *bunch* of Debian platforms running unregisterised GHC.
>
> If you mean
> ftp://
ome platforms unregistered builds are even being distributed in the
> native package format, openbsd/amd64 for one, and Ian Lynagh has a
> *bunch* of Debian platforms running unregisterised GHC.
If you mean
ftp://debian-amd64.alioth.debian.org/pub/debian-amd64/pure64/pool/main/g/ghc6/ghc6_6.
2004-06-18T13:39:38 Donald Bruce Stewart:
> Yes. Download and build the src, and 'make install' :-)
Thanks --- turns out my problem was that something in my env breaks
the makefile, Simon gave me what I hope is the voodoo to get it to
work.
-Bennett
pgpNBMx3rmHsm.pgp
Description: PGP signature
bet:
> 2004-06-18T01:57:14 Donald Bruce Stewart:
> > That's interesting. GHC unregisterised on amd64/openbsd *does* pass all
> > the testsuite tests.
>
> Which brings us around to the question that opened this thread, is
> there any way to install the unregistered bu
2004-06-18T08:57:27 Simon Marlow:
> Ok, $(ProjectsThatExist) is supposed to be set to all the projects in
> your source tree that can be built, which on a normal GHC build should
> be something like this:
>
> ProjectsThatExist="glafp-utils ghc libraries hslibs"
>
> This value is set right near th
2004-06-18T01:57:14 Donald Bruce Stewart:
> That's interesting. GHC unregisterised on amd64/openbsd *does* pass all
> the testsuite tests.
Which brings us around to the question that opened this thread, is
there any way to install the unregistered build?
Thanks,
-Bennett
pgpxPp
On 17 June 2004 17:30, Peter Robinson wrote:
> On Thursday 17 June 2004 17:38, Simon Marlow wrote:
>> It looks like registerised compilation on x86_64 isn't quite working
>> yet, then. If you're up to debugging this, then I suggest you start
>> from a simpler program - try hello world registerise
On 17 June 2004 13:09, Bennett Todd wrote:
> 2004-06-17T09:04:40 Simon Marlow:
>> Hmmm. Try these please:
>>
>> make show VALUE=ProjectsToBuild
>> make show VALUE=ProjectsThatExist
>> make show VALUE=SUBDIRS
>
> bash-2.05b$ make show VALUE=ProjectsToBuild
> ProjectsToBuild=""
> bash-2.0
MAP_ANONYMOUS, -1, 0) = -1 EINVAL (Invalid argument)
> #log:write(2, "getMBlock: mmap: Invalid argumen"..., 33) = 33
>
> And a third one:
> #mprotect(0, 1048264, PROT_NONE) = -1 ENOMEM (Cannot allocate memory)
> #...
> #munmap(0x2a95c4f000, 131072)= 0
>
On Thursday 17 June 2004 17:38, Simon Marlow wrote:
> It looks like registerised compilation on x86_64 isn't quite working
> yet, then. If you're up to debugging this, then I suggest you start
> from a simpler program - try hello world registerised, and then slightly
> larger programs if that work
On 17 June 2004 16:29, Peter Robinson wrote:
> Well the build finally succeeded but unfortunately I immediately get a
> segfault when running ghc/ghci.
> I've attached the output of
> # strace -o log ./ghc
It looks like registerised compilation on x86_64 isn't quite working
yet, then. If you're
Well the build finally succeeded but unfortunately I immediately get a
segfault when running ghc/ghci.
I've attached the output of
# strace -o log ./ghc
Cheers
Peter
On Thursday 17 June 2004 15:25, Simon Marlow wrote:
> On 17 June 2004 14:08, Peter Robinson wrote:
>
>
>
On 17 June 2004 14:08, Peter Robinson wrote:
>
> ==fptools== make all -wr;
> in /home/thaldyron/var/ghcbuild/ghc-6.2.20040613/libraries/base
>
> rm -f
On Thursday 17 June 2004 15:01, Gerd M wrote:
> Unfortunately I've only got one gcc version installed at the moment and I'm
> not sure if installing another version won't break something... Maybe I
> will give it another try later this week, thanks for your help so far!
> Regards
> Gerd
Since I'm
Simon Marlow wrote:
This one looks like a failure from GCC, not GHC. If possible, you
should send a bug report to the GCC folks or Gentoo as requested.
You could try using a different version of GCC to work around the
problem.
Unfortunately I've only got one gcc version installed at the moment and
2004-06-17T09:04:40 Simon Marlow:
> Hmmm. Try these please:
>
> make show VALUE=ProjectsToBuild
> make show VALUE=ProjectsThatExist
> make show VALUE=SUBDIRS
bash-2.05b$ make show VALUE=ProjectsToBuild
ProjectsToBuild=""
bash-2.05b$ make show VALUE=ProjectsThatExist
ProjectsThatExist="
On 17 June 2004 10:59, Gerd M wrote:
> I managed to create an unregistered build that compiles the hello
> world example.
> # file hello
> hello: ELF 64-bit LSB executable, AMD x86-64, version 1 (SYSV), for
> GNU/Linux 2.6.0, dynamically linked (uses shared libs), not stripped
Great!
> /tmp/ghc7
I managed to create an unregistered build that compiles the hello world
example.
# file hello
hello: ELF 64-bit LSB executable, AMD x86-64, version 1 (SYSV), for
GNU/Linux 2.6.0, dynamically linked (uses shared libs), not stripped
But when I tried to build a registered compiler with it (by using
On 16 June 2004 13:50, Bennett Todd wrote:
> 2004-06-16T10:33:49 Simon Marlow:
>> On 15 June 2004 16:24, Bennett Todd wrote:
>>> 2004-06-15T14:52:53 Simon Marlow:
After hc-build, you should unpack a completely fresh GHC source
tree, somewhere else. Then 'cd' into this tree, and issue th
2004-06-16T13:26:45 Simon Marlow:
> Bennett, who said he had a working unregisterised build.
I'm by no means a Haskell expert, or even a Haskell programmer; but
my unregistered build does do hello.hs successfully.
-Bennett
pgp9V3uOTefQY.pgp
Description: PGP signature
___
On 16 June 2004 13:19, Gerd M wrote:
> Simon Marlow wrote:
>> It looks like HC bootstrapping is enabled in this tree; it shouldn't
>> be. Just use a completely fresh source tree, don't configure with
>> --enable-hc-boot, and don't unpack any HC files into it.
>>
> If I use a fresh source tree wit
2004-06-16T10:33:49 Simon Marlow:
> On 15 June 2004 16:24, Bennett Todd wrote:
> > 2004-06-15T14:52:53 Simon Marlow:
> >> After hc-build, you should unpack a completely fresh GHC source tree,
> >> somewhere else. Then 'cd' into this tree, and issue the
> >> configure/make commands.
> >
> > Alas,
Simon Marlow wrote:
It looks like HC bootstrapping is enabled in this tree; it shouldn't be.
Just use a completely fresh source tree, don't configure with
--enable-hc-boot, and don't unpack any HC files into it.
If I use a fresh source tree without HCs then I need the unregistered build
to compile
On 15 June 2004 16:24, Bennett Todd wrote:
> 2004-06-15T14:52:53 Simon Marlow:
>> After hc-build, you should unpack a completely fresh GHC source tree,
>> somewhere else. Then 'cd' into this tree, and issue the
>> configure/make commands.
>
> Alas, no joy; again, "make" does nothing.
>
> These
On 16 June 2004 11:00, Gerd M wrote:
> Simon Marlow wrote:
>> After hc-build, you should unpack a completely fresh GHC source tree,
>> somewhere else. Then 'cd' into this tree, and issue the
>> configure/make commands.
>
> I tried this and got as far as:
>
---
Simon Marlow wrote:
After hc-build, you should unpack a completely fresh GHC source tree,
somewhere else. Then 'cd' into this tree, and issue the configure/make
commands.
I tried this and got as far as:
==fptools== make all -
2004-06-15T14:52:53 Simon Marlow:
> After hc-build, you should unpack a completely fresh GHC source tree,
> somewhere else. Then 'cd' into this tree, and issue the configure/make
> commands.
Alas, no joy; again, "make" does nothing.
These Makefiles are cleverer than I am, I can't quite figure ou
2004-06-15T14:52:53 Simon Marlow:
> On 15 June 2004 14:18, Bennett Todd wrote:
> > ./distrib/hc-build ...
> > ./configure --with-ghc=`pwd`/ghc/compiler/ghc-inplace
> > make
> >
> > That last make didn't do anything.
>
> After hc-build, you should unpack a completely fresh GHC source tree,
> somew
On 15 June 2004 14:18, Bennett Todd wrote:
> 2004-06-14T16:06:05 Simon Marlow:
>> You probably don't want to install the registerised build; just use
>> it to build a fresh tree:
>>
>> $ ./configure
>> --with-ghc=/unregisterised-build/ghc/compiler/ghc-inplace
>> $ make
>
> Everything was fi
101 - 200 of 224 matches
Mail list logo
