RE: Updated 6.4 Windows installer RC
Hi Sigbjorne. | It hopefully sorts out the showstopping profiling problems that people | have reported; Fixed for me thanks. Cheers Mike Thomas ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: Object IO problem
Hi Simon. | Are there any Object-IO folk out there who'd like to fix (or otherwise | resolve) this sourceforge bug? | | https://sourceforge.net/tracker/index.php?func=detailaid=1145315group_ | id=8032atid=108032 I've posted a reply asking for examples and hopefully will get to the issue within the next fortnight (unless Krasimir gets there first). I'm curious about who is actually using ObjectIO. Anyone? Cheers Mike Thomas. ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: 6.4 snapshot installer available
Hi Sigbjorn. I wrote: I built CVS head GHC with this package and mucked around a little bit. The only problem I've come across so far is that an objectio library application I have crashes on take-off when built with this compiler (not necessarily to do with objectio of course). It does not crash with GHC 6.2.1 Woops. It turns out that I missed a blatantly obvious error message which 6.2.1 did not give: Starting program: c:\data\source\ghc\grass/./objectio/geo.exe grass/./objectio/geo.exe: main.hs:23:8-70: Irrefutable pattern failed for patter n [fileMenuID, mapMenuID, grassDBMenuID] after I shortened a list of ids. Luckily this afternoon I took delivery of a pair of reading glasses which will hopefully help me to avoid such errors in future. Thumbs up for that installer. Cheers Mike Thomas. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: 6.4 snapshot installer available
Hi Sigbjorn. | http://www.haskell.org/ghc/dist/stable/dist/ghc-6-4-20050301.msi | (md5.sig: 0f3be1a0c211194415b2cb8ee579f6e1 ; size: 46M) Thanks as usual. I built CVS head GHC with this package and mucked around a little bit. The only problem I've come across so far is that an objectio library application I have crashes on take-off when built with this compiler (not necessarily to do with objectio of course). It does not crash with GHC 6.2.1 I'll doubt that I'll be able to break out the debugger on this one for a while so that may have to miss the 6.4 bus I'm afraid. Cheers Mike Thomas. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Windows nofib
Hi Simon.
I've made the following change to get nofib tests running for Cygwin hosted
MinGW32 builds, at least on my computer:
Index: runstdtest.prl
===
RCS file: /home/cvs/root/fptools/glafp-utils/runstdtest/runstdtest.prl,v
retrieving revision 1.31
diff -r1.31 runstdtest.prl
56a57,63
# If this is Cygwin, ignore eol and CR characters.
# Perhaps required for MSYS too, although the cygpath
# bit is hopefully unnecessary.
if ( `uname | grep CYGWIN` ) {
$CONTEXT_DIFF=$CONTEXT_DIFF . --strip-trailing-cr ;
$TmpPrefix = `cygpath -m $TmpPrefix | tr -d n`;
}
===
I can't test this on a Unix platform so please excuse any overnight test
failures which might result.
The next exciting bug in nofib on Windows is now revealed:
==fptools== make all - --unix - --no-print-directory -r;
in /c/cvs/head/i386-unknown-mingw32/nofib/spectral/fft2
HC = /c/cvs/head/i386-unknown-mingw32/ghc/compiler/stage3/ghc-inplace
HC_OPTS = -H16m -O -O -Rghc-timing -H32m -hisuf hi
RUNTEST_OPTS = -ghc-timing +RTS -H10m -K10m -RTS
==nofib== fft2: size of fft2 follows...
textdata bss dec hex filename
1354692 70320 57072 1482084 169d64 fft2.exe
==nofib== fft2: time to run fft2 follows...
/usr/bin/time ../../../glafp-utils/runstdtest/runstdtest ./fft2 \
\
-o1 fft2.stdout -o1 fft2.stdout-mingw -o1 fft2.stdout1 -o1
fft2.stdout2 -o1 ff
t2.stdout3 -o1 fft2.stdout4 -o1 fft2.stdout -o1 fft2.stdout-mingw -o1
fft2.stdou
t1 -o1 fft2.stdout2 -o1 fft2.stdout3 -o1 fft2.stdout4 \
\
-ghc-timing +RTS -H10m -K10m -RTS
/bin/sh -c ././fft2 +RTS -Sc:/DOCUME~1/miketh/LOCALS~1/Temp/stats8152 -RTS
+RTS
-H10m -K10m -RTS /dev/null 1
c:/DOCUME~1/miketh/LOCALS~1/Temp/runtest8152.1
2 c:/DOCUME~1/miketh/LOCALS~1/Temp/runtest8152.2 3
c:/DOCUME~1/miketh/LOCALS~1
/Temp/runtest8152.3
././fft2 +RTS -H10m -K10m -RTS /dev/null
expected stdout not matched by reality
*** fft2.stdout Wed Nov 3 02:12:56 1999
--- c:/DOCUME~1/miketh/LOCALS~1/Temp/runtest8152.1 Mon Sep 20 17:28:51
2004
***
*** 2,3
result2 = 2.65193921505278e-12
! result3 = 3.4766401313390816e-8
--- 2,3
result2 = 2.65193921505278e-12
! result3 = 4.829354338653502e-8
Command exited with non-zero status 1
1.09user 0.56system 0:01.64elapsed 100%CPU (0avgtext+0avgdata
447872maxresident)
k
0inputs+0outputs (28528major+0minor)pagefaults 0swaps
make[2]: *** [runtests] Error 1
make[1]: *** [all] Error 1
make: *** [all] Error 1
It may be that this is merely the result of differences in numerical
precision across platforms, and given the comment at the bottom of Main.lhs,
it might be best just to have a test, with some kind of tolerance say 1e-6,
for closeness to zero.
As a matter of interest, should this test failure cause the entire nofib
suite to fall over?
Cheers
Mike Thomas
___
Glasgow-haskell-bugs mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
RE: wanted: tester for libraries/Win32
Hi Ross. For the record I've CC'ed GHC bugs due to the error message below, although as you are dealing with foreign calls it could easily be the results of bugs in the library interface rather than the compiler. At the moment I am unable to go probing into this problem I'm sorry. | On Thu, May 06, 2004 at 12:39:40PM +1000, Mike Thomas wrote: | I CVS updated libraries/Win32 and libraries/HGL in a HEAD | fptools build tree | from a few weeks ago then make boot and make in each | followed by make | in the HGL examples directory. I hadn't realised that the hsc binding | existed. | | All built but running was a bit sad: | | Thanks, Mike. Similar results as yesterday with a fresh up-to-date source tree. An additional observation is that there are inconsistent results from one run to the next of Tests.exe which suggests to me as a first hypothesis that some memory is not being initialised: $ ./Tests Tests.exe: internal error: stg_ap_p_ret Please report this as a bug to [EMAIL PROTECTED], or http://www.sourceforge.net/projects/ghc/ [EMAIL PROTECTED] /c/cvs/head/i386-unknown-mingw32/libraries/HGL/examples $ ./Tests [EMAIL PROTECTED] /c/cvs/head/i386-unknown-mingw32/libraries/HGL/examples $ ./Tests Cheers Mike Thomas. ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
RE: wanted: tester for libraries/Win32
Hi Ross. I CVS updated libraries/Win32 and libraries/HGL in a HEAD fptools build tree from a few weeks ago then make boot and make in each followed by make in the HGL examples directory. I hadn't realised that the hsc binding existed. All built but running was a bit sad: gtest - crashes hello-world - flashes initial white then changes to black background window, window title shows only 'H', crashes when close icon hit. tests - crashes Will do a complete update/rebuild tonight and let you know what happens in case that is the cause. Sorry for the delay and thanks for the good work. Cheers Mike Thomas. | -Original Message- | From: Mike Thomas [mailto:[EMAIL PROTECTED] | Sent: Friday, 30 April 2004 8:19 AM | To: Ross Paterson | Subject: RE: wanted: tester for libraries/Win32 | | | Hi Ross. | | I'm catching up on email and still busy with things other than | GHC, but did you get help with this? | | If not, let me know and I'll try and do something over the next week. | | Cheers | | Mike Thomas. | | | -Original Message- | | From: [EMAIL PROTECTED] | | [mailto:[EMAIL PROTECTED] Behalf Of Ross | | Paterson | | Sent: Thursday, 29 April 2004 7:59 AM | | To: [EMAIL PROTECTED] | | Subject: wanted: tester for libraries/Win32 | | | | | | Would someone who's building from CVS under Windows like to try make | | in libraries/Win32, libraries/HGL and libraries/HGL/examples, and | | even run the programs in the latter directory (should they happen | | to compile)? | | ___ | | Glasgow-haskell-users mailing list | | [EMAIL PROTECTED] | | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users | | ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: Cygwin binary?
Hi Igor. | We don't support targeting Cygwin, I'm afraid. Details here: | | | http://www.haskell.org/ghc/docs/latest/html/building/winbuild.html | | Various people have worked to provide libraries offering Posix-like | facilities for Haskell on Windows, to ease the kind of porting you are | trying to do. I'm not sure what the status is, though. Mike Thomas | might be a good person to ask. I'm actually the worst to ask (I prefer that GHC remain independent of the Cygwin DLL and have never built ghc targetted at Cygwin; in fact I blame Cygwin, in the friendliest possible way, for most of the bizarre build problems I seem to encounter with GHC). I believe that Sigbjorn put a Cygwin ghc up on the web about 18 months ago but I can't find his original message and I would expect that he would not particularly want to revive it if it is no longer available. Cheers Mike Thomas. ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: the woes of non-cvs haskellers
Hi all. | Speaking from a GHC standpoint, your efforts were/are greatly | appreciated. Thanks - Didn't intend to sound Sad Sack there! | Modulo bugs (I can only test on Windows and syncing the | Hdirect libraries | with the GHC-inplace version, rather than the version of the bootstrap | compiler eluded me), those changes are backward compatible | with the usual | nightly builds so there should be no problems for those who | want to work as usual. | | If everyone thinks that these changes might be helpful, I | will bring them up | to date and check them in. | | Yes, please do this. No worries. I did a test run today and found some new problems to do with the binary-dist targets among other things (eg avoiding documentation install and build on a system without the SGML tools.) Unfortunately the turnaround is about half a working day so at most two to three full debugging runs per day. I'll send the results to ghc CVS never-the-less. Cheers Mike Thomas. ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
RE: the woes of non-cvs haskellers
Hi Claus. | A broader approach would be to try and show a united Haskell | tools front to the general Haskeller: Identify a core set of Haskell | tools (the above four would be my initial suggestion), and make | sure that the latest binary releases for these are always in synch | with each other. ... | On Windows at least, it seems that everyone | is relying on Sigbjorn to do all the packaging - couldn't the | creation of updated installers be automated (or Haskellised), | so that he'd only have to be bothered for the initial packaging, | not for patchlevel updates? I agree that it would be good to make coordinated releases of some set of the GHC tools. In particular, it would bring that rather excellent tool Hdirect into the spotlight which I think would be a good thing - for example, a binding to a substantial portion of the Win32 library should be be buildable from the Visual Basic type libraries available on the web. Towards the end of last year I started experimenting with modified nightly build scripts to build in one fell swoop ghc (and it's libraries), alex, happy, greencard and hdirect. I backed off for three reasons, one was other tasks, the second was that I felt I was possibly going off on a tangent that no-one else was interested in (at least as far as the approach I took - that is, using the CVS nightly build scripts - was concerned) and the third was that I still find building GHC on Windows a hit and miss affair. A number of build messages from this project made it to the GHC CVS mailing list at the time. Modulo bugs (I can only test on Windows and syncing the Hdirect libraries with the GHC-inplace version, rather than the version of the bootstrap compiler eluded me), those changes are backward compatible with the usual nightly builds so there should be no problems for those who want to work as usual. If everyone thinks that these changes might be helpful, I will bring them up to date and check them in. | In other words, someone could go download | them, make a Haskell tools, Spring 2004 CD, and be sure that | they actually work together while he/she's trying to learn Haskell. Unfortunately I'm unable to do this myself, but the above changes should make the task more automatable. Cheers Mike Thomas. ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: GHC and Mingw32 (cont.)
Hi Simon. If it's still a problem in approx one month I'll look into fixing it then as I feel that there may be areas of commonality with the nightly build bindist packaging for Windows - notably the way the MinGW32 C compiler is dealt with (or even at all with make install I suppose). Cheers Mike Thomas. - Original Message - From: Simon Peyton-Jones [EMAIL PROTECTED] To: Michael Adams [EMAIL PROTECTED] Cc: GHC bugs [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Tuesday, July 29, 2003 6:19 PM Subject: RE: GHC and Mingw32 (cont.) I'm redirecting this to ghc bugs and cvs-ghc. The conclusion is that 'make install' on Win32 is currently broken. (Mostly people install from the .msi installer, which is why it's not much exercised.) I doubt it's really hard, just ticklish. Does any Win32 expert feel like fixing it? We'd be happy to help. Simon | -Original Message- | From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] | On Behalf Of Michael Adams | Sent: 28 July 2003 22:34 | To: [EMAIL PROTECTED] | Subject: GHC and Mingw32 (cont.) | | Ok, I got GHC compiled but running it is a tricky. It | has trouble finding package.conf. | | I found a reference to this problem at | http://www.mail-archive.com/[EMAIL PROTECTED]/msg05617.h tml. | The work-around of doing -B does work (make sure you | don't but a space after the -B though), but it would | be nice for a better solution. Can this be fixed? | The e-mail refers to the location of package.conf | changing causing the problem. | | Michael D. Adams | [EMAIL PROTECTED] | | The following is a demonstration of the problem and | work-around. | | $ ghc --version | D:\cygwin\usr\local\stow\ghc-6-cvs\bin\ghc.exe: Can't | find package.conf as | D:\cygwin\usr\local\stow\ghc-6-cvs\ghc\driver\package.conf.inplace | | $ find /usr/local/stow/ghc-6-cvs/ -name package\* | -print | /usr/local/stow/ghc-6-cvs/lib/ghc-6.1/package.conf | | $ ghc --version | -BD:\\cygwin\\usr\\local\\stow\\ghc-6-cvs\\lib\\ghc-6.1 | The Glorious Glasgow Haskell Compilation System, | version 6.1 | | | __ | Do you Yahoo!? | Yahoo! SiteBuilder - Free, easy-to-use web site design software | http://sitebuilder.yahoo.com | ___ | Glasgow-haskell-users mailing list | [EMAIL PROTECTED] | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Cvs-ghc mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/cvs-ghc --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.502 / Virus Database: 300 - Release Date: 2003-07-18 ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
RE: Readline (was Re: state of ghc6 on sparc)
Hi Malcolm. I tried this on both a Cygwin (environment variable TERM=cygwin) and a Windows XP console with GHC 6.0. Under Cygwin, these problems occurred: 1. ^K and ^L both appear as themselves, rather than causing deletion: prompt abc^Kefg 2. When editing an item in the history buffer, if I delete a one or more characters and then move to the end of the line with the cursor, it runs off the end with the same number of characters added at the end. Those characters are taken from the characters at what was previously the end of the line eg: prompt hello delete 'l' prompt helo move to end of line: prompt heloo (This does not happen with a new item, only with history items.) This happens with a normal Windows XP command prompt too (that is, without any Haskell program running) so I suspect that it is an overprinting of the Windows terminal handling on your test program's terminal handling. The interesting result of that is that successive invocations of the same executable retain the command line history of previous runs. I would expect substantially different results running under a Win98 command line as console line editing is not provided on those older versions of the OS. Under the Windows XP command line prompt: 1. The stty system call is redundant: C:\lang\source\ghc\lineeditle 'stty' is not recognized as an internal or external command, operable program or batch file. prompt Checking that the preprocessor symbol i386_unknown_mingw32_TARGET is not defined fixed that. 2. - See points 1 and 2 of the Cygwin problems above and the conclusions drawn there. Cheers Mike Thomas. | -Original Message- | From: [EMAIL PROTECTED] | [mailto:[EMAIL PROTECTED] Behalf Of Malcolm | Wallace | Sent: Friday, June 20, 2003 2:39 AM | To: [EMAIL PROTECTED] | Cc: [EMAIL PROTECTED] | Subject: Readline (was Re: state of ghc6 on sparc) | | | Alastair Reid [EMAIL PROTECTED] writes: | | It would be nice to have those bindings but just having backspace and | left-right cursors work would already be a huge improvement | over nothing. | | OK, here is my contribution. The attached module SimpleLineEditor | is API-compatible with readline, and is a slight elaboration of | the line editor currently distributed as part of hmake interactive. | It does the basic stuff like backspace and left and right arrows. | Today's addition was a simple history mechanism using (uggh!) an IORef. | | Because of the way I chose to implement a separation of | keystroke-recognition from interpretation of the associated editing | command, it should be reasonably straightforward to extend/change | the keystrokes for different terminal types. It should also be | fairly easy to add more editing commands (e.g. there are commands | for word-movement, and begin/end of line, but no key-binding and no | interpretation yet either.) | | Perhaps we should add something like this to the hierarchical libs, | in the readline package? Then we can have some basic line-editing | functionality available in a portable fashion, independent of whether | any particular machine has the real readline library installed. | | Regards, | Malcolm | ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: building ghc from source
Hi again. | Sorry if I seem to be rejecting your offer to help. That doesn't worry me!! | At the | moment I just want | to get greencard, win32, x11 and hgl out the door. I'm tired of | endlessly | tweaking makefiles... No worries and good luck. Cheers Mike Thomas. ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
RE: building ghc from source
Hi Alastair.
| Yes -- but hslibs/win32 should be fixed, or else nuked in favour of
| libraries/win32, which Alastair is working on.
|
| Alastair: what's the story on win32 in hslibs/ or libraries/?
|
| I'd hoped to have the changeover done by now but I don't and
| won't in time so,
| for now, hslibs/win32 is the one to go with for ghc 6.0.
|
| [In particular, I haven't tried building libraries/win32 ever.]
|
| My plan is that win32, xlib, greencard, libgreencard (i.e.,
| StdDIS.{gc,hs}),
| HGL/win32 and HGL/xlib should all be separate packages from each
| other and
| from ghc. I am hoping to trickle these packages out over the
| next few weeks
| and my thought is that future releases would happen independently of each
| other, of ghc, of hugs, etc.
First: Let me say Thanks! for the effort you are making in this direction.
Second: In the GHC CVS nightly source tree I have put some minor
modifications which I hope will raise consciousness of the need for
Greencard, Happy and HDirect maintenance and perhaps assist you. To make
those modifications work (if you use the GHC nightly build system), just add
the following to your particular site/?/conf-? file:
#
# Some extra binaries
#
do_greencard=YES
do_happy=YES
do_hdirect=YES
other_update_dirs=green-card happy hdirect
See, for example, site/paradigm/conf-HEAD-water.
These additions should cause the nightly build system to attempt to build
those packages and, if necessary, to print the tail of each error log in a
relatively neat manner at the end-of-run email message.
In the case of a MinGW32 build, if a binary distribution is being made then
the build script will attempt to rejig those utilities into the GHC binary
distribution tree which is then zipped up. The rejigging is still
experimental but I hope it will ultimately automate an all-in-one Windows
binary distribution.
Cheers
Mike Thomas.
___
Glasgow-haskell-bugs mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Small JAPI binding for GHC in CVS
Hi there. Under fptools/libraries/Japi (the GHC CVS repository) please find a preliminary binding to a subset of the Japi library: http://www.japi.de/ from which site you can obtain precompiled libraries and headers for different platforms. Japi is a simple C wrapper on Java which means that either jre or java needs to be in your path, but it avoids callbacks and uses the Haskell 98 FFI so I would expect it to be easy to port to nhc98. You have to do an event loop in Haskell. The makefiles have been tested with MinGW32 GHC, but I expect you would need little effort under Linux, for example. Some examples are provided including a Fractal program, based on the C originals including the one below which will probably have mangled formatting courtesy of Outlook. Cheers Mike Thomas. --- module Main(main) where import Graphics.UI.Japi.Binding import Graphics.UI.Japi.Types import Graphics.UI.Japi.Constants import Control.Monad main = do j_setdebug 4 rv - j_start when (0 == rv) (error Could not start the JAPI server (jre or java)) frame - j_frame Frame demo j_show (Object $ fromIntegral $ frame) icon - j_loadimage ../c-examples/images/new.gif when (0 == icon) (error Could not find the icon file.) j_seticon frame icon waitForFrameAction frame return j_quit waitForFrameAction :: Frame - IO () waitForFrameAction frame = do rv - j_nextaction when (not (rv == (EventListener $ fromIntegral $ frame))) (waitForFrameAction frame) return () ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: hsc2hs broken under Win32?
Which, on reading it again is probably not related (please put it down to last day before a weeks worth of holiday inattention). I recall having a similar problem in cases where I've accidentally mixed up Cygwin and Mingw gcc/ld. If this is the same issue you probably need to put MinGW32 gcc/ld first in your path, or pass the --mno-cygwin flag to gcc. Cheers Mike Thomas. | -Original Message- | From: [EMAIL PROTECTED] | [mailto:[EMAIL PROTECTED]]On Behalf Of Mike Thomas | Sent: Tuesday, January 21, 2003 9:26 AM | To: [EMAIL PROTECTED]; [EMAIL PROTECTED] | Subject: RE: hsc2hs broken under Win32? | | | Hi Antony. | | I had this problem in a different context and got this reply from | Sigbjorn: | | http://www.haskell.org/pipermail/cvs-ghc/2002-October/015843.html | | Cheers | | Mike Thomas. | | | | -Original Message- | | From: [EMAIL PROTECTED] | | [mailto:[EMAIL PROTECTED]]On Behalf Of Antony | | Courtney | | Sent: Friday, January 17, 2003 5:51 AM | | To: [EMAIL PROTECTED] | | Subject: hsc2hs broken under Win32? | | | | | | Hi, | | | | I have also submitted this bug via SourceForge: | | | | http://sourceforge.net/tracker/index.php?func=detailaid=668705gr | | oup_id=8032atid=108032 | | | | I uploaded my minimal test program along with the SourceForge | bug report. | | | | hsc2hs seems to be broken under Win32 with ghc | | 5.04.2. If I take a simple test program and attempt to | | compile it with hsc2hs, I get the following output: | | | | $ make -f Makefile.ghc-win32 | | hsc2hs Test.hsc | | Test_hsc_make.o(.text+0x2d8):Test_hsc_make.c: | | undefined reference to `_imp___iob | | ' | | Test_hsc_make.o(.text+0x305):Test_hsc_make.c: | | undefined reference to `_imp___iob | | ' | | Test_hsc_make.o(.text+0x31b):Test_hsc_make.c: | | undefined reference to `_imp___iob | | ' | | Test_hsc_make.o(.text+0x348):Test_hsc_make.c: | | undefined reference to `_imp___iob | | ' | | Test_hsc_make.o(.text+0x373):Test_hsc_make.c: | | undefined reference to `_imp___iob | | ' | | Test_hsc_make.o(.text+0x3a0):Test_hsc_make.c: more | | undefined references to `_imp | | ___iob' follow | | collect2: ld returned 1 exit status | | make: *** [Test.hs] Error 1 | | | | If anyone has any suggestions about what's going on, I'd be | very grateful. | | | | Thanks, | | | | -antony | | | | | | -- | | Antony Courtney | | Grad. Student, Dept. of Computer Science, Yale University | | [EMAIL PROTECTED] http://www.apocalypse.org/pub/u/antony | | | | ___ | | 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 | | ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
RE: Proposal for GHC documentation
Hi all. The rewritten documentation can be translated to HTML using just a standard xsltproc tool (available for both Cygwin Linux) and XSLT DocBook stylesheet. The main advantage of XML version is that there is already developed XSLT stylesheet which generates input for Microsoft HTML Help Compiler. ... I think that this will made GHC documentation much more easy for reading and browsing. I would strongly support such a change. As an aside to you, Krasimir, I would like to say thanks for the great work you did this year on the Object-IO library which I use a lot when programming with GHC. Cheers Mike Thomas. ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: GHC Undefined
Hi Michael. The latest release candidate of Mingw binutils fixed some problems with autoimporting variables from DLL's. More details at: http://sourceforge.net/project/shownotes.php?release_id=127364 I believe that there have also been similar changes in one or two other recent MinGW32 binutils releases. Cheers Mike Thomas. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of michael vorin Sent: Thursday, December 12, 2002 8:14 AM To: [EMAIL PROTECTED] Subject: GHC Undefined Whilst I was trying to get the curses binding example in QForeign to compile - I stumbled on what I believe to be a bug. Essentialy I believe that the version of ld.exe that you have packaged up with ghc 5.04 win32 has a bug or is perhaps badly configured. ghc uses - GNU ld version 2.11.90 (20010704) (with BFD 2.11.90) which did not properly resolve external references to variables (see below). I resolved problem by using - GNU ld version 2.13, from current mingw release. my configuration GHC 5.04 Win32 running on win2K platform. What I encountered ghc -fglasgow-exts CursesTest.hs CursesTest_hsc.c Curses.hs curses_hsc.c -lpdcurses curses_hsc.o(.text+0x4):curses_hsc.c: undefined reference to `stdscr' curses_hsc.o(.text+0x10):curses_hsc.c: undefined reference to `LINES' curses_hsc.o(.text+0x1c):curses_hsc.c: undefined reference to `COLS' curses_hsc.o(.text+0x28):curses_hsc.c: undefined reference to `COLOR_PAIRS' curses_hsc.o(.text+0x34):curses_hsc.c: undefined reference to `COLORS' when I had a look at the object files and the libpdcurses.dll, the appropriate symbols were in fact defined, and in fact all functions were resolved, the above symbols represent bindings to variables declared as follows:- extern int LINES; 2. setup of a test - I setup a test (test.c attached) where I just had one external reference that I was trying to resolve. I compiled it curses\tst-linesghc tst.c -o tst.exe -lpdcurses tst.o(.text+0x4):tst.c: undefined reference to `LINES' curses\tst-linesgcc tst.c -o tst.exe -lpdcurses Info: resolving _LINES by linking to __imp__LINES (auto-import) the above should give the same result, i.e. the later result 3. fix I copied ld.exe from my mingw release (version 2.13) over ld.exe in the ghc release (version 2.11.90 ). This solved my problem 4. postmortem - why the problem ? Does this problem occur with all external variable references or is limitted to a few dll libraries, does it occur linking against static libraries ? I don't know _ Help STOP SPAM with the new MSN 8 and get 2 months FREE* http://join.msn.com/?page=features/junkmail ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: Template Haskell
Thanks Simon. If you look in the manual you'll see that it says you can only compile-time-call a function that is in a separate module. So put 'pr/gen/parse' in a separate module and you'll be fine. My fault really as I only have the raw SGML and it sends me up the wall to try and read it. The manual may not be very clear... pls help me improve it. Having said that I added a simple worked example with an example command line and checked it in. As I don't have Docbook I was unable to see what it looks like and have fingers crossed that the tags match up etc. Cheers Mike Thomas. ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Template Haskell
Hi there. Could somebody please let me know where I've gone wrong in the program below (yesterday's CVS HEAD stage 3 compiler on Windows)? - TH - printf.hs --- module Main where import Language.Haskell.THSyntax data Format = D | S | L String main = putStrLn ( $(pr Hello) ) parse :: String - [Format] parse s = [ L s ] gen :: [Format] - Expr gen [D] = [| \n - show n |] gen [S] = [| \s - s |] gen [L s] = string s pr :: String - Expr pr s = gen (parse s) - Command Line - /c/cvs/i386-unknown-mingw32/stage3/ghc/compiler/ghc-inplace -fglasgow-exts - package haskell-src printf.hs -o printf.exe - GHC output- printf.hs:7: Stage error: `pr' is bound at stage 1 but used at stage 0 In the first argument of `putStrLn', namely `($[splice](pr Hello))' In a right-hand side of function `main': putStrLn ($[splice](pr Hello)) In the definition of `main': main = putStrLn ($[splice](pr Hello)) --- Thanks Mike Thomas. ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
ghci/Template Haskell - Windows link problem
Hi there While trying to compile a Template Haskell program (and run ghci) I get the output shown below. The symbol _impmb_cur_max is in msvcrt.dll and msvcrt is present in the extra libraries list for package base. Windows XP and CVS. Cheers Mike Thomas. = $ ghc --make -fglasgow-exts -package haskell-src th.hs -o th c:\lang\ghc\bin\ghc.exe: chasing modules from: th.hs Skipping Pr ( Pr.hs, ./Pr.o ) Compiling Main ( th.hs, ./th.o ) c:/lang/ghc/HSbase_cbits.o: unknown symbol `__impmb_cur_max' Loading package base ... linking ... c:\lang\ghc\bin\ghc.exe: panic! (the `impossible' happened, GHC version 5.05): can't load package `base' Please report it as a compiler bug to [EMAIL PROTECTED], or http://sourceforge.net/projects/ghc/. miketh@ICE c:/cvs/fptools $ ghci ___ ___ _ / _ \ /\ /\/ __(_) / /_\// /_/ / / | | GHC Interactive, version 5.05, for Haskell 98. / /_\\/ __ / /___| | http://www.haskell.org/ghc/ \/\/ /_/\/|_| Type :? for help. Loading package base ... linking ... c:/lang/ghc/HSbase_cbits.o: unknown symbol `__impmb_cur_max' c:\lang\ghc\bin\ghc.exe: panic! (the `impossible' happened, GHC version 5.05): can't load package `base' Please report it as a compiler bug to [EMAIL PROTECTED], or http://sourceforge.net/projects/ghc/. ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
GLUT
Hi There. CVS ghc on Windows 2000 Pro compiling libraries/GLUT: ../../ghc/compiler/ghc-inplace -Wall -fglasgow-exts -package OpenGL -Iinclude '-#include HsGLUT.h' -cpp -DCALLCONV=stdcall -package-name GLUT -O -Rghc-timing -package ase -package OpenGL -split-o bjs-c Graphics/UI/GLUT/Window.hs -o Graphics/UI/GLUT/Window.o Graphics/UI/GLUT/Window.hs:140: No instance for (Eq Window) arising from use of `==' at Graphics/UI/GLUT/Window.hs:140 In the predicate expression: w == (Window 0) In the second argument of `($)', namely `if w == (Window 0) then Nothing else Just w' ghc: 43043828 bytes, 20 GCs, 2140648/4111904 avg/max bytes residency (3 samples), 8M in use, 0.01 INIT (0.01 elapsed), 0.52 MUT (0.58 elapsed), 0.45 GC (0.45 elapsed) :ghc make: *** [Graphics/UI/GLUT/Window.o] Error 1 Cheers Mike Thomas ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: Directory.doesDirectoryExist inconsistency
Hi all. | across those platforms up to the limits of available programmer time and | common sense. Would anyone care to remove the trailing '/' or '\' in the Win32 version of doesDirectoryExist? I'll put it on my list, but it's so much easier to write emails about the problem than to write code. Is there a deadline for 6.04.2 I need to meet? Cheers Mike Thomas. ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: Directory.doesDirectoryExist inconsistency
Hi there. That would take care of the incompatibility here, but it's a slippery slope. Just how slippery the filename slope can get is shown by Common Lisp filename/logical pathnames: http://www.cs.queensu.ca/software_docs/gnudev/gcl-ansi/gcl_1063.html#SEC1063 Should Haskell provide you with a platform-independent view of filenames and file systems? I think that if a language implementation takes the trouble to provide a cross-platform library function then that function should be consistent across those platforms up to the limits of available programmer time and common sense. For example, I think that Haskell 98 library functions should have particular care applied to them and I think that the trailing / problem should be eliminated. Allowable cross platform variations should be documented in the standard. By the same logic, I don't believe that much effort at all should be applied to reproducing cross-platform behaviour in the GHC Posix library on systems which do not support Posix. Generally I think that compilers striving to support production programming should, where possible, provide at least basic coverage of low level system specific libraries and low level programming. Such coverage in tandem with efficient higher level abstracted libraries such as ObjectIO, gives programmers lots of useful options and is a great strength of GHC. Cheers Mike Thomas. --sigbjorn - Original Message - From: Simon Peyton-Jones [EMAIL PROTECTED] To: Sigbjorn Finne [EMAIL PROTECTED]; Claus Reinke [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Tuesday, October 22, 2002 08:50 Subject: RE: Directory.doesDirectoryExist inconsistency Sigbjorn (and others interested in Win32 I/O behaviour) The fact that MS CRT differs from Unix doesn't mean that the Haskell interface should necessarily differ. The Haskell impl of doesDirectoryExist could, on Win32, trim off trailing '/' or '\', in order to make the behaviour consistent. Where it's possible to get consistent behaviour, we should strive for that. Do you agree? Simon | -Original Message- | From: Sigbjorn Finne [mailto:sof;galois.com] | Sent: 16 October 2002 15:54 | To: Claus Reinke | Cc: [EMAIL PROTECTED] | Subject: Re: Directory.doesDirectoryExist inconsistency | | This is known behaviour of the MS CRT implementation | of stat() on directories -- trailing slashes will cause it to | report ENOENT. | | Undesirable behaviour, you might (reasonably) say, but | the format of FilePaths is left system-specific by Haskell98. | | --sigbjorn | | - Original Message - | From: Claus Reinke [EMAIL PROTECTED] | To: [EMAIL PROTECTED] | Sent: Wednesday, October 16, 2002 07:21 | Subject: Directory.doesDirectoryExist inconsistency | | | I've just been chasing a portability problem, where a largish third-party | program works fine on our suns (ghc-5.02.3), but chokes under | cygwin/windows (ghc-5.04). Comes down to an inconsistency in the | handling of (trailing?) slashes in Directory.doesDirectoryExist (see | a and b below). | | ... | | ___ | 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 ___ 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: Newbie building GHC
Hi Simon.
You're the victim of my first sentence which was obfuscated by simultaneous
attempts at humour and a bad memory disclaimer - sorry - my wife always
tells me not to make up my own jokes! (Oops.)
To build yesterday's CVS HEAD (previously autoconfed) using Windows 2000,
GHC 5.04.1, and Mingw32 gcc 2.95.3-7 in the southern hemisphere 10 hours
ahead of GMT, I did the following (by memory - the details of the configure
options may be shaky):
(a) I believe that it's important to run autoconf
I agree. Note the very well hidden (previously autoconfed).
What you did may work, but I am not confident in it. For example where
are you saying where to find the (mingw) gcc that GHC should use?
Note the second line below which places the mingw bin directory (and
therefore the Mingw executables) directly in front of the Cygwin path:
| - Run the following following commands:
|
| export PATH=/cygdrive/c/lang/mingw32/bin::${PATH}
|
| make clean; ./configure --build=mingw configure.log
Having said that, specifying the C compiler by your method is better as you
never know when a shell script or tool might temporarily modify the path.
(sh and /etc/profile being a known candidate for doing this behind your
back).
Uh oh. You aren't following the instructions in Section 12.4 of the GHC
building guide!
http://haskell.cs.yale.edu/ghc/docs/latest/html/building/winbuild.html
True - they didn't change for such a long time I gave up looking at them!
(b) I've never seen this --build option for configure. What I use (as
the building guide says) is:
./configure --host=i386-unknown-mingw32 --with-gcc=/mingw/bin/gcc
If you type ./configure --help you will see:
=
System types:
--build=BUILD configure for building on BUILD [guessed]
--host=HOST cross-compile to build programs to run on HOST [BUILD]
--target=TARGET configure for building compilers for TARGET [HOST]
=
These are standard GNU configure options. Note that the triple above
cascades down from the --build option. You only need to specify
--build. --host seems to be meant for cross-compilation.
A common Mingw32 practice (not one that I recommend for casual users) is to
cross compile from Linux, and in fact I noticed recently someone was
cross-compiling from a spare four processor Sparc they had lying around
their office!
As it happens, the GHC configure is also set up to recognize the phrase
mingw32 as an argument to --build (I mistakenly put mingw above) and
canonicalises that to i386-unknown-mingw32.
In fact - I use the following script as follows for configure (after the
autoconf process):
=
$ cat ~/ghcc1
make clean;
./configure --build=mingw32 --enable-hopengl --enable-objectio --prefix=c:/l
ang/ghc --datadir=c:/lang/ghc/imports --libdir=c:/lang/ghc configure.log
=
The lesson I learnt today based on what you and Sigbjorn have to say is that
I should also add the following lines to that script:
=
find . -iname *.o -exec rm \{\} \;
find . -iname *.hi -exec rm \{\} \;
find . -iname *.p_o -exec rm \{\} \;
find . -iname *.p_hi -exec rm \{\} \;
=
At risk of stating the (now) obvious, apparently, make clean only deletes
files with those endings which correspond to already existing .hs and
.lhs files, so that a CVS update which removes source files leaves
orphaned interfaces etc around.
Do you think we should change this behaviour?
Cheers
Mike Thomas
___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Newbie building GHC
Actually...
I said in my previous reply:
Having said that, specifying the C compiler by your method is better as you
never know when a shell script or tool might temporarily modify the path.
(sh and /etc/profile being a known candidate for doing this behind your
back).
In retrospect I think that unless configure is doing something really
tricky, if you want the Mingw32 ar and ld to be picked up instead of the
Cygwin equivalents then you must have the Mingw32 bin directory in your path
ahead of the Cygwin bin directory.
You should also remove the Mingw bin make.exe as it is seriously flawed
and will not suffice to do much at all, let alone build GHC.
Cheers
Mike Thomas.
- Original Message -
From: Simon Peyton-Jones [EMAIL PROTECTED]
To: Mike Thomas [EMAIL PROTECTED];
[EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Sent: Tuesday, September 24, 2002 5:30 PM
Subject: RE: Newbie building GHC
| - Run the following following commands:
|
| export PATH=/cygdrive/c/lang/mingw32/bin::${PATH}
|
| make clean; ./configure --build=mingw configure.log
Uh oh. You aren't following the instructions in Section 12.4 of the GHC
building guide!
http://haskell.cs.yale.edu/ghc/docs/latest/html/building/winbuild.html
(a) I believe that it's important to run autoconf
(b) I've never seen this --build option for configure. What I use (as
the building guide says) is:
./configure --host=i386-unknown-mingw32 --with-gcc=/mingw/bin/gcc
You need to run configure in fptools/ghc first actually. (No need to
autoconf there.)
What you did may work, but I am not confident in it. For example where
are you saying where to find the (mingw) gcc that GHC should use?
Simon
___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Newbie building GHC
Hi again.
Thanks for the feedback.
The only way I know to make all this work is to use a straightforward
Cygwin environment for building (with absolutely no mingw
stuff in your
path) and use --with-gcc in your configure line. Other
things may work,
but you're on your own.
I think Mike has a point here - unless mingw is first in your PATH, you
get the cygwin binutils (ar, ld, maybe even as?) which could conceivably
be a problem if they behave differently from the mingw versions.
Presumably they don't, however, so we get away with it.
The reason that this worries me is that Cygwin ld links with libraries
from the Cygwin lib directory rather than the Mingw equivalent, regardless
of which gcc was used to compile the object files.
FWIW, I recently build GHC on cygwin/mingw using the instructions from
the building guide and it worked fine.
After the emails last night, I rebuilt after running the script below
(including specification of gcc) and with the Mingw32 bin directory first
in the path.
==
make clean
find . -iname *.o -exec rm \{\} \;
find . -iname *.hi -exec rm \{\} \;
find . -iname *.p_o -exec rm \{\} \;
find . -iname *.p_hi -exec rm \{\} \;
cvs -z3 update -dP
rm -f configure
autoconf; cd ghc; autoconf; cd ..
./configure --build=mingw32 \
--enable-hopengl \
--enable-objectio \
--with-gcc=c:/lang/MinGW295/bin/gcc.exe \
--prefix=c:/lang/ghc \
--datadir=c:/lang/ghc/imports \
--libdir=c:/lang/ghc \
configure.log 21
==
It went well until hslibs/win32 where a previously mentioned missing file
stopped the build as shown below - a separate problem.
Cheers
Mike Thomas.
==
.
../../ghc/compiler/ghc-inplace -cpp -fvia-C -optc-DTARGET_GHC -fglasgow-exts
-package-name
win32 -H32m -O -W -fno-warn-unused-matches -fwarn-unused-imports -package
lang-c Win32Spawn.hs -o Win32Spawn.o
Win32Spawn.hs:23:
Warning: foreign declaration uses deprecated non-standard syntax
c:\DOCUME~1\mike\LOCALS~1\Temp\ghc196.hc: In function `s678_ret':
c:\DOCUME~1\mike\LOCALS~1\Temp\ghc196.hc:449: warning: implicit declaration
of function `spawnProc'
c:/lang/MinGW295/bin/gcc.exe -mno-cygwin -O -DTARGET_GHC -I../../ghc/include
s-c WndProc.c -o WndProc.o
c:/lang/MinGW295/bin/gcc.exe -mno-cygwin -O -DTARGET_GHC -I../../ghc/include
s-c diatemp.c -o diatemp.o
c:/lang/MinGW295/bin/gcc.exe -mno-cygwin -O -DTARGET_GHC -I../../ghc/include
s-c dumpBMP.c -o dumpBMP.o
c:/lang/MinGW295/bin/gcc.exe -mno-cygwin -O -DTARGET_GHC -I../../ghc/include
s-c errors.c -o errors.o
c:/lang/MinGW295/bin/gcc.exe -mno-cygwin -O -DTARGET_GHC -I../../ghc/include
s-c finalizers.c -o finalizers.o
c:/lang/MinGW295/bin/gcc.exe -mno-cygwin -O -DTARGET_GHC -I../../ghc/include
s-c spawnProc.c -o spawnProc.o
rm -f libHSwin32.a
c:/lang/MinGW295/bin/ar clqslibHSwin32.a WndProc.o diatemp.o dumpBMP.o
errors.o finalizers.o spawnProc.o Win32Dialogue_stub.o Win32Window_stub.o
Win32Spawn.o WndProc.o diatemp.o dumpBMP.o errors.o finalizers.o spawnProc.o
c:\lang\MinGW295\bin\ar.exe: Win32Dialogue_stub.o: No such file or directory
make[2]: *** [libHSwin32.a] Error 1
make[1]: *** [all] Error 1
make[1]: Leaving directory `/cygdrive/c/cvs/fptools/hslibs'
make: *** [all] Error 1
___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Newbie building GHC
Hi Saswat and Dominic.
To build yesterday's CVS HEAD (previously autoconfed) using Windows 2000,
GHC 5.04.1, and Mingw32 gcc 2.95.3-7 in the southern hemisphere 10 hours
ahead of GMT, I did the following (by memory - the details of the configure
options may be shaky):
- Start the standard Cygwin Bash prompt
- Run the following following commands:
export PATH=/cygdrive/c/lang/mingw32/bin::${PATH}
make clean; ./configure --build=mingw configure.log
make make.log
I had build.mk in the mk directory set for a performance build and
SPLIT_OBJS=NO.
I built Happy from scratch.
This built Happy, the compiler and RTS, libraries, and some of hslibs
stopping at the Win32 library due to a missing file, the name of which
escapes me. Thinking that I had to run Green-card to generate that file, I
tried building Green-card but GHC failed to build the StdDIS module due to
an out of range index - reported separately in ghc-bugs.
The build has been a bit shaky for me since the Template Haskell changes.
Luckily I preserved a complete HEAD build from just before those changes
which runs beautifully including heap profiling and the ObjectIO library.
Maybe you should try building the STABLE branch (if you were using HEAD
previously)?
Cheers
Mike Thomas.
- Original Message -
From: Saswat Anand [EMAIL PROTECTED]
To: Simon Marlow [EMAIL PROTECTED]
Cc: Dominic Cooney [EMAIL PROTECTED];
[EMAIL PROTECTED]
Sent: Tuesday, September 24, 2002 1:04 PM
Subject: RE: Newbie building GHC
Hi
I am also facing the same problem. I tried to build a virgin tree,
but with no success as Simon PJ has pointed out.
I have attached my strace file.
Saswat
On Mon, 23 Sep 2002, Simon Marlow wrote:
I have been trying to build GHC, but the ghc.exe that gets built for
ghc-inplace always exits with Error 1. It *can* print its version
number and the help, but building anything fails. The build fails
making Adjustor.o from Adjustor.c.
I'm trying to build a cvs checkout fpconfig ghc hslibs on Win XP Pro,
bootstrapping with the provided GHC 5.04.1 binary and Happy
1.13 binary.
I mentioned this to a colleague and he said he had exactly the same
problem (ghc exits with error 1), on Windows and Linux, when building
from source tarballs and CVS. We don't normally have any problems
running the haskell.org GHC binaries.
Can any of you suggest what we might be doing wrong? We are in the
southern hemisphere, so our electrons may be orbiting backwards.
:-) I've never seen this myself, I'm afraid. If you have a Linux build
which behaves in the same way, could you try stracing it (i.e. prepend
'strace' to the command which fails) and send us the output?
Cheers,
Simon
___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: bug with profiling things with strange filename
Hi Hal. 5.04 profiled executables (-prof -auto-all) on Windows just crash on takeoff with or without a dot in their name (ie even without a .exe extension). This is substantially different to the behaviour of HEAD a few days before release of 5.04, which only crashed when fed heap profiling arguments. Cheers Mike Thomas - nfib.exe caused an Access Violation at location 00451047 in module nfib.exe Writing to location . Registers: eax=00ac043c ebx=00457a40 ecx= edx=00ac0498 esi=004510a8 edi=00ac10a8 eip=00451047 esp=0022de3c ebp=00abf3cd iopl=0 nv up ei pl nz na pe nc cs=001b ss=0023 ds=0023 es= fs=0038 gs= efl=0202 Call stack: 00451047 nfib.exe:00451047 __gmpn_divrem_2 divrem_2.c:151 mp_limb_t __gmpn_divrem_2( mp_ptr qp = , mp_size_t qxn = 671105912, mp_ptr np = , mp_size_t nsize = -201326592, mp_srcptr dp = ) 9800AC10 - Original Message - From: Hal Daume III [EMAIL PROTECTED] To: GHC Users Mailing List [EMAIL PROTECTED] Sent: Friday, July 26, 2002 5:02 AM Subject: bug with profiling things with strange filename if you compile a program -p -auto-all with ghc and the name you give the exectuable contains iether a . or a - (and possibly other things) it will core dump when executed (at least on sparc solaris), or so it seems, under 5.04. has anyone else had this problem? -- Hal Daume III Computer science is no more about computers| [EMAIL PROTECTED] than astronomy is about telescopes. -Dijkstra | www.isi.edu/~hdaume ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC 5.03 CVS NT2000 Mingw32 - Possible profiling problem in rts/GC.c (or in gmp?)
Title: Message
Hi Simon.
No worries - I appreciate that it is an
enormous job for you guys.
As a matter of interest, would the fact that my
computer has an AMD K6 CPU rather than an Intel CPU be
relevant?
Cheers
Mike Thomas.
- Original Message -
From:
Simon
Peyton-Jones
To: Mike Thomas ; [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Sent: Friday, June 28, 2002 11:04
PM
Subject: RE: GHC 5.03 CVS NT2000 Mingw32
- Possible profiling problem in rts/GC.c (or in gmp?)
Mike
Your
message has been sitting in my inbox for a while.
GHC-compiled programs should never crash, but the combination of
profiling, object I/O, call backs, and the win32 platform makes a rather
complicated context for bug hunting.
Simon M is the profiling and run-time system expert, and he's not well
this week. Furthermore, he'd tied up trying to get 5.04 out of the
door. So I'm afraid you may not get much help from us for a
while.If anyone else can help, and if you find what's wrong, that
would be great. If you are still stuck on thisin a few week's
time, come back to us.
Simon
-Original Message-From: Mike Thomas
[mailto:[EMAIL PROTECTED]] Sent: 18 June 2002
14:38To: [EMAIL PROTECTED]Subject: GHC
5.03 CVS NT2000 Mingw32 - Possible profiling problem in rts/GC.c (or in
gmp?)
Hi all.
I have a problemprofiling the
"hslibs/object-io/Examples/Bounce" example program.
When built with GHC 5.03 CVS (which was in turn
built with 5.02.3) using the default compiler and RTS Makefile settings, the
example runs, but roughly (pauses for GC and slower than the pure Clean
version).
To find the cause I tried building with
profiling turned on:
ghc Main.hs --make -package objectio -prof
-auto-all -o Bounce.exe -lopcodes
When run, the resulting executable crashes with
a requestor in:
__gmpn_divrem_2
divrem_2.c:151
Usingan RTS built with the default
debugging options found in "mk/built.mk.sample", I catch the exception with
DrMingw and get the stack dump shown in DEBUGGER OUT ONE (below) - an access
violation in line 3820 of "rts/GC.c"
(get_itbl(frame)-type).
Ithen inserted a "#undef DEBUG" in
"rts/GC.c".
This just pushes the crash to the next
reference to the sameconstruct - line 3841. See DEBUGGER OUT TWO
- also below. This time there is also a reference to the same gmp
routine as above, which for some reason is not reported in DEBUGGER OUT
ONE.
Any help on interpreting and squishing this one
gratefully accepted.
Cheers
Mike Thomas.
=
DEBUGGER OUT ONE - DEBUG defined in GC.c
=
Bounce.exe caused an Access Violation at
location 0056349d in module Bounce.exe Reading from location
000d.
Registers:eax=101c031c ebx=101c0400
ecx=000d edx=000d esi=101c031c edi=101c23e8eip=0056349d
esp=0022dd88 ebp=0022ddd0
iopl=0 nv up ei pl zr na po
nccs=001b ss=0023 ds=0023 es=0023 fs=0038
gs=
efl=0246
Call stack:0056349D
Bounce.exe:0056349D threadSqueezeStack
GC.c:3820... frame,
prev_frame);
}) switch (get_itbl(frame)-type)
{ case
UPDATE_FRAME:upd_frames++;...
0056378B Bounce.exe:0056378B
threadPaused GC.c:4054...{ if (
RtsFlags.GcFlags.squeezeUpdFrames == rtsTrue
) threadSqueezeStack(tso);// does black
holing too else
threadLazyBlackHole(tso);...
00554592 Bounce.exe:00554592
suspendThread Schedule.c:1532...
threadPaused(cap-r.rCurrentTSO);
cap-r.rCurrentTSO-link = suspended_ccalling_threads;
suspended_ccalling_threads =
cap-r.rCurrentTSO;...
004795A9
Bounce.exe:004795A900A749D024448904
=
DEBUGGER OUTTWO - DEBUG UNdefined in GC.c
=
Bounce.exe caused an Access Violation at location 00684c7d in module
Bounce.exe Reading from location .
Registers:eax=101bf3f4 ebx=006ab3d0 ecx=101bf3d8 edx=11c5d010
esi=006a15fc edi=eip=00684c7d esp=0022dd98 ebp=0022ddd0
iopl=0 nv up ei ng nz na po
cycs=001b ss=0023 ds=0023 es=0023 fs=0038
gs=
efl=0287
Call stack:00684C7D Bounce.exe:00684C7D
threadSqueezeStack GC.c:3841...
}#endif if
(get_itbl(frame)-type == UPDATE_FRAME
frame-updatee-header.info == stg_BLACKHOLE_info)
{
break;...
00684E8B Bounce.exe:00684E8B threadPaused
GC.c:4054...{ if (
RtsFlags.GcFlags.squeezeUpdFrames == rtsTrue
)
Re: GHC and Win32 API - help wanted
Hi Claus. Moral support but little else below As noone has responded so far, I have to conclude that this is quite an infrequently used package.. - noone using ghc + win32 API? - noone using ghc + hgl on windows? Although I feel the Win32 package is important I am finding it impossible to build GHC from CVS in order to debug my main project which, (unfortunately for your own interest in HGL), uses ObjectIO, so I felt that I was unable to offer anything coherent to you. I can't even get as far as the Win32 library while building GHC from scratch at the moment. We suspect that Alastairs fixes may still leave some issues with concurrency / potentially blocking threads / ffi (at least in GHC's default configuration on windows), but we'd like to see just how far the improvements go, as the next stable release of GHC is imminent. I suspect that the problems I had with profiling the ObjectIO library recently reported on the bugs list are also caused by thread issues, but I can't test this hypothesis due to the problems outlined above. * Could anyone with cvs/fptools/makefile-expertise lend me a hand * if I try again to build only hslibs/win32 from cvs? Or is it * completely unreasonable to expect this to work? The fresh greencard output seems to depend on parts of the ffi syntax that weren't supported in ghc-5.02.2, so I'd have to try with ghc-5.03.20020208 (the latest windows installer snapshot). When I tried building CVS GHC with this package I got a compiler which would not work. But if I try setting GHC_PKG_INPLACE today, there's absolutely no change! The setting in fptools/mk/build.mk seems to be ignored now? Yes, I haven't found a way of getting around this problem myself other than hard wiring the compiler (possibly in target.mk from memory?) Any helpful souls out there, who could lead me through the jungle of bewildering makefiles tomorrow (target date for feature completeness for the next release)? Sorry not to be of more help. If not, I'll just drop the issue (those who reported the problem earlier seem to have given up? and Simon Thompson, who last ran into it, does now get acceptable performance from Hugs/HGL for his app). Lost, Claus Even more lost, Mike Thomas. ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Ix{Int}.index: Index (28671) out of range ((4,450))
FYI, On WinNT 2000 Mingw32, CVS HEAD
build
../../ghc/utils/ghc-pkg/ghc-pkg-inplace -f
../../ghc/driver/package.conf --update-package
base.conf.installedReading package info from stdin... done.Expanding
embedded variables...done.warning: can't find GHCi lib
`HSbase1.o'warning: can't find GHCi lib `HSbase2.o'warning: can't find
GHCi lib `HSbase3.o'Saving old package config file... done.Writing new
package config file... done.../../ghc/compiler/ghc-inplace -lbfd -liberty
-fglasgow-exts -cpp -Iinclude -Icbits/regex -funbox-strict-fields
-package-name base -dcore-lint -O -W -fno-warn-unused-matches
-fwarn-unused-imports -keep-hc-files -c
GHC/Arr.lhs -o GHC/Arr.oghc.exe: panic! (the `impossible' happened, GHC
version 5.03): Ix{Int}.index:
Index (28671) out of range ((4,450))
Please report it as a compiler bug to [EMAIL PROTECTED],or
http://sourceforge.net/projects/ghc/.
make: *** [GHC/Arr.o] Error
1
Re: stgSyn/CoreToStg.lhs:1112: Couldn't match `#' against `*'
MessageHi Simon. maybe you need to rebuild the compiler you are compiling *with*? That's exactly what I'm trying to do with the latest CVS Head, so I assume you mean to try switching back to the Glasgow team's 5.02 or 5.03 releases to build. As the compiler I am using was built with the GHC team 5.03 snapshot and using CVS head of about 26 April, I guess I'll try the most recent GHC 5.02 this time. As an aside, building GHC from scratch on a 300 Mhz 192 MB PC takes all day unfortunately. I am also accumulating trivial but numerous changes to the HDirect tree to get it to build with 5.03, so I wouild like to get CVS write access to fold that stuff back in (if you trust me after the above fiasco!) Thanks Mike Thomas ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
stgSyn/CoreToStg.lhs:1112: Couldn't match `#' against `*'
Hi there.
While building current CVS GHCunder Windows
witha CVS version of GHCfrom 26 April I get the error at the end of
this message (short extract here):
--
stgSyn/CoreToStg.lhs:1112:
Couldn't match `#' against `*'
When matching types `GHC.Prim.Int#' and `a'
Expected type: GHC.Prim.Int#
Inferred type: a
In the application `error ("cafRefs " ++ (showSDoc (ppr
id)))'
--
I modified the file to "import Err" and passed a "-i" command line option
to get the compiler to see "err.hi-boot"in "libraries/base/GHC", but now I
get (details at end of the email):
--stgSyn/CoreToStg.lhs:18:
Something is amiss; requested module name Err differs from name found in
theinterface file GHC.Err
--
Is there an easy way around this (bootstrap?) problem?
I would also like some advice about how to interpret the initial error
message about "#" and "*" if someone can point me in the right direction in the
documentation.
Cheers
Mike Thomas
--
/cygdrive/f/lang/ghc/ghcnl/bin/ghc -DGHCI -cpp
-fglasgow-exts -Rghc-timing -I. -IcodeGen -InativeGen -Iparser
-iutils:basicTypes:types:hsSyn:prelude:rename:typecheck:deSugar:coreSyn:specialise:simplCore:stranal:stgSyn:simplStg:codeGen:absCSyn:main:profiling:parser:usageSP:cprAnalysis:compMan:ndpFlatten:nativeGen:ghci
-package concurrent -package util -recomp -Rghc-timing -H16M '-#include
"hschooks.h"' -O -c stgSyn/CoreToStg.lhs -o
stgSyn/CoreToStg.o
stgSyn/CoreToStg.lhs:1112:
Couldn't match `#' against `*'
When matching types `GHC.Prim.Int#' and `a'
Expected type: GHC.Prim.Int#
Inferred type: a
In the application `error ("cafRefs " ++ (showSDoc (ppr
id)))'
ghc: 147694784 bytes, 78 GCs, 6234233/15873980 avg/max bytes
residency (5 samples), 30M in use, 0.02 INIT (0.02 elapsed), 11.42 MUT (12.32
elapsed), 8.20 GC (8.37 elapsed) :ghc
make[2]: *** [stgSyn/CoreToStg.o] Error 1make[1]: *** [all] Error
1make[1]: Leaving directory `/e/cvs/fptools/ghc'make: *** [all] Error
1
/cygdrive/f/lang/ghc/ghcnl/bin/ghc -DGHCI -cpp -fglasgow-exts -Rghc-timing
-I. -IcodeGen -InativeGen -Iparser -i"e:/cvs/fptools/libraries/base/GHC"
-iutils:basicTypes:types:hsSyn:prelude:rename:typecheck:deSugar:coreSyn:specialise:simplCore:stranal:stgSyn:simplStg:codeGen:absCSyn:main:profiling:parser:usageSP:cprAnalysis:compMan:ndpFlatten:nativeGen:ghci
-package concurrent -package util -recomp-Rghc-timing -H16M '-#include
"hschooks.h"' -O -c stgSyn/CoreToStg.lhs -o
stgSyn/CoreToStg.o
stgSyn/CoreToStg.lhs:18: Something is amiss;
requested module name Err differs from name found in theinterface file
GHC.Errghc: 28041516 bytes, 8 GCs, 1120992/2226000 avg/max bytes
residency (2 samples), 17M in use, 0.02 INIT (0.03 elapsed), 1.55 MUT (2.00
elapsed), 0.76 GC (0.77elapsed) :ghcmake: ***
[stgSyn/CoreToStg.o] Error 1
Re: Matrix library in Haskell
Hi Jan.
I recently spent some time researching precisely this topic.
Unfortunately I don't have the exact references at hand but two key starting
points are TR433 by David Wise et al and Chris Angus Numerical Software
DEvelopment with Functional Languages.
The TR433 report has code written in Gofer which I just yesterday finished
converting to Haskell 98. (That is, I compiled it but I have not yet tested
it.) It is attached as a starting point.
Cheers
Mike Thomas.
- Original Message -
From: Jan Kybic [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Tuesday, April 23, 2002 9:33 PM
Subject: Matrix library in Haskell
Hello,
I am just discovering Haskell, so sorry if this is not the
right place to ask. I want to use it for some numerical
calculations. I need something higher level than C++ and faster than
Python or Matlab and from the initial experiments it seems that
Haskell could be the right choice. My question is: Is there any
matrix/vector library available with common operations (dot products,
matrix products, linear system solution etc.) ? I could not find any.
I am including her my first try on such a library, in case it might be
useful for somebody. However, I am not perfectly happy with the
design. In particular I would like to define MatrixClass and
VectorClass so that applying a getRow operation on a matrix instance
would yield automatically the correct instance of the VectorClass, but
I do not know how to express this interdependency, so for the moment I
have dropped the classes.
Yours,
Jan
--
-
Jan Kybic [EMAIL PROTECTED] Robotvis, INRIA, Sophia-Antipolis, France
or [EMAIL PROTECTED],tel. work +33 492 38 7589, fax 7845
http://www-sop.inria.fr/robotvis/personnel/Jan.Kybic/
-- Module implementing vectors, matrices, and operations on them
-- it uses the multiparameter class extension
--
-- $Id: LinearAlgebra.hs,v 1.4 2002/04/22 11:44:41 jkybic Exp $
-- Jan Kybic, April 2002
module LinearAlgebra where
import Array
import Complex
import Observe
-- now define the concrete vector and array implementations
-- TODO: This could be accelerated using IArray/ UArray
-- TODO: Make it a proper instance of Show
newtype ArrayVectorType a = ArrayVector (Array Int a) deriving Show
newtype ArrayMatrixType a = ArrayMatrix (Array (Int,Int) a) deriving Show
listToVec l = ArrayVector (array (0,uplim) $ zip [0..uplim] l) where
uplim = (length l) -1
vecToList (ArrayVector v) = [ v!i | i - indices v ]
dot (ArrayVector a) (ArrayVector b) = sum [ a!i * b!i | i - indices a ]
norm2 a = dot a a
norm a = sqrt (norm2 a)
(!@) (ArrayVector v) i = v!i
sizeV (ArrayVector v) = rangeSize $ bounds v
indicesV v= [0..(sizeV v - 1)]
scaleV (ArrayVector a) s = ArrayVector ( fmap (\x - s * x) a )
(+@) a b = listToVec [ a!@i + b!@i | i - indicesV a ]
(-@) a b = listToVec [ a!@i - b!@i | i - indicesV a ]
-- matrix operations
(!@@) (ArrayMatrix m) (i,j) = m!(i,j)
listToMat l =
let { bnds=((0,0),(m,n)) ; m=length l -1 ; n= length (head l) -1}
in ArrayMatrix ( array bnds
[ ((i,j),(l!!i)!!j) | (i,j) - range bnds ] )
matToList a =
[ [ a !@@ (i,j) | j - range $ cbounds a ] | i - range $ rbounds a ]
boundsM (ArrayMatrix a) = bounds a
rbounds m = let z=boundsM m in (fst(fst z),fst(snd z))
cbounds m = let z=boundsM m in (snd(fst z),snd(snd z))
nrows = rangeSize . rbounds
ncols = rangeSize . cbounds
getRow a i = -- extract row i as vector
listToVec [ a!@@(i,j) | j - range $ cbounds a ]
getCol a j = -- extract column j as vector
listToVec [ a!@@(i,j) | i - range $ cbounds a ]
showMat a = [ ++ concat
[ showVec (getRow a i) ++|
i - range (rbounds a) ] ++ ]
scaleMat (ArrayMatrix a) s = ArrayMatrix ( fmap (\x - s * x) a )
matMult a b =
let bnds = transTup (rbounds a,cbounds b) in
ArrayMatrix (array bnds [ ((i,j), (getRow a i) `dot` getCol b j) |
(i,j) - range bnds ])
idMat n = -- create an identity matrix
let bnds=((0,0),(n-1,n-1)) in
ArrayMatrix (accumArray (+) 0.0 bnds
[ ((i,i),1.0) | i - [0..n-1] ])
-- cross takes two vectors of length three and calculates their cross
product
-- uncomment the run-time checks if you prefer safety over speed
-- the signature is a little limiting to avoid uncertainity of the
resulting
-- vector
cross a b
--| or [ sizeV a /=3 , sizeV b /=3 ] =
-- error Cross product needs length 3 vectors
--| otherwise
= listToVec [ a !@ 1 * b !@ 2 - a !@ 2 * b !@ 1,
- a !@ 0 * b !@ 2 + a !@ 2 * b !@ 0,
a !@ 0 * b !@ 1 - a !@ 1 * b !@ 0 ]
vangle a b = acos (cosvangle a b) -- angle between two vectors
cosvangle' a b = -- the cos of an angle between two vectors
let mag= sqrt
Re: how to call Fortran Procedures in Haskell Program?
Hi there. Does anybody know how to call Fortran procedures in Haskell program? I tried Green Card, but seems it only works with C codes. Sigbjorn Finne posted a way of doing this a while back, possibly on this list, maybe the GHC one. He used the FFI and a simple squaring function. Below is an extension using an integer array. Note that I've had to double the array size. $ g77 -c atest.f $ ghc -fglasgow-exts main.hs -o main.exe $ ./main [1,3,0,0,2,4,0,0] If you go any further, please let me know as I want to interface to LAPACK. Cheers Mike Thomas. module Main where import Ptr import Storable import MarshalArray import MarshalUtils import MarshalAlloc foreign import atest_ unsafe atest_ :: Ptr Int - Ptr Int - IO Int atest :: Int - IO [Int] atest x = withObject x $ \ ptr_x - allocaArray x $ \ ptr_a - do atest_ ptr_x ptr_a peekArray (x*2) ptr_a main = atest 4 = print --square :: Int - IO Int --square x = -- withObject x $ \ ptr_x - -- alloca $ \ ptr_res - do --square_ ptr_x ptr_res --peek ptr_res SUBROUTINE ATEST(N,M) DIMENSION M(N,N) M(1,1)=1 M(1,2)=2 M(2,1)=3 M(2,2)=4 RETURN END ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Uncertain if this is a bug in GHC
Hi there. I am uncertain if the error message below from the code further below is a bug or not. Putting a space between the -- and the | parses without error: - $ ghc -c test.hs test.hs:4: parse error on input `=' - module Test where test a | a 1 = 1 --| a 1 = 1 | a = 1 = 0 ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Jan Skibinski's numeric-quest code
Hi there. Does anyone know where to get Jan's Haskell math/physics Haskell examples from since www.numeric-quest.com went down? An open-source LU matrix factorisation function would also be handy. Cheers Mike Thomas. ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
HDIRECT/FFI - C enums
Hi all. HDirect can generate code as follows: data CONST_DDWAITVBFLAGS = DDWAITVB_BLOCKBEGIN | DDWAITVB_BLOCKBEGINEVENT | DDWAITVB_BLOCKEND instance Prelude.Enum (CONST_DDWAITVBFLAGS) where fromEnum v = case v of DDWAITVB_BLOCKBEGIN - 1 DDWAITVB_BLOCKBEGINEVENT - 2 DDWAITVB_BLOCKEND - 4 toEnum v = case v of 1 - DDWAITVB_BLOCKBEGIN 2 - DDWAITVB_BLOCKBEGINEVENT 4 - DDWAITVB_BLOCKEND _ - Prelude.error unmarshallCONST_DDWAITVBFLAGS: illegal enum value Unfortunately, if you want to interface to a C function which takes a combination of flags added together in a specific argument eg (C): bar ( DDWAITVB_BLOCKBEGIN + DDWAITVB_BLOCKBEGINEVENT ); (Haskell) bar (toEnum (fromEnum DDWAITVB_BLOCKBEGIN) + (fromEnum DDWAITVB_BLOCKBEGINEVENT )) the toEnum function can't deal with the comnbination - it generates a run-time error. Is there a simple way to deal with this situation (the need to associate symbols with specific values, while retaining the ability to lump the values together in a manner reflecting the underlying C semantics)? Should there be another FFI type CEnum? Should the Haskell Enum type be operable with +//| or whatever? Merry Christmas Mike Thomas. ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
HDirect - Make install on Win32
Hi there. Trivial comments about things that can make builds smoother: Make install in CVS HDirect doesn't copy WideString.hs and WideString.hi to the target directory. It copies the *.hi files to share rather than imports/com. It copies lib*.a to lib rather than ghc/ghc-5.02. Cheers Mike Thomas. ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: No type lib generated by hdirect
Hi Patrick. This is probably because you need to build HDirect in two stages - once without typelibrary support, and once with. Here is the process I used to build HDirect 0.17 with ghc 4.08 under NT (much is probably irrelevant as I think some of these problems have been sorted by Sigbjorne): Building HDIrect 0.17 - Uninstall previous versions of HDirect including lib/imports/com and associated libraries, which don't work very well with GHC 4.08.2. - Get the source from the HDirect web site and untar it somewhere. - You may need to edit lib/WideStringSrc.c if you use the latest Cygwin distribution to remove a clashing definition and declaration of wcslen(). - Build per the instructions in the INSTALL file. - This gives you a bare bones ihc.exe which cannot handle type libraries. - Install the freshly built lib/*.hi files in a new ghc lib/imports/com directory and also the libraries (libHScom.a, libhdirect.a) into ghc's lib directory. - Do make clean, deleting src/ihc.exe by hand. - Set SUPPORT_TYPELIBS=YES in src/Makefile - make boot, make, then make lib as before. - You now have version 0.17 of HDirect for Windows. Regards Mike Thomas. - Original Message - From: Lehti, Patrick [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, October 10, 2001 7:47 PM Subject: No type lib generated by hdirect I am trying to build a Haskell COM component with HDirect (from http://www.galconn.com/~sof/hdirect-0.18-src.tar.gz) and ghc 5.02. I have problems generating the type library: it is simply not created. Even the comserv example is not working because of the same problem. Could that be a bug in that HDirect version? Patrick ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
BUGS (2): Win32 ghc and Win98
Hi Reuben. Two bugs for you: BUG 1: Under Windows 98, ghc fails because of a gcc path problem - can't find as etc. FIX 1: This is caused by a particular release of the standalone mingw32 gcc which changed the default path separator and broke the package under W98 and some of the newer versions of Windows. I fixed this by replacing gcc.exe in your distribution with one from the latest mingw32 standalone release on Sourceforge. Better, of course, to replace the whole lot with the latest release. BUG 2: Under Windows 98 Sigbjorn's example Win32 hello world program displays but then hangs when the window close icon is clicked. Works OK under NT, and can be closed under Windows 98 by ^C in the terminal window. NOFIX 2: Unfortunately I haven't got around to working on this one yet. Cheers Mike Thomas. ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
HDirect CVS
Hi again. Re a report I filed about a week ago, I got around to reading the manula and realised that the Makefile for HDirect lib should probably have a change similar to the one below in order to make the COM library interface files believe that they are in package Com rather than package Main. $ cvs diff Makefile Index: Makefile === RCS file: /cvs/fptools/hdirect/lib/Makefile,v retrieving revision 1.49 diff -r1.49 Makefile 153a154 HC_OPTS += -package-name Com Cheers Mike Thomas. ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: HDirect CVS
Woops - make that a lower case package name com instead of Com! HC_OPTS += -package-name com - Original Message - From: Mike Thomas [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, August 08, 2001 6:18 PM Subject: HDirect CVS Hi again. Re a report I filed about a week ago, I got around to reading the manula and realised that the Makefile for HDirect lib should probably have a change similar to the one below in order to make the COM library interface files believe that they are in package Com rather than package Main. $ cvs diff Makefile Index: Makefile === RCS file: /cvs/fptools/hdirect/lib/Makefile,v retrieving revision 1.49 diff -r1.49 Makefile 153a154 HC_OPTS += -package-name Com Cheers Mike Thomas. ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: Greencard CVS - ErrorHook.c
Hi Reuben. The CVS edition of Greencard has a file src/ErrorHook.c which causes a linker error about _impure_ptr under Win32 with the latest install-shield ghc. That suggests that the file has been compiled with the wrong GCC options compared with the rest of the code, e.g. perhaps without -mno-cygwin. You're right thanks. Here is another overwhelmingly massive patch for the makefile in greencard/src which fixes the link error and the __GLASGOW_HASKELL__ macro definition problem under Mingw/Win32: - Index: src/Makefile === RCS file: /cvs/fptools/green-card/src/Makefile,v retrieving revision 1.29 diff -r1.29 Makefile 41c41 $(CC) $(CC_OPTS) -c $ -o $@ --- $(HC) $(HC_OPTS) -c $ -o $@ 43a44 - Cheers Mike Thomas. ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Greencard CVS - ErrorHook.c
Hi there. I hope all is well in ghc land. The CVS edition of Greencard has a file src/ErrorHook.c which causes a linker error about _impure_ptr under Win32 with the latest install-shield ghc. Commenting out the contents of that file seems to cause no problems so I infer that the file is no longer required for Greencard and can be removed from the repository. Also, the file had a line: #if __GLASGOW_HASKELL__ = 303 which seems to evaluate to false under GHC 5.01 (Win32), so I assume that this macro is no-longer defined or is incorrectly set wherever such things are defined in ghc. Cheers Mike Thomas. ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: POLL: GC options
Hi Simon. Issue 1: should the maximum heap size be unbounded by default? Currently the maximum heap size is bounded at 64M. Arguments for: this stops programs with a space leak eating all your swap space. Arguments against: it's annoying to have to raise the limit when you legitimately need more space. Options: Remove the default limit altogether - because you don't always know how much data a temporo-spatially remote end user of a finished product might need to use. (any others?) with the option to set a limit during debugging in the event that a space leak is beginning to be annoying and troublesome to find during development. Issue 2: Should -M be renamed to -H, and -H renamed to something else? The argument for this change is that GHC's -M option is closer to the traditional meaning of -H. I suggest remove -H and -M to avoid legacy semantic confusion and introduce something like --minimum-heap (-Hmin) and --maximum-heap (-Hmax) to get away from the unintuitive M. Issue 3: (suggestion from Julian S.) Perhaps there should be two options to specify optimise for memory use or optimise for performance, which have the effect of setting the defaults for various GC options to appropriate values. Optimising for memory use might enable the compacting collector all the time, for instance. Optimising for performance is hard - we may be able to change some of the defaults to trade space for time, but it's unlikely to be entirely reliable (eg. turning on the compacting collector sometimes improves performance, sometimes reduces it). Sounds sensible. How about: * Renaming current -M to -H, and current -H to -HS. Don't like this because it's not intuitive and could cause legacy mixup problems. * Fixing up the sizing calculations a bit so that the max heap size is more closely observed. Depends on time cost and perceived run-time GC activity - anything which minimises runtime pauses is best. Also having an auto-fallback to compacting collection when heap gets full. Overall aim is to reduce, ideally to zero, the number of flags users have to give to the RTS in order to get reasonable performance yet efficient use of memory. People simply won't use the compacting collector if you have to ask for it specially. Agree with all of this paragraph. Cheers Mike Thomas. ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Hdirect
Hi there. I get the impression someone is working on this stuff from the changes in CVS so you probably know about these problems, but just in case (and to prove that it is all worthwhile, for you to do this stuff), here they are: Using the latest Win32 GHC (thanks to Reuben for the ongoing work) and CVS source for HDirect: - Trying to build Hdirect straight from CVS has a number of dependency problems. I find I have to do several iterations of make and make boot and make lib. (Happy likewise has a crossdependency when bootstrapping without installing a binary copy first) - The dependency analysis seems to fail for IDLUtils.lhs - I have to do a make IDLUtils.hi - You have to build ihc.exe by bootstrapping without com first. - make clean does not delete src/ihc.exe - the com interface files seem to think they are in package main eg: __interface Main PointerPrim 1 501 where __export PointerPrim finalFreeMemory finalNoFree primAllocFrame primAllocMemory primFinalise primFreeBSTR primFreeMemory primNoFree; import Prelude :: 1; import PrelBase ! :: 1; import PrelWord :: 1; import PrelIOBase :: 1; and so at build time in the comcli example: -- miketh@NASTURTIUM //e/cvs/ghc/hdirect/examples/comcli $ make /cygdrive/e/ghc/ghc-5.01/bin/ghc -fglasgow-exts -package com -fno-warn-missing-m ethods -O-c Quartz.hs -o Quartz.o Quartz.hs:9: Module `Automation' is located in package `com' but its interface file claims it is part of package `Main' Quartz.hs:13: Module `Com' is located in package `com' but its interface file claims it is part of package `Main' make: *** [Quartz.o] Error 1 -- - various minor source problems: Index: lib/ComDll.lhs === RCS file: /cvs/fptools/hdirect/lib/ComDll.lhs,v retrieving revision 1.16 diff -r1.16 ComDll.lhs 39c39 import Foreign --- import Foreign hiding ( Ptr ) Index: lib/ComServ.lhs === RCS file: /cvs/fptools/hdirect/lib/ComServ.lhs,v retrieving revision 1.16 diff -r1.16 ComServ.lhs 88c88 import Foreign --- import Foreign hiding ( Ptr ) Index: lib/autoPrim.h === RCS file: /cvs/fptools/hdirect/lib/autoPrim.h,v retrieving revision 1.10 diff -r1.10 autoPrim.h 100c100 #ifdef __GNUC__ --- #if defined(__GNUC__) ! defined(__MINGW32__) Index: src/Makefile === RCS file: /cvs/fptools/hdirect/src/Makefile,v retrieving revision 1.57 diff -r1.57 Makefile 52c52 --- SUPPORT_TYPELIBS = YES Index: src/TLBWriter.lhs === RCS file: /cvs/fptools/hdirect/src/TLBWriter.lhs,v retrieving revision 1.23 diff -r1.23 TLBWriter.lhs 36c36 writeTLB :: [String] - [Decl] - IO () --- --writeTLB :: [String] - [Decl] - IO () 38c38 writeTLB _ _ = ioError (userError (writeTLB: type library writer code not com piled in)) --- --writeTLB _ _ = ioError (userError (writeTLB: type library writer code not c ompiled in)) Cheers (and as usual thanks for the good work) Mike Thomas ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
CVS HDirect with GHC5.00 on WinNT
Hi there.
Using GHC 5.00 (dodgy self made Mingw32 standalone version) on Windows NT to
compile HDirect as updated today (Thursday 28 June 2001) from CVS I get the
error message below.
Cheers
Mike Thomas.
../src/ihc -fno-qualified-names -fno-imports -fno-export-lists -fout-point
ers-
are-not-refs -c ComPrim.idl -o ComPrim.hs
/usr/local/bin/ghc -cpp -DBEGIN_GHC_ONLY='-}' -DEND_GHC_ONLY='{-' -DBEGIN_
NOT_
FOR_GHC='{-' -DEND_NOT_FOR_GHC='-}' -DELSE_FOR_GHC='-}-}' -DBEGIN_FOR_GHC_4
_08_
AND_LATER='-}' -DEND_FOR_GHC_4_08_AND_LATER='{-' -DBEGIN_NOT_FOR_GHC_4_08_AN
D_LA
TER='{-' -DEND_NOT_FOR_GHC_4_08_AND_LATER='-}' -static -fglasgow-exts -fno-
prun
e-tydecls -recomp -fvia-C -package lang -c ComPrim.hs -o ComPrim.o
ComPrim.hs:43:
Warning: Variable `foreignObjToAddr' is deprecated:
ForeignObj has been replaced by ForeignPtr
ComPrim.hs:70:
Couldn't match `Exception' against `Maybe FilePath - IOException'
Expected type: Exception
Inferred type: Maybe FilePath - IOException
Probable cause: `IOError' is applied to too few arguments in the call
(IOError Nothing (ComError (toInt hr)) msg)
In the first argument of `ioError', namely
`(IOError Nothing (ComError (toInt hr)) msg)'
make[1]: *** [ComPrim.o] Error 1
make: *** [all] Error 1
___
Glasgow-haskell-bugs mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: a cygwin binary package of ghc-5.00.x
Hi. Do anybody have one? I failed to recompile it with ghc 4.08.x. Thank you in advance Alexander I have one, which uses the Mingw standalone GCC compiler for Windows. It seems to be capable of compiling itself. Problems: 1. It is not in an installer - you would have to hand patch the package file and install by hand. 2. It is not supported by anyone and is non-standard in the way it uses Mingw32. 3. The Win32 demo program hangs on exit under Win98 (works OK on NT4 though). 4. I haven't bootstrapped GHCi, yet (maybe by next week). 5. It is only GHC 5.00, not 5.00.1. (maybe next week). 6. You would have to install Mingw32 (and maybe Cygwin for it's shell) yourself. 7. It is very big, mainly because of the profiled libraries. 8. I don't have an FTP site to put it. 9. It doesn't do dynamic libraries, only static. etc. Unless you're desperate, I suggest waiting for the official release. Cheers Mike Thomas. ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Hard earned hints for using Win32 GHC 4.08.2 and HDirect.
Hi all. I thought I might share some hints on making HDirect work with GHC 4.08.2. Installing and checking GHC: - Get the installer from the GHC downloads page, do the installation per the instructions there, including Cygwin etc. - Remove the digit "1" from the bottom of lib/imports/win32/Win32.hi - Remove old .hi files from any program source directories you may have. - To test, try compiling the Windows hello.lhs example using the command line "ghc hello.lhs -o hello.exe -package win32" and run hello.exe. - If you get linker errors about "importtimezone_dll" from time.o, you need to add the line: push(@SysLibrary, '-lcrtdll') if ($TargetPlatform =~ /-(mingw32|cygwin32)$/); below the line: push(@SysLibrary, '-lwsock32') if ($TargetPlatform =~ /-(mingw32|cygwin32)$/); in your "bin/ghc" driver script. This is because the distribution is built with an old version of Cygwin GCC which links against crtdll.dll rather than msvcrt.dll when -mno-cygwin is set on the command line (GHC uses mingw32). By doing this, spare symbols are resolved after linkage with msvcrt.dll. DO NOT SUBSTITUTE -lmsvcrt with -lcrtdll. If you substitute, you will get errors about running out of resources on fileOpen at run time. - You may also need to update your GCC Mingw32 libraries and headers from the Sourceforge Mingw32 downloads page if you have unexplained crashes. Building HDIrect 0.17 - Uninstall previous versions of HDirect including "lib/imports/com" and associated libraries, which don't work very well with GHC 4.08.2. - Get the source from the HDirect web site and untar it somewhere. - You may need to edit "lib/WideStringSrc.c" if you use the latest Cygwin distribution to remove a clashing definition and declaration of wcslen(). - Build per the instructions in the INSTALL file. - This gives you a bare bones ihc.exe which cannot handle type libraries. - Install the freshly built lib/*.hi files in a new ghc "lib/imports/com" directory and also the libraries (libHScom.a, libhdirect.a) into ghc's "lib" directory. - Do "make clean", deleting "src/ihc.exe" by hand. - Set SUPPORT_TYPELIBS=YES in "src/Makefile" - "make boot", "make", then "make lib" as before. - You now have version 0.17 of HDirect for Windows. Question Time: Why does ihc ignore binary interfaces in type libraries such as dx7vb.dll? Cheers Mike Thomas ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Hard earned hints for using Win32 GHC 4.08.2 and HDirect.
Hi all. I thought I might share some hints on making HDirect work with GHC 4.08.2. Installing and checking GHC: - Get the installer from the GHC downloads page, do the installation per the instructions there, including Cygwin etc. - Remove the digit "1" from the bottom of lib/imports/win32/Win32.hi - Remove old .hi files from any program source directories you may have. - To test, try compiling the Windows hello.lhs example using the command line "ghc hello.lhs -o hello.exe -package win32" and run hello.exe. - If you get linker errors about "importtimezone_dll" from time.o, you need to add the line: push(@SysLibrary, '-lcrtdll') if ($TargetPlatform =~ /-(mingw32|cygwin32)$/); below the line: push(@SysLibrary, '-lwsock32') if ($TargetPlatform =~ /-(mingw32|cygwin32)$/); in your "bin/ghc" driver script. This is because the distribution is built with an old version of Cygwin GCC which links against crtdll.dll rather than msvcrt.dll when -mno-cygwin is set on the command line (GHC uses mingw32). By doing this, spare symbols are resolved after linkage with msvcrt.dll. DO NOT SUBSTITUTE -lmsvcrt with -lcrtdll. If you substitute, you will get errors about running out of resources on fileOpen at run time. - You may also need to update your GCC Mingw32 libraries and headers from the Sourceforge Mingw32 downloads page if you have unexplained crashes. Building HDIrect 0.17 - Uninstall previous versions of HDirect including "lib/imports/com" and associated libraries, which don't work very well with GHC 4.08.2. - Get the source from the HDirect web site and untar it somewhere. - You may need to edit "lib/WideStringSrc.c" if you use the latest Cygwin distribution to remove a clashing definition and declaration of wcslen(). - Build per the instructions in the INSTALL file. - This gives you a bare bones ihc.exe which cannot handle type libraries. - Install the freshly built lib/*.hi files in a new ghc "lib/imports/com" directory and also the libraries (libHScom.a, libhdirect.a) into ghc's "lib" directory. - Do "make clean", deleting "src/ihc.exe" by hand. - Set SUPPORT_TYPELIBS=YES in "src/Makefile" - "make boot", "make", then "make lib" as before. - You now have version 0.17 of HDirect for Windows. Question Time: Why does ihc ignore binary interfaces in type libraries such as dx7vb.dll? Cheers Mike Thomas ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Compiling HDirect
Hi Reuben et al. I had some more time to spend on building hdirect from CVS sources using GHC 4.08.2 under NT 4: PROBLEM 1. The timezone_dll problems reported earlier (caused by a Cygwin GCC mingw32 compiler change to linking with msvcrt.dll instead of crtdll.dll). PSEUDOFIX: Push -lcrtdll in the appropriate places in the ghc driver script (don't know yet how this will hold up in the longer run)). The locations are those where -lmsvcrt is pushed. This is of course not required in a rebuilt ghc library - a goal I have yet to achieve. PROBLEM 2. Pointer.hi/o and PointerPrim.hi/o are not built before HDirect.lhs is compiled during a complete rebuild. FIX: I added the following dependency at about line 359: Pointer.o : PointerPrim.o and rearranged the order of the files in: HS_SRCS = PointerPrim.hs Pointer.lhs HDirect.lhs My guess is that the second change is not necessary, I haven't tried removing it yet. PROBLEM 3. Mingw32 built IHC can't handle the Cygwin file links in the shadow build directory (built with mkshadowdir). FIX: I guess I'll have to abandon the shadow CVS source tree and work directly with the sources as checked out under CVS. Thanks for the assistance so far in this voyage of discovery. Mike Thomas. ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
(no subject)
Hi again.
Further to my earlier report today:
1. Further CVS source HDirect Makefile dependencies needed as follows (not
necessarily exhaustive, see 3 below):
Com.o : WideString.o ComPrim.o ComException.o
Automation.o : SafeArray.o AutoPrim.o
SafeArray.o : StdTypes.o
2. While compiling the ihc generated file AutoPrim.hs, errors like the
following arise:
==fptools== make all - --unix -r;
in //d/public/cvsroot/fpt/hdirect/lib
/cygdrive/c/ghc/ghc-4.08.2/bin/ghc -cpp -DBEGIN_GHC_ONLY='-}' -DEND_GHC_ON
LY='
{-' -DBEGIN_NOT_FOR_GHC='{-' -DEND_NOT_FOR_GHC='-}' -DELSE_FOR_GHC='-}-}' -
DBEG
IN_FOR_GHC_4_08_AND_LATER='-}' -DEND_FOR_GHC_4_08_AND_LATER='{-' -DBEGIN_NOT
_FOR
_GHC_4_08_AND_LATER='{-' -DEND_NOT_FOR_GHC_4_08_AND_LATER='-}' -static -fgl
asgo
w-exts -fno-prune-tydecls -recomp -fvia-C -c AutoPrim.hs -o AutoPrim.o -osuf
o
AutoPrim.hs:91:
type synonym `IUnknown' should have 1 argument, but has been given 0
In the type synonym declaration for `IDispatch'
Compilation had errors
make[1]: *** [AutoPrim.o] Error 1
make: *** [all] Error 1
PSEUDOFIX: Naively (I am still a Haskell learner and don't understand the
consequences) added arguments to the type declarations as follows:
type IDispatch a = IUnknown a
dispatchInvoke :: IDispatch (a)
This is a HDirect bug?
---
3. In automation.lhs:
Automation.lhs:7:
Type constructor or class not in scope: `IDispatch_'
Automation.lhs:351:
Type constructor or class not in scope: `IDispatch_'
Cheers and giving up till thumb comes out of mouth and bottom lip recedes.
Mike Thomas
___
Glasgow-haskell-bugs mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: Compiling HDirect from CVS
| Is "_imp___timezone_dll" a Haskell DLL, a missing Mingw lib, I think this is a problem with the version of gcc and the switches it expects; I've added -mwin32 and it seems to work. Try updating and rebuilding. ...and add -mwin32 after -mno-cygwin in the *installed compiler's (4.08.2, presumably) driver script. Sadly, no luck at all. I went through every file in the CVS distribution and the ghc4.08.2 driver and added -mwin32 after every -mno-cygwin. ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Compiling HDirect from CVS
Hi all. I'm having a lot of trouble building the latest version of HDirect from CVS. After setting up per the instructions, adjusting "mk/config.mk" to substitute mingw for cygwin (avoids problems about the Posix library) and then typing make at the top level of fptools I get the link error below. If I go to the hdirect directory and type "make boot" followed by "make" the same problem occurs. I am using ghc 4.08.2 under Windows NT4 with the latest Cygwin setup. Is "_imp___timezone_dll" a Haskell DLL, a missing Mingw lib, or some kind of foot and mouth virus passed from the pure Scottish air to Australia's unseasonally warm shores via cvs? Cheers Mike Thomas. ==fptools== make boot - --unix - --no-print-directory -r; in file://d/public/cvsroot/fpt/ghc/utils/hsc2hs Creating Config.hs ... done. make INSTALLING=0 BIN_DIST=0 - --unix - --no-print-directory -r all /cygdrive/c/ghc/ghc-4.08.2/bin/ghc -package util -O-c Config.hs -o Config.o -osuf o /cygdrive/c/ghc/ghc-4.08.2/bin/ghc -package util -O-c KludgedSystem.hs -o Kl udgedSystem.o -osuf o C:/TEMP/ghc218.hc:297: warning: implicit declaration of function `_getpid' /cygdrive/c/ghc/ghc-4.08.2/bin/ghc -package util -O-c Main.hs -o Main.o -osu f o /cygdrive/c/ghc/ghc-4.08.2/bin/ghc -o hsc2hs-bin -package util -O Config.o KludgedSystem.o Main.o C:/ghc/ghc-4.08.2/lib/libHSstd.a(Time.o)(.text+0x1c42c):ghc1360.c: undefined ref erence to `_imp___timezone_dll' collect2: ld returned 1 exit status ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
GHC Mingw32 build
Hi all.. What is the recommended way of making the Mingw32 build of GHC and all associated tools, eg HDirect, Green-card etc from the CVS? Cheers Mike Thomas ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
HDirect example compilation problem
Hi there.
After compiling the HDirect 0.17 sources using GHC 4.08.2 and the latest
Cygwin internet distribution (some small mods made to deal with Cygwin
B20isms in the C source code):
miketh@NASTURTIUM
file://d/public/ProgrammingLanguages/haskell/hdirect-0.17/examples/
html-dialog
$ make
dlltool --output-lib liburlmon.a --def urlmon.def --dllname urlmon.dll -k
../../src/ihc -c HtmlDialog.idl -o HtmlDialog.hs
file://c/ghc/ghc-4.08.2/bin/ghc -syslib
-fglasgow-exts -L. -lurlmon-c HtmlDia
log.hs -o HtmlDialog.o -osuf o
panic! (the `impossible' happened):
getRegister(x86)
(Prim {-__stdcall-}__dyn_ccall_GC "" Temp(B0StgAddr) Temp(B1StgAddr)
Temp(B2
StgAddr) Temp(B3StgAddr) Temp(B4StgAddr) Temp(B5StgAddr))
Please report it as a compiler bug to [EMAIL PROTECTED]
make: *** [HtmlDialog.o] Error 1
----
Cheers
Mike Thomas.
___
Glasgow-haskell-bugs mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: Greencard, GHC and FFI.
Hi again.
So, when using GC's FFI backend, it generates two source files for you
(and some header files) - in your case, GCTest.hs and GCTest_stub.c.
To achieve linker happiness, you need to compile up the latter and include
it on the link line *and* drop StdDIS.o from that link line.
Thanks for that - I've achieved linker happiness.
FYI, I notice that the GCTest stub file has a do..while(0), which I suppose
should be optimised away by GCC, but still makes the code less
palatable:
/* Auto generated GreenCard 2 code for FFI */
double prim_my_sin(double arg1)
{ double res1;
do { res1=sin(arg1);
return((double)(res1));} while(0);
}
Cheers
Mike Thomas
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell
Greencard, GHC and FFI.
Hi all. I'm having trouble with using green-card 2 on Windows with GHC-4.08.2. As the default output for -target ghc seems to be for the C back-end rather than native code, I thought I would try the FFI target. Using the example from the green-card doc: - module GCTest where import StdDIS %fun my_sin :: Double - Double %code res1=sin(arg1); - Compiling for target FFI: - green-card -c GCTest.gc -o GCTest.hs --target ffi ghc -c GCTest.hs -fglasgow-exts - Linking with this main module: - module Main(main) where import GCTest main :: IO() main = putStrLn (show (my_sin (20.0))) - I get: - $ ghc main.hs -o main.exe GCTest.o StdDIS.o -package lang -package greencard Compilation IS NOT required GCTest.o(.text+0x7f):fake: undefined reference to `prim_my_sin' StdDIS.o(.text+0x549):fake: undefined reference to `prim_free' StdDIS.o(.text+0x600):fake: undefined reference to `prim_allocCharStar' StdDIS.o(.text+0x731):fake: undefined reference to `prim_readCharAddr' StdDIS.o(.text+0xc84):fake: undefined reference to `prim_malloc' StdDIS.o(.text+0xd38):fake: undefined reference to `access_prim_malloc_res1' StdDIS.o(.text+0xdec):fake: undefined reference to `access_prim_malloc_gc_failed ' StdDIS.o(.text+0xea0):fake: undefined reference to `access_prim_malloc_gc_failst ring' StdDIS.o(.text+0x1206):fake: undefined reference to `prim_writeCharAddr' collect2: ld returned 1 exit status - Where have I gone wrong? Cheers Mike Thomas. ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
GHC - Cygwin Installation and also DirectX
Hi all. I'm having ghc import path problems on NT: -- $ ghc -i//c/ghc/ghc-4.08.2/lib/imports/win32 hello.lhs Import path element `/cygdrive/c/ghc/ghc-4.08.2/lib/imports/win32' does not exist, ignor ing. hello.lhs:14: Could not find interface file for `Win32' in the directories /cygdrive/c/ghc/ghc-4.08.2/lib/imports/win32/*.hi ./*.hi C:/ghc/ghc-4.08.2/lib/imports/std/*.hi hello.lhs:15: Could not find interface file for `Addr' in the directories /cygdrive/c/ghc/ghc-4.08.2/lib/imports/win32/*.hi ./*.hi C:/ghc/ghc-4.08.2/lib/imports/std/*.hi Compilation had errors -- The Win32 installation instructions say that one should execute "mount -f C: /", but having done that in response to this error it does not fix the problem and it stops bash from starting up correctly (Cygwin is installed in c:\cygwin and GHC in c:\ghc\ghc-4.08.2). (Why am I supposed to do this mount?) Has anyone got a solution? Furthermore, is anyone using Direct X especially Direct Play and Draw with GHC? Cheers Mike Thomas. ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
RE: GHC WIndows NT Can't Compile (New Installation)
Hi again. Thanks for the help. I followed Sigbjorn's instructions - the QUB Perl interpreter took some time to download and GHC wouldn't work without it - but finally everything worked on my NT machine. Now for Windows 95...then Haskell. Cheers Mike Thomas.
