RE: Building GHC 5.02 on Solaris x86
> Simon Marlow <[EMAIL PROTECTED]> writes:
> >
> > Having just looked at the code, it seems we could recover the
> > platform-independentness in the I/O library with just a
> small amount of
> > wrapperage: most of the offending code is in PrelPosix.hsc,
> with a few
> > #const's scattered around PrelHandle and PrelIO, and none of the
> > affected areas are particularly performance-critical.
> >
> > Also needing wrappers are Time, CPUTime, Directory &
> System. I'd say
> > stop there, though - this is purely to make bootstrapping
> on a new OS
> > easier, so we only need to apply the no-tool restriction to
> libraries
> > needed by the compiler.
> >
>
> Good, let's sort this one out. ghc/compiler/ has its fingers
> deep in the pie
> that is hslibs/, so presumably the restriction applies there also?
I would extend it as far as necessary in order to satisfy the
dependencies of a non-GHCi compiler. That means only converting IOExts
from hslibs, I think. net isn't needed, and neither is Readline. I'll
have to be careful with Posix when I rewrite it.
> I'll happily convert some of these files (once I know what
> wrapper story you have in mind); let me know.
That'd be great.
PrelPosix.fdFileSize is a tricky one, because we can't return an Integer
from C land and we can't return an off_t because the size of that is
OS-dependent. Probably we'll have to return an Int64 even though that's
quite ugly. The other functions in PrelPosix shouldn't present too much
of a problem - I imagine most of PrelPosix can be moved into C land
leaving a small Haskell wrapper.
For the #const's, we'll have to do something like this:
something.c
HsInt get_BUFSIZ(void) { return BUFSIZ; }
PrelHandle.hs:
bUFSIZ = unsafePerformIO get_BUFSIZ
foreign import get_BUFSIZ :: IO Int
Directory needs some #const wrappers, and it can get isDirectory from
the I/O library. System is already wrappered. Time will be ugly, but
then it already is. The CPUTime wrapper is probably going to have to
use Int64.
Cheers,
Simon
___
Glasgow-haskell-bugs mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: Building GHC 5.02 on Solaris x86
Simon Marlow <[EMAIL PROTECTED]> writes: > > Having just looked at the code, it seems we could recover the > platform-independentness in the I/O library with just a small amount of > wrapperage: most of the offending code is in PrelPosix.hsc, with a few > #const's scattered around PrelHandle and PrelIO, and none of the > affected areas are particularly performance-critical. > > Also needing wrappers are Time, CPUTime, Directory & System. I'd say > stop there, though - this is purely to make bootstrapping on a new OS > easier, so we only need to apply the no-tool restriction to libraries > needed by the compiler. > Good, let's sort this one out. ghc/compiler/ has its fingers deep in the pie that is hslibs/, so presumably the restriction applies there also? I'll happily convert some of these files (once I know what wrapper story you have in mind); let me know. --sigbjorn ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
RE: Building GHC 5.02 on Solaris x86
> > So, bringing back the solution of having manually written C wrapper > > functions which platform-independent Haskell source files will call > > out to, would be preferable (in short, avoid the use of hsc2hs *or > > any other extra tool* alltogether). I'm willing to make the > > necessary changes. > > You started by objecting to using a tool that commits your code to a > platform too early. I'm in complete agreement. > > But now you seem to be objecting to using any tools at all. > This seems > excessive. Why not do one of: > > 1) Don't write the tool in Haskell > > 2) Write in Haskell but execute it using a more easily ported Haskell >implementation (i.e., Hugs or NHC) > > 3) Write it in Haskell but include platform independent machine >generated code in the distributions. > > [I lean towards 3 since it avoids the embarressment of 1 and 2] > > (This is all on the assumption that the amount of code we're talking > about is significant enough to care. I have the impression that it is > but could be wrong.) In this case, tool-dependency isn't an issue, because the tool can be generated from the same set of prerequisites that you already require to build the libraries, namely working Haskell & C compilers. It isn't the tool itself that is the problem - it is the baking of OS-dependent information into the Haskell source that is causing problems, because this means that our previously mostly OS-independent intermediate C files are now OS-dependent. The OS-independent nature of the intermediate C is a fairly fragile property - it requires you to avoid using any OS-related #ifdef in the Haskell source, and it means our Haskell-to-C translation must be entirely OS-independent, but the property is highly useful when porting to a new OS. To achieve full platform-independence you also have to not use any architecture-related #ifdefs in the Haskell source (we don't do this: there are quite a few 32-vs-64 bit dependencies in there, which made porting to the Alpha recently *interesting* I understand :-). Cheers, Simon ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
RE: Building GHC 5.02 on Solaris x86
> Yuck. If this isn't enough to convince people that hsc2hs is not > an appropriate tool (at least in the context of the Prelude > and hslibs/), than I don't know what is. > > It commits to a particular platform at too early a stage -- details > of C header files are often best left toC source files > for C compilers > to process and deal with, not Haskell. If possible, keeping your > Haskell sources plat-indep. is a good goal to have, and I don't see > any fundamental reasons why that can't be done here (indeed, the > previous Prelude cbits/ setup was fairly close to achieving this). Yes, I have to reluctantly admit this is an unfortunate, and unforseen, consequence of having moved these libraries into Haskell+hsc2hs. Oh well. > So, bringing back the solution of having manually written C wrapper > functions which platform-independent Haskell source files will > call out to, would be preferable (in short, avoid the use of hsc2hs > *or any other extra tool* alltogether). I'm willing to make the > necessary changes. Having just looked at the code, it seems we could recover the platform-independentness in the I/O library with just a small amount of wrapperage: most of the offending code is in PrelPosix.hsc, with a few #const's scattered around PrelHandle and PrelIO, and none of the affected areas are particularly performance-critical. Also needing wrappers are Time, CPUTime, Directory & System. I'd say stop there, though - this is purely to make bootstrapping on a new OS easier, so we only need to apply the no-tool restriction to libraries needed by the compiler. IOExts shouldn't be a .hsc file at all - the #defs are unnecessary and even wrong (I think I've already turned these into inline functions in HsLang.h in the new libraries). Cheers, Simon ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: Building GHC 5.02 on Solaris x86
"Alastair David Reid" <[EMAIL PROTECTED]> writes: > > > So, bringing back the solution of having manually written C wrapper > > functions which platform-independent Haskell source files will call > > out to, would be preferable (in short, avoid the use of hsc2hs *or > > any other extra tool* alltogether). I'm willing to make the > > necessary changes. > > You started by objecting to using a tool that commits your code to a > platform too early. I'm in complete agreement. > > But now you seem to be objecting to using any tools at all. This seems > excessive. Why not do one of: > [..suggestions on what kind of tool to provide..] > > (This is all on the assumption that the amount of code we're talking > about is significant enough to care. I have the impression that it is > but could be wrong.) > Yep, I'm of the humble(?) opinion that it is not. Minimising your tool dependencies is always something to keep in mind too. But let not that be the main point - the main point was that this problem needs to be addressed, tool or no tool. I offered a no-tool solution which has worked well in the past. --sigbjorn ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: Building GHC 5.02 on Solaris x86
> So, bringing back the solution of having manually written C wrapper > functions which platform-independent Haskell source files will call > out to, would be preferable (in short, avoid the use of hsc2hs *or > any other extra tool* alltogether). I'm willing to make the > necessary changes. You started by objecting to using a tool that commits your code to a platform too early. I'm in complete agreement. But now you seem to be objecting to using any tools at all. This seems excessive. Why not do one of: 1) Don't write the tool in Haskell 2) Write in Haskell but execute it using a more easily ported Haskell implementation (i.e., Hugs or NHC) 3) Write it in Haskell but include platform independent machine generated code in the distributions. [I lean towards 3 since it avoids the embarressment of 1 and 2] (This is all on the assumption that the amount of code we're talking about is significant enough to care. I have the impression that it is but could be wrong.) -- Alastair ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: Building GHC 5.02 on Solaris x86
Yuck. If this isn't enough to convince people that hsc2hs is not an appropriate tool (at least in the context of the Prelude and hslibs/), than I don't know what is. It commits to a particular platform at too early a stage -- details of C header files are often best left toC source files for C compilers to process and deal with, not Haskell. If possible, keeping your Haskell sources plat-indep. is a good goal to have, and I don't see any fundamental reasons why that can't be done here (indeed, the previous Prelude cbits/ setup was fairly close to achieving this). So, bringing back the solution of having manually written C wrapper functions which platform-independent Haskell source files will call out to, would be preferable (in short, avoid the use of hsc2hs *or any other extra tool* alltogether). I'm willing to make the necessary changes. --sigbjorn As another data point, this is also an issue when booting under OpenBSD x86. I suspect anyone with a version of the glibc headers on a Linux box different to those used to bake the supplied .hc / .hs files are also at risk of running into problems. - Original Message - From: "Simon Marlow" <[EMAIL PROTECTED]> To: "Ian Lynagh" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Monday, October 29, 2001 03:08 Subject: RE: Building GHC 5.02 on Solaris x86 > > > Doh, I have several times got further than I thought but > > didn't realise > > it as I didn't notice it had made a ghc-5.02 binary! > > > > Here's my latest problem, anyway - I don't suppose it could > > be caused by > > the hc files being generated under a different OS with different magic > > numbers could it? > > Ah yes, I forgot about that. Ken Shan came across the same problem when > porting to Alpha. > > To generate a Solaris-friendly set of hc files for the libraries you > need to do this: for each .hsc file, take the C output from hsc2hs on a > Linux box (use --no-compile to get the _hsc_make.c file), and > compile/run it on your Solaris box to get the .hs file. Take the .hs > file back to Linux to generate the .hc file. > > You will probably have to generate a full set of .hc files, including > the compiler. That means doing a 2-stage build on Linux using the .hs > files generated on Solaris as above. > > Cheers, > Simon > > ___ > Glasgow-haskell-bugs mailing list > [EMAIL PROTECTED] > http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: Building GHC 5.02 on Solaris x86
Thanks for your help Simon. Unfortunately I think I have spent enough time on this, and not enough on what I would like it for, without getting there - I may try again in the future if the porting process becomes better documented/tested. Ian ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
RE: Building GHC 5.02 on Solaris x86
> Doh, I have several times got further than I thought but > didn't realise > it as I didn't notice it had made a ghc-5.02 binary! > > Here's my latest problem, anyway - I don't suppose it could > be caused by > the hc files being generated under a different OS with different magic > numbers could it? Ah yes, I forgot about that. Ken Shan came across the same problem when porting to Alpha. To generate a Solaris-friendly set of hc files for the libraries you need to do this: for each .hsc file, take the C output from hsc2hs on a Linux box (use --no-compile to get the _hsc_make.c file), and compile/run it on your Solaris box to get the .hs file. Take the .hs file back to Linux to generate the .hc file. You will probably have to generate a full set of .hc files, including the compiler. That means doing a 2-stage build on Linux using the .hs files generated on Solaris as above. Cheers, Simon ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: Building GHC 5.02 on Solaris x86
Doh, I have several times got further than I thought but didn't realise
it as I didn't notice it had made a ghc-5.02 binary!
Here's my latest problem, anyway - I don't suppose it could be caused by
the hc files being generated under a different OS with different magic
numbers could it?
m99igl@booth33:rts$
LD_LIBRARY_PATH=/auto/ecslab/m99igl/scratch/local/readline/lib truss -o
truss.out ../../ghc/compiler/ghc-inplace -optc-O -optc-O2
-optc-fomit-frame-pointer -optc-Wall -optc-W -optc-Wstrict-prototypes
-optc-Wmissing-prototypes -optc-Wmissing-declarations -optc-Winline
-optc-Waggregate-return -optc-Wbad-function-cast -optc-Wcast-align
-optc-DCOMPILING_RTS -ldl -I../includes -I. -Iparallel -O2
-DCOMPILING_RTS -static-c Adjustor.c -o Adjustor.o
inappropriate type
Action: hFileSize
Handle:
{loc=/tmp/foo/ghc-5.02/ghc/driver/package.conf.inplace,type=readable,binary=False,buffering=block
(8192)}
Reason: not a regular file
File:
/tmp/foo/ghc-5.02/ghc/driver/package.conf.inplace
m99igl@booth33:rts$
-rw--- 1 m99igl 7270 Oct 26 23:40
/tmp/foo/ghc-5.02/ghc/driver/package.conf.inplace
truss says:
[...]
xstat(2, "/tmp/foo/ghc-5.02/package.conf", 0x500BB020) Err#2 ENOENT
xstat(2, "", 0x500BB0B8)= 0
open("/tmp/foo/ghc-5.02/ghc/driver/package.conf.inplace",
O_RDONLY|O_CREAT|O_NOCTTY, 0666) = 3
fcntl(3, F_GETFL, 0x01B6) = 0
fstat64(3, 0x0804569C) = 0
fstat64(3, 0x0804569C) = 0
fcntl(3, F_SETFL, 0x0800) = 0
fxstat(2, 3, 0x500BB190)= 0
ioctl(3, TCGETA, 0x0804575C)Err#25 ENOTTY
fxstat(2, 3, 0x500BB1F0)= 0
write(2, " i", 1) = 1
write(2, " n", 1) = 1
[spells out "appropriate type" etc]
Thanks
Ian
___
Glasgow-haskell-bugs mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
RE: Building GHC 5.02 on Solaris x86
> I've attached a diff of the changes I've made so far - they > are changes > to make it work rather than the correct way to fix it, though. Thanks. I've fixed the 'ld -x' problem. You also appear to need an extra -L path to find the readline library - we don't have proper provision for this at the moment, so hacking it in by hand is fine. > I'm not quite there yet. It's currently doing this when linking > everything together into ghc-5.02: > > [...] > lHSconcurrent -lHSlang -lHSlang_cbits -lHSstd -lHSstd_cbits > -lHSrts -lgmp -lm > -L/auto/ecslab/m99igl/scratch/local/readline/lib -lreadline > -lhistory -ltermcap -ldl > Undefined first referenced > symbol in file > Readline_addzuhistory_closure ghci/InteractiveUI.o > Readline_readline_fast2 ghci/InteractiveUI.o > Readline_readline_closure ghci/InteractiveUI.o > __stginit_Readline ghci/InteractiveUI.o > ld: fatal: Symbol referencing errors. No output written to ghc-5.02 > collect2: ld returned 1 exit status > make[1]: *** [ghc-5.02] Error 1 > make: *** [all] Error 1 > make: Leaving directory `/tmp/foo/ghc-5.02/ghc' Hmmm, looks like your libHSutil.a is missing the Readline module. Cheers, Simon ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: Building GHC 5.02 on Solaris x86
On Tue, Oct 23, 2001 at 02:10:52PM +0100, Simon Marlow wrote: > > I am trying to build GHC 5.02 on an x86 Solaris machine (with > > the x86 HC > > stuff) and I am getting this error: > > [...] > > You need to add the line > > MArray_HC_OPTS += -monly-3-regs > > to fptools/hslibs/lang/Makefile. Thanks > > I have also fount it neccesary to add > > /tmp/foo/ghc-5.02/ghc/driver/mangler to the path for ghc-asm - should > > this be needed? > > I don't know, we haven't tested the bootstrapping process very > thoroughly due to lack of time. I'll be happy to look through any > patches you come up with, though. I've attached a diff of the changes I've made so far - they are changes to make it work rather than the correct way to fix it, though. I'm not quite there yet. It's currently doing this when linking everything together into ghc-5.02: [...] lHSconcurrent -lHSlang -lHSlang_cbits -lHSstd -lHSstd_cbits -lHSrts -lgmp -lm -L/auto/ecslab/m99igl/scratch/local/readline/lib -lreadline -lhistory -ltermcap -ldl Undefined first referenced symbol in file Readline_addzuhistory_closure ghci/InteractiveUI.o Readline_readline_fast2 ghci/InteractiveUI.o Readline_readline_closure ghci/InteractiveUI.o __stginit_Readline ghci/InteractiveUI.o ld: fatal: Symbol referencing errors. No output written to ghc-5.02 collect2: ld returned 1 exit status make[1]: *** [ghc-5.02] Error 1 make: *** [all] Error 1 make: Leaving directory `/tmp/foo/ghc-5.02/ghc' I'm doing something like: bunzip2 -c ghc-5.02-src-2.tar.bz2 | tar -xf - bunzip2 -c ghc-5.02-i386-hc-1.tar.bz2 | tar -xf - tar -zxf happy-1.11-src.tar.gz cd ghc-5.02 ln -s ../happy-1.11/happy/ happy export PATH=$PATH:/tmp/foo/ghc-5.02/ghc/driver/mangler CPPFLAGS=-I/auto/ecslab/m99igl/scratch/local/readline/include/ distrib/hc-build --prefix=/auto/ecslab/m99igl/scratch/local/ghc --includedir=/auto/ecslab/m99igl/scratch/local/readline/include/ If anyone spots anything obviously stupid I'm doing, please let me know :-) Thanks Ian diff -ur ghc-5.02x/ghc/lib/std/Makefile ghc-5.02/ghc/lib/std/Makefile --- ghc-5.02x/ghc/lib/std/Makefile Tue Oct 23 10:24:45 2001 +++ ghc-5.02/ghc/lib/std/Makefile Tue Oct 23 22:54:04 2001 @@ -113,14 +113,14 @@ ifneq "$(TARGETPLATFORM)" "i386-unknown-mingw32" # Standard rule HSstd.o :: $(GHCI_LIBOBJS) - ld -r -x -o $@ $(GHCI_LIBOBJS) + ld -r -o $@ $(GHCI_LIBOBJS) else # Rule for Win32 platform # Keep HSstd.o as a pseudo-target (I think) HSstd.o :: $(GHCI_LIBOBJS) - ld -r -x -o HSstd1.o $(filter Prel%, $(GHCI_LIBOBJS)) - ld -r -x -o HSstd2.o $(filter-out Prel%, $(GHCI_LIBOBJS)) + ld -r -o HSstd1.o $(filter Prel%, $(GHCI_LIBOBJS)) + ld -r -o HSstd2.o $(filter-out Prel%, $(GHCI_LIBOBJS)) endif # TARGETPLATFORM = i386-unknown-mingw32 diff -ur ghc-5.02x/ghc/rts/StgCRun.c ghc-5.02/ghc/rts/StgCRun.c --- ghc-5.02x/ghc/rts/StgCRun.c Tue Oct 23 10:24:46 2001 +++ ghc-5.02/ghc/rts/StgCRun.c Tue Oct 23 22:57:20 2001 @@ -138,7 +138,7 @@ "movl %2,%%eax\n\t" "jmp *%%eax\n\t" - ".global " STG_RETURN "\n" + ".globl " STG_RETURN "\n" STG_RETURN ":\n\t" "movl %%esi, %%eax\n\t" /* Return value in R1 */ diff -ur ghc-5.02x/hslibs/lang/Makefile ghc-5.02/hslibs/lang/Makefile --- ghc-5.02x/hslibs/lang/Makefile Tue Oct 23 10:24:47 2001 +++ ghc-5.02/hslibs/lang/Makefile Tue Oct 23 22:54:14 2001 @@ -20,6 +20,7 @@ CTypes_HC_OPTS += -monly-3-regs ArrayBase_HC_OPTS += -monly-3-regs ForeignObj_HC_OPTS+= -monly-3-regs +MArray_HC_OPTS+= -monly-3-regs StorableArray_HC_OPTS += -funbox-strict-fields include $(TOP)/mk/target.mk diff -ur ghc-5.02x/hslibs/win32/Makefile ghc-5.02/hslibs/win32/Makefile --- ghc-5.02x/hslibs/win32/Makefile Tue Oct 23 10:24:47 2001 +++ ghc-5.02/hslibs/win32/Makefile Tue Oct 23 22:54:18 2001 @@ -58,9 +58,9 @@ HACKY_ALLOBJS = $(sort $(LIBOBJS) $(STUBOBJS) \ Win32Dialogue_stub.o Win32Window_stub.o) HSwin32.o :: $(HACKY_ALLOBJS) - ld -r -x -o HSwin321.o $(filter Win32M% Win32N% Win32R% Win32W%, \ + ld -r -o HSwin321.o $(filter Win32M% Win32N% Win32R% Win32W%, \ $(HACKY_ALLOBJS)) - ld -r -x -o HSwin322.o $(filter-out Win32M% Win32N% Win32R% Win32W%, \ + ld -r -o HSwin322.o $(filter-out Win32M% Win32N% Win32R% Win32W%, \ $(HACKY_ALLOBJS)) diff -ur ghc-5.02x/mk/bootstrap.mk ghc-5.02/mk/bootstrap.mk --- ghc-5.02x/mk/bootstrap.mk Tue Oct 23 10:24:44 2001 +++ ghc-5.02/mk/bootstrap.mkTue Oct 23 22:56:00 2001 @@ -114,7 +114,7 @@ -u "PrelMain_mainIO_closure"\ -u "__stginit_PrelMain" -HC_BOOT_LIBS = -lHStext -lHStext_cbits -lHSutil -lHSposix -lHSposix_cbits -lHSconcurren
RE: Building GHC 5.02 on Solaris x86
> I am trying to build GHC 5.02 on an x86 Solaris machine (with
> the x86 HC
> stuff) and I am getting this error:
>
>
> gcc -x c MArray.hc -o MArray.raw_s -S -O -fno-defer-pop
> -fomit-frame-pointer -DDONT_WANT_WIN32_DLL_SUPPORT
> -D__GLASGOW_HASKELL__=502 -O
> -I/tmp/foo/ghc-5.02/ghc/includes
> -I/tmp/foo/ghc-5.02/ghc/lib/std/cbits
> -I/tmp/foo/ghc-5.02/hslibs/lang/cbits
> -I/tmp/foo/ghc-5.02/hslibs/posix/cbits
> -I/tmp/foo/ghc-5.02/hslibs/util/cbits
> -I/tmp/foo/ghc-5.02/hslibs/text/cbits
> -I/tmp/foo/ghc-5.02/hslibs/hssource/cbits
> -I../../ghc/lib/std/cbits -I../../ghc/includes -Icbits-I.
> `echo | sed 's/^$/-DSTOLEN_X86_REGS=4/'`
> MArray.hc: In function `sbMI_ret':
> MArray.hc:5292: fixed or forbidden register 3 (bx) was
> spilled for class GENERAL_REGS.
> MArray.hc:5292: This may be due to a compiler bug or to impossible asm
> MArray.hc:5292: statements or clauses.
> MArray.hc:5292: This is the instruction:
> (insn 28 26 31 (set (mem/s:DI (plus:SI (plus:SI (mult:SI (reg:SI 25)
> (const_int 8 [0x8]))
> (reg:SI 26))
> (const_int 8 [0x8])) 0)
> (reg/v:DI 24)) 79 {movdi+1} (insn_list 16 (insn_list
> 24 (insn_list 26 (nil
> (expr_list:REG_DEAD (reg/v:DI 24)
> (expr_list:REG_DEAD (reg:SI 25)
> (expr_list:REG_DEAD (reg:SI 26)
> (nil)
> make[1]: *** [MArray.raw_s] Error 1
> make: *** [all] Error 1
> make: Leaving directory `/tmp/foo/ghc-5.02/hslibs'
You need to add the line
MArray_HC_OPTS += -monly-3-regs
to fptools/hslibs/lang/Makefile.
> I have also fount it neccesary to add
> /tmp/foo/ghc-5.02/ghc/driver/mangler to the path for ghc-asm - should
> this be needed?
I don't know, we haven't tested the bootstrapping process very
thoroughly due to lack of time. I'll be happy to look through any
patches you come up with, though.
Cheers,
Simon
___
Glasgow-haskell-bugs mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Building GHC 5.02 on Solaris x86
I am trying to build GHC 5.02 on an x86 Solaris machine (with the x86 HC
stuff) and I am getting this error:
gcc -x c MArray.hc -o MArray.raw_s -S -O -fno-defer-pop -fomit-frame-pointer
-DDONT_WANT_WIN32_DLL_SUPPORT -D__GLASGOW_HASKELL__=502 -O
-I/tmp/foo/ghc-5.02/ghc/includes -I/tmp/foo/ghc-5.02/ghc/lib/std/cbits
-I/tmp/foo/ghc-5.02/hslibs/lang/cbits -I/tmp/foo/ghc-5.02/hslibs/posix/cbits
-I/tmp/foo/ghc-5.02/hslibs/util/cbits -I/tmp/foo/ghc-5.02/hslibs/text/cbits
-I/tmp/foo/ghc-5.02/hslibs/hssource/cbits -I../../ghc/lib/std/cbits
-I../../ghc/includes -Icbits-I. `echo | sed 's/^$/-DSTOLEN_X86_REGS=4/'`
MArray.hc: In function `sbMI_ret':
MArray.hc:5292: fixed or forbidden register 3 (bx) was spilled for class GENERAL_REGS.
MArray.hc:5292: This may be due to a compiler bug or to impossible asm
MArray.hc:5292: statements or clauses.
MArray.hc:5292: This is the instruction:
(insn 28 26 31 (set (mem/s:DI (plus:SI (plus:SI (mult:SI (reg:SI 25)
(const_int 8 [0x8]))
(reg:SI 26))
(const_int 8 [0x8])) 0)
(reg/v:DI 24)) 79 {movdi+1} (insn_list 16 (insn_list 24 (insn_list 26 (nil
(expr_list:REG_DEAD (reg/v:DI 24)
(expr_list:REG_DEAD (reg:SI 25)
(expr_list:REG_DEAD (reg:SI 26)
(nil)
make[1]: *** [MArray.raw_s] Error 1
make: *** [all] Error 1
make: Leaving directory `/tmp/foo/ghc-5.02/hslibs'
I have also fount it neccesary to add
/tmp/foo/ghc-5.02/ghc/driver/mangler to the path for ghc-asm - should
this be needed?
Thanks
Ian
___
Glasgow-haskell-bugs mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
