- Glasgow-haskell-users

RE: Problems building ghc-current
by Simon Marlow 28 May '03

28 May '03

> "Simon Marlow" <simonmar(a)microsoft.com> writes: > > > > /cvs --+ > > > | > > > +-- CVSROOT > > > | > > > +-- fptools > > > | > > > +-- ghc > > > | > > > +-- libraries > > > | > > > +-- hslibs > > > | > > > +-- green-card > > > [...] > > > > We could just rearrange the repository in place, and > everything would > > still work, right? Well, perhaps the script that generates the CVS > > commit logs would have to be tweaked. > > Don't forget that any scripts/Makefiles that refer to ../something may > need to change to ../fptools/something. Examples might include the > global `mk' files, glafp-utils, and so on. Of course, those could > all live at the new toplevel as well, provided that checking out the > 'fptools' project collected all of them in one operation. No, the idea is that the source tree structure would remain exactly the same, it's only the repository that would change. The checkout procedure remains almost the same: $ cvs co fptools $ cd fptools $ cvs co ghc hslibs libraries (except the third step now *must* be 'cvs co', not 'cvs up -d'). The advantages are that (a) there's no hacky 'fpconfig' module, and (b) 'cvs update -d' works properly from the top of fptools. One possible problem is that if we switch to using something less braindead than CVS (eg. Subversion) at some point in the future, this structure might cause problems. Cheers, Simon

1 0

Problems building ghc-current
by Peter Simons 28 May '03

28 May '03

Hi, I'm trying to compile the latest version of GHC from CVS. I followed the instructions on GHC's web page and everything worked just fine. But when I updated the sources with "cvs update -dP" as instructed, CVS checked-out pretty much everything the CVS repository carries. (Is that supposed to happen? The CVS cheat sheet suggests that only "ghc", "libraries", and "hslibs" would be used/required.) So, when I tried to compile again -- now with _everything_ in the source tee --, the build fails here: | ------------------------------------------------------------------------ | ==fptools== make boot -wr; | in /usr/local/src/ghc-current/green-card/lib | ------------------------------------------------------------------------ | target ffi Foreign/GreenCard.gc -o Foreign/GreenCard.hs | make[2]: target: Command not found | make[2]: [Foreign/GreenCard.hs] Error 127 (ignored) Obviously, at some point the Makefile goes wrong and doesn't get the options right, but I have no idea where to start looking. Is this a known problem? Or has anyone a suggestion where to start debugging this? I'm building GHC on Linux/i386 with GHC 5.04.3 as boot-strapping compiler and GCC 3.2.2 as C backend. Any suggestions are appreciated! Peter

3 6

RE: Problems building ghc-current
by Simon Marlow 28 May '03

28 May '03

> I'm trying to compile the latest version of GHC from CVS. I followed > the instructions on GHC's web page and everything worked just fine. > But when I updated the sources with "cvs update -dP" as instructed, > CVS checked-out pretty much everything the CVS repository carries. Sorry about that, the instructions should really say that 'cvs update -dP' is only to be done in each project subdirectory. You still need to 'cvs update' at the top-level. CVS doesn't really support the structure of our source tree very well. Cheers, Simon

2 1

linking ghc object files with mingw-g++
by johago＠web.de 28 May '03

28 May '03

Hi! I'm trying to link ghc object files with mingw's g++/ld... The following shows that linking ghc code with C code can be done very easily: $ cat > Test.hs module Test where foreign export ccall test :: IO () test = putStr "Hello from Haskell World!\n" $ cat > main.c #include "RtsApi.h" #include "Test_stub.h" #ifdef __cplusplus extern "C" #endif void __stginit_Test(void); int main(int argc, char *argv[]) { startupHaskell(argc, argv, __stginit_Test); test(); shutdownHaskell(); } $ ghc -ffi -c Test.hs -o Test.o $ gcc -c Test_stub.c -Ic:/ghc/ghc-5.04.3/include $ gcc -c main.c -Ic:/ghc/ghc-5.04.3/include $ ghc -no-hs-main main.o Test.o Test_stub.o $ ./a.out Hello from Haskell World! The procedure above works well with gcc; g++ object files seem to depend on a rt-lib or something, which ghc does not link into the executable by default. $ g++ -c main.cpp -Ic:/ghc/ghc-5.04.3/include $ ghc -no-hs-main main.o Test.o Test_stub.o main.o(.text+0x22):main.cpp: undefined reference to `__stginit_Test()' main.o(.eh_frame+0x11):main.cpp: undefined reference to `__gxx_personality_v0' The other way round, linking the files with gcc/ld, using $ gcc main.c Test_stub.c -Ic:/ghc/ghc-5.04.3/include \ c:/ghc/ghc-5.04.3/HSbase1.o \ c:/ghc/ghc-5.04.3/HSbase2.o \ c:/ghc/ghc-5.04.3/HSbase3.o \ c:/ghc/ghc-5.04.3/HSbase_cbits.o \ c:/ghc/ghc-5.04.3/HStext.o \ c:/ghc/ghc-5.04.3/HStext_cbits.o \ c:/ghc/ghc-5.04.3/HSlang.o \ c:/ghc/ghc-5.04.3/HSlang_cbits.o \ c:/ghc/ghc-5.04.3/HShaskell98.o \ c:/ghc/ghc-5.04.3/HSrts.o \ -lgmp Test.o -lwsock32 -lgmp -lwinmm results in c:/ghc/ghc-5.04.3/HSrts.o(.text+0x9ff8): multiple definition of `main' c:\DOKUME~1\jgoetz\LOKALE~1\Temp/ccWKaaaa.o(.text+0x0):main.c: first defined here c:/ghc/ghc-5.04.3/HSrts.o(.text+0xa00e): undefined reference to `__stginit_Main' c:/ghc/ghc-5.04.3/HSrts.o(.text+0xa01f): undefined reference to `Main_zdmain_closure' I'm stuck... Is there a way to merge ghc code with c++ code? What am I doing wrong? Do you think it's possible to link ghc object code with Metrowerks and MSVC? btw, I'm using ghc-5.04.3, windows binary distribution and current mingw g++ Thanks, Johannes johago(a)web.de

