Re: ghc for hp-ux 11.11...
Okay, I've tried to follow the directions, and ran into a couple minor issues I was able to work through, but I got stuck at the cd H/libraries make boot make stage. The host system is redhat enterprise linux 3, the target is hp-ux 11.11, the output is below: /var/tmp/work/ghc-6.2.2/libraries 1030 $ make boot make ===fptools== Recursively making `boot' in base haskell98 haskell-src network parsec QuickCheck readline unix ... PWD = /var/tmp/work/ghc-6.2.2/libraries ==fptools== make boot -r; in /var/tmp/work/ghc-6.2.2/libraries/base ../../ghc/utils/hsc2hs/hsc2hs-inplace -Iinclude -I../../ghc/includes -I. System/CPUTime.hsc In file included from /var/tmp/work/ghc-6.2.2/ghc/includes/HsFFI.h:21, from /var/tmp/work/ghc-6.2.2/ghc/utils/hsc2hs/template-hsc.h:4, from System/CPUTime_hsc_make.c:1: /var/tmp/work/ghc-6.2.2/ghc/includes/config.h:12:14: warning: ISO C requires whitespace after the macro name /var/tmp/work/ghc-6.2.2/ghc/includes/config.h:13:14: warning: ISO C requires whitespace after the macro name /var/tmp/work/ghc-6.2.2/ghc/includes/config.h:13:1: warning: hppa2 redefined /var/tmp/work/ghc-6.2.2/ghc/includes/config.h:12:1: warning: this is the location of the previous definition /var/tmp/work/ghc-6.2.2/ghc/includes/config.h:14:14: warning: ISO C requires whitespace after the macro name /var/tmp/work/ghc-6.2.2/ghc/includes/config.h:14:1: warning: hppa2 redefined /var/tmp/work/ghc-6.2.2/ghc/includes/config.h:13:1: warning: this is the location of the previous definition In file included from CPUTime.hsc:33: include/HsBase.h:64:26: sys/timers.h: No such file or directory include/HsBase.h:98:1: warning: HAVE_GETRUSAGE redefined In file included from /var/tmp/work/ghc-6.2.2/ghc/includes/HsFFI.h:21, from /var/tmp/work/ghc-6.2.2/ghc/utils/hsc2hs/template-hsc.h:4, from System/CPUTime_hsc_make.c:1: /var/tmp/work/ghc-6.2.2/ghc/includes/config.h:494:1: warning: this is the location of the previous definition make[1]: *** [System/CPUTime.hs] Error 1 make: *** [boot] Error 1 On Mon Dec 20 17:38 , [EMAIL PROTECTED] (Donald Bruce Stewart) sent: amyhr: Is it possible? Is there anyone out there who's done it and could provide advice or binaries? It should be possible. You'll have to follow the instructions from the porting guide: http://www.haskell.org/ghc/docs/latest/html/building/sec-porting-ghc.html When you run in to problems, ask on #haskell or this list. Good luck, Don ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ghc for hp-ux 11.11...
[EMAIL PROTECTED] wrote: Okay, I've tried to follow the directions, and ran into a couple minor issues I was able to work through, but I got stuck at the cd H/libraries make boot make stage. The host system is redhat enterprise linux 3, the target is hp-ux 11.11, the output is below: [...] It looks like you try to get GHC 6.2.2 up and running. Could you try the GHC from CVS HEAD instead, please? The configuration stuff has changed quite a bit, and I'm reluctant to work on the old STABLE branch. Could you send a log of the configuration/building plus all config.log and config.status files, please? In ancient times, I made GHC run on HP-UX 9, but I guess that things suffer from bit rot... Cheers, S. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Emitting java bytecode?
Hello! Would be possible for GHC to emit Java bytecode? There seems to be some code in GHC's sources (in ghc/compiler/javaGen/) suggesting that it was anticipated. I suppose most of the work would be in making a java RTS and libraries. I am mainly interested in making GHC more portable. Haskell is a great application programming language, but there are some concerns about portability of applications. Perhaps I shouldn't be looking at java bytecode for a solution... Is it possible that a C-- backend will make GHC more portable? Best regards, Tomasz ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Emitting java bytecode?
Hello Tomasz, I am mainly interested in making GHC more portable. Haskell is a great application programming language, but there are some concerns about portability of applications. What kind of concerns? We develop an application with GUI, a lot of file I/O and that interfaces with a C++ library. It compiles fine on Windows and Linux. If the C++ library would be available for the Mac, we could compile it on MacOS X, too. Cheers, Arjan ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Emitting java bytecode?
On Tue, Dec 21, 2004 at 10:41:01PM +0100, Arjan van IJzendoorn wrote: Hello Tomasz, I am mainly interested in making GHC more portable. Haskell is a great application programming language, but there are some concerns about portability of applications. What kind of concerns? For example, some darcs users complain about problems with building darcs on some exotic platforms (ie not Linux, OS X, Windows, FreeBSD). It would be nice if it was possible to distribute a .jar file for all such platforms. Best regards, Tomasz ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Emitting java bytecode?
Einar Karttunen writes: Tomasz Zielonka [EMAIL PROTECTED] writes: For example, some darcs users complain ... Perhaps making -keep-hc-files a bit more documented ... This could be faster and easier to implement than creating a version of the RTS running under the JVM. == More generally: do you (Tomasz and others) really think that Java, or even C/C++ is a good portable platform for implementing efficiently Haskell or other lazy functional languages?? I believe this has been discussed already. And GHC passed already through this stage. I don't believe the world can return to it. The RT model is different, even decently implemented tail recursion is not so easy in C, and in Java I wouldn't bet either. Moreover, I don't think that Haskell is a good way to perpetuate imperative languages as portable platforms. While Lisp machine belongs to the past, it seems reasonable to hope that functional hardware, with some universal implementation paradigms, will be more popular... Jerzy Karczmarczuk ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
