May 2003 - Glasgow-haskell-users

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

Re: building ghc from source
by johago＠web.de 24 May '03

24 May '03

----- Original Message ----- From: Simon Peyton-Jones To: johago(a)web.de ; GHC bugs Sent: Monday, May 19, 2003 10:23 AM Subject: RE: building ghc from source [Redirecting this to GHC bugs] 9. Entered "./configure --host=i386-unknown-mingw32 --with-gcc=/cygdrive/c/MinGW/bin/gc c". No errors occurred. I believe your problem is here. You must not use Cygwin-style paths when specifying what GCC is. Instead use --with-gcc=c:/mingw/bin/gcc Can you let me know if that fixes it? (remove config.cache before reconfiguring) The online Building Guide is wrong on this point, but it's fixed in the repository. I'll try to get the fixed version online asap. Simon I tried to compile the current cvs sources (using the windows binary distribution of ghc-5.04.3), following your instructions. Giving a windows style path name for for the gcc executable seems to solve my (first) problem. According to Mike Thomas' and Derek Elkins' posts, I also enabled HAVE_O_BINARY in config.h. ./configure --build=i386-unknown-mingw32 --with-gcc=c:/MinGW/bin/gcc make --- snip --- [...] ../../glafp-utils/mkdependC/mkdependC -f .depend -I../../ghc/includes -s p -- -mno-cygwin -O -DTARGET_GHC -I../../ghc/includes -- GDITypes_stub_ffi.c Win3 2Bitmap_stub_ffi.c Win32Brush_stub_ffi.c Win32Clip_stub_ffi.c Win32Control_stub_ ffi.c Win32DLL_stub_ffi.c Win32Dialogue_stub_ffi.c Win32File_stub_ffi.c Win32Fon t_stub_ffi.c Win32Graphics2D_stub_ffi.c Win32HDC_stub_ffi.c Win32Icon_stub_ffi.c Win32Key_stub_ffi.c Win32MM_stub_ffi.c Win32Menu_stub_ffi.c Win32Misc_stub_ffi. c Win32NLS_stub_ffi.c Win32Palette_stub_ffi.c Win32Path_stub_ffi.c Win32Pen_stub _ffi.c Win32Process_stub_ffi.c Win32Region_stub_ffi.c Win32Registry_stub_ffi.c W in32Resource_stub_ffi.c Win32SystemInfo_stub_ffi.c Win32Types_stub_ffi.c Win32Wi nMessage_stub_ffi.c Win32Window_stub_ffi.c WndProc.c diatemp.c dumpBMP.c errors. c finalizers.c spawnProc.c ../../ghc/compiler/ghc-inplace -M -optdep-f -optdep.depend -optdep-s -optdepp -o suf o -H16m -O -cpp -fvia-C -optc-DTARGET_GHC -fglasgow-exts -package-name wi n32 -O -Rghc-timing -package lang GDITypes.hs StdDIS.hs Win32.hs Win32Bitmap.hs Win32Brush.hs Win32Clip.hs Win32Control.hs Win32DLL.hs Win32Dialogue.hs Win32Fil e.hs Win32Font.hs Win32Graphics2D.hs Win32HDC.hs Win32Icon.hs Win32Key.hs Win32M M.hs Win32Menu.hs Win32Misc.hs Win32NLS.hs Win32Palette.hs Win32Path.hs Win32Pen .hs Win32Process.hs Win32Region.hs Win32Registry.hs Win32Resource.hs Win32Spawn. hs Win32SystemInfo.hs Win32Types.hs Win32WinMessage.hs Win32Window.hs Win32Spawn.hs: can't locate import `GHC.Posix' make[2]: *** [depend] Error 1 make[1]: *** [boot] Error 1 make[1]: Leaving directory `/cygdrive/c/try6/fptools/hslibs' make: *** [build] Error 1 --- snap --- Unfortunately, module GHC.Posix doesn't exist. I read something about this module to be unavailable under mingw and that I first had to build a cygwin-ghc-inplace which supports posix and then compile mingw-ghc with it... Therefore, I try the following: ./configure --build=i686-pc-cygwin --host=i386-unknown-mingw32 omitting --with-gcc=c:/MinGW/bin/gcc Is this correct? Thanks again, Johannes johago(a)web.de

3 2

instance MPlus IO?
by Hal Daume III 22 May '03

22 May '03

THe docs claim this instance exists, but it doesn't seem to. Moreoever, such an instance doesn't make sense to me. -- Hal Daume III | hdaume(a)isi.edu "Arrest this man, he talks in maths." | www.isi.edu/~hdaume

4 3

RE: Converting things to and from binary
by Simon Marlow 21 May '03

21 May '03

> Several tests by SimonM and I have shown > that the bit style is about 20% slower than the byte style. Really? I seem to recall it was more like 250% :-) http://haskell.org/pipermail/libraries/2002-December/000742.html Cheers, Simon

2 1