2 3

RE: linking ghc object files with mingw-g++
by Simon Peyton-Jones 28 May '03

28 May '03

I have never tried to link C++ with GHC stuff; I know that it has caused people difficulties in the past. If someone who has got it working cares to write up some notes on what to do, I'll gladly incorporate them in the GHC users guide. From what Koen says, maybe it's possible! Simon | -----Original Message----- | From: glasgow-haskell-users-admin(a)haskell.org [mailto:glasgow-haskell-users-admin@haskell.org] | On Behalf Of Koen Claessen | Sent: 28 May 2003 07:17 | To: johago(a)web.de | Cc: glasgow-haskell-users(a)haskell.org | Subject: Re: linking ghc object files with mingw-g++ | | | | I'm trying to link ghc object files with mingw's | | g++/ld... | | We have used the g++-2 compiler that you can get with Cygwin | and it seems to work fine. (mingw-g++ and the normal g++ did | not work for us.) | | Another hint: maybe you should give "-lstdc++" as a flag to | the final linking fase. | | A final hint: I have heard rumours of people changing the | linker that GHC uses to be g++'s linker, maybe that helps in | your case. Apparently, some C++ code requires special | treatment at linking time, something that normal ld does not | do. | | /Koen | | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users(a)haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

1 0

Your Inquiry in www.bau-center.com
by LOADER KOMATSU 28 May '03

28 May '03

Your Inquiry in www.bau-center.com DEAR SIR, WE ARE URGENTLY LOOKING FOR USED LOADER TYP VOLVO KOMATSU 2 TILL 3 M3 FOR KROATIA. 4 OR 5 YEARS OLD. PLEASE SEND US OFFER. M.HOEPPNER.

1 0

ChipNews - Chipworks "Inside Technology" Newsletter - Issue 1, 2003
by Chipworks 27 May '03

27 May '03

1 0

RE: GHCi spaces-on-folder-names bug revisited.
by Simon Marlow 27 May '03

27 May '03

> And, in particular, will it fix the large file business? > > If it's going to take a while, I'll implement multiple files to work > around the 2G limit, but if it's about to be released, I'd rather just > wait for the upgraded RPMs. 6.0 won't fix the large file issues I'm afraid; I'm still working on that one. Hopefully I'll get the fix into the next release. Cheers, Simon

1 0

RE: GHCi spaces-on-folder-names bug revisited.
by Simon Peyton-Jones 26 May '03

26 May '03

| > You mean 6.00? :) | | OK; when will the *next* release be around? Soon. A week or two, not a month or two. The tree is forked, we have no unexpected failures, etc | And, in particular, will it fix the large file business? | | If it's going to take a while, I'll implement multiple files to work | around the 2G limit, but if it's about to be released, I'd rather just | wait for the upgraded RPMs. I'll let Simon M answer that. Simon

1 0

GHCi spaces-on-folder-names bug revisited.
by Calle Lejdfors 26 May '03

26 May '03

Hello. I have recently built a GHC/GHCi from the "ghc-5-04-branch" to check whether the bug concerning white spaces in folder names have been resolved. It has (thanks!) but while testing it I found another strangeness: it does not work for literate Haskell-scripts. $ ghci test\ dir/Test.lhs [...] Loading package base ... linking ... done. Loading package haskell98 ... linking ... done. usage: unlit [-q] [-n] [-c] file1 file2 phase `Literate pre-processor' failed (exitcode = 1) Prelude> Whereas for the non-literate version seemingly works correctly. When running unlit manually via $ /usr/local/lib/ghc-5.04.3/unlit test\ dir/Test.lhs - it prints out the correct unliterated code. Any ideas as to what goes wrong? Thanks (again), Calle. PS When will 5.04.4 be released?

4 3