April 2002 - Nhc-bugs

Re: [nhc-bugs] Building nhc98 on Windows 2000
by C.Reinke 04 Apr '02

04 Apr '02

> I got curious, so I went to have a look at the nhc-bugs archives > -- seems like what's at the root of it all is that the following > ghc invocation: > > ghc -package lang -package posix -c \ > -o /tmp/nhc98-1.12/targets/ix86-CYGWIN_NT-5.0/obj/hmake/QSort.o \ > QSort.hs > > Assembler messages: > FATAL: Can't create \ > \tmp\nhc98-1.12\targets\ix86-CYGWIN_NT-5.0\obj\hmake\QSort.o > > This is a known 'usability bug' with GHC - it doesn't check that > the directory portion of the '-o' file exists, but just merrily > hands it off to the assembler, which barfs with the above > unfriendly message. > > So, for whatever reason, that /tmp/... directory doesn't exist. Question: which assembler is being called there? In a standalone GHC, that can't be the cygwin assembler, so, unless the call is routed via the cygwin shell, the assembler is unlikely to know about cygwin's file system. When I encountered that problem, a simple fix was to add the necessary prefix to turn the cygwin path into a native path: c:/cygwin/tmp/nhc... neither GHC nor cygwin have trouble with that path, and the assembler was happy as well. Claus

2 1

Re: [nhc-bugs] Building nhc98 on Windows 2000
by C.Reinke 04 Apr '02

04 Apr '02

> > > ?? you seem to assume that the redirection affects the executing > > > shell itself, whereas, IMO, it only affects the command. so, if > > > the shell can't find the command, no redirection, and the shell > > > reports the error as usual, no? > > > > There seems to be a difference between bash and sh - the former behaves > > as I would like, the latter as you describe. > > Under sh, something like > > if (basename >/dev/null 2>&1); then echo foo; fi > > will hide the shell's stderr. okay, I admit, I had to check;-) but for sh, the above will not hide the shell's stderr, only the condition's stderr, if that condition is found and executed (reassociating the redirection with the whole helps, though): > sh $ if (fullname >/dev/null 2>&1); then echo hi; fi fullname: not found $ if (fullname 2>>/dev/null); then echo hi; fi fullname: not found $ if fullname ; then echo hi ; fi 2>>/dev/null $ whereas, as Malcolm pointed out, bash differs from sh here..:-( > bash bash-2.04$ if (fullname >/dev/null 2>&1); then echo hi; fi bash-2.04$ if (fullname 2>>/dev/null); then echo hi; fi bash-2.04$ if fullname ; then echo hi ; fi 2>>/dev/null bash-2.04$ if fullname; then echo hi; fi bash: fullname: command not found bash-2.04$ Claus

1 0

RE: [nhc-bugs] Cygwin and GHC
by Simon Peyton-Jones 04 Apr '02

04 Apr '02

| Can you comment on how much longer the GHC core team will exist? Indefinitely. Meaning that (a) There is no time limit: Simon and I have permanent posts Reuben and Julian left when the grant ran out; we knew that was coming, but there is no correponding future event known. (b) But (as has been the case for the last 15 yrs) "indefinite" does not mean "forever". One day I'll get old and die. The more people that help look after GHC, the healthier it will be. It's fun, it's rewarding, and it's not as demanding as you might think. There's even a lovely commentary to explain how it works http://www.cse.unsw.edu.au/~chak/haskell/ghc/comm/ Simon

1 0

Cygwin and GHC
by Simon Peyton-Jones 04 Apr '02

04 Apr '02

Folks, There's been some mail recently about GHC and Cygwin, some of it on the nhc-bugs list (hence ccing this there). I'm a bit confused so this message is to try to clarify the situation. The GHC core team is now down to Simon M and me. Sigbjorn heroically helps out on Win32 stuff, but it isn't his job. So we have strictly limited effort available. I am therefore deeply reluctant to provide both GHC-for-mingw32 and GHC-for-cygwin. One build on Win32 is enough! We ended up with a mingw32 basis because it meant we could make GHC completely self-contained -- no dependence on cygwin1.dll etc. This was *huge* step forward: GHC installs and runs with no problem on Windows now. Therefore I ask: can someone summarise succinctly what the problems with GHC-for-mingw32 are? The ones I know about are these: 1. GHC does not understand cygwin paths in the file names passed to it on the command line. 2. GHC on Win32 does not come with a Posix library. If we used a Cygwin basis, Posix would be easy because cygwin does all the hard work. 3. I/O on Win32 is *blocking*. A blocking input operation freezes all the other Haskell threads. Are there any other problems? My own ill-informed thoughts on these are: 1. GHC already fudges filenames to take account of the Win32/Unix conventions. We could add more fudges, to change /cygwin/c/foo to c:\foo, for example. Perhaps controlled by a -cygwin flag to tell GHC-for-win32 whether to use cygwin fudges or not. Heuristic, yes; but might solve the problem for 99% of customers. 2. Mingw32 provides quite a lot of Posix, so if someone was prepared to put in a bit of work we could get a good part of the Posix library available on Win32, still via mingw. Any volunteers? 3. Non-blocking I/O is a soluble problem: Win32 provides suitable primitives. But they are different to the Unix primitives, so there is work to do in the runtime system to make it work. This is harder for a volunteer to do because it's in the runtime system, but not impossible. Any thoughts? Ideas are much more likely to be implemented if they are either easy, or you can help do the job! Simon

2 1

Re: Cygwin and GHC
by Claus Reinke 04 Apr '02

04 Apr '02

>I am therefore deeply reluctant to provide both GHC-for-mingw32 >and GHC-for-cygwin. One build on Win32 is enough! We ended >up with a mingw32 basis because it meant we could make GHC >completely self-contained -- no dependence on cygwin1.dll etc. Some comments from a binary-only GHC user who tends to depend a lot on cygwin while using windows: >This was *huge* step forward: GHC installs and runs with no problem >on Windows now. This *is* a huge step forward, and together with GHCi and HOpenGL, has even tempted me to use GHC a bit more:-) Having to wrestle with two different GHC installations on one platform would seem a step backward. So, I'd not only agree with one build only (GHC should be compilable under cygwin, though, for those who absolutely need to go the other way, or who want to track the CVS version), I'd like one build to work both in native and in cygwin mode. As a Haskell user, I'm interested in: - a standalone GHC, producing standalone executables and dlls, with good FFI interfaces to the non-Haskell world - portability across platforms, with as few code changes or restrictions as possible My approach to keeping windows/unix differences small is mostly based on cygwin, so I need to be able to use GHC and it's executables under cygwin, as I would use it under unix, in combination with other (windows/ cygwin) software. That doesn't mean that GHC-generated executables or libraries need to be cygwin-dependent, and cygwin is, by design, able to use windows executables (mixing of libraries is probably another story). >1. GHC does not understand cygwin paths in the file names passed >to it on the command line. Making GHC understand cygwin paths makes software more system dependent, not more portable. And what about the executables produced by GHC? Most of the cygwin path problems could, in theory, be solved without changing GHC, but with a lot of accumulated UNIX makefiles, that can be unpractical. As far as I understand, GHC can cope with both relative unix-style and relative and absolute windows-styles paths, so the remaining problem I tend to encounter are "absolute" unix-style paths which are really relative to the cygwin root directory. (I also seem to recall someone mentioning problems related to GHC passing "normalised" paths to other tools, but if GHC uses it's own toolchain, that seems unlikely?) My suggestion would be a --prefix <path> option, or GHC_PATH_PREFIX variable for GHC-produced executables (including GHC itself), telling them that any absolute, unix-style paths are to be interpreted relative to <path> (e.g., in cygwin makefiles, default installation, HC=ghc --prefix c:/cygwin). That wouldn't be platform-specific and might also come in handy for other purposes. >2. GHC on Win32 does not come with a Posix library. If we used a >Cygwin basis, Posix would be easy because cygwin does all the hard work. That looks like a real bugger to me as it impacts on portability of Haskell programs. Going from incomplete posix support to even less posix support was a step backwards. >3. I/O on Win32 is *blocking*. A blocking input operation freezes all >the other Haskell threads. No experience with that one, but in general, establishing consistent I/O behaviour across platforms would be a very useful asset. >Are there any other problems? perhaps: 4. File I/O on windows differs from I/O in unix (locking of files instead of implicit maintainance of hidden handles, I think??). cygwin tries to smooth things over, but fails for more complex cases (open a file for reading, remove it, open it for writing, copy from read handle to write handle).We just traced a problem in building nhc on cygwin down to that one.. How does mingw fare in that respect? Better? Or even worse? 5. I assume that GHC and it's executables interface rather well with the windows world. What about interfacing to software ported from unix that depends on cygwin, though? >1. GHC already fudges filenames to take account of the Win32/Unix >conventions. We could add more fudges, to change /cygwin/c/foo >to c:\foo, for example. Perhaps controlled by a -cygwin flag to tell >GHC-for-win32 whether to use cygwin fudges or not. Heuristic, yes; >but might solve the problem for 99% of customers. No heuristic, please, just some more flexibility for makefile authors (/cygwin/c/foo tends to be /cygdrive/c/foo these days, and sometimes is //c/foo, but c:/foo tends to work as well - do you want to track cygwin's mount table in GHC?-). >2. Mingw32 provides quite a lot of Posix, so if someone was prepared >to put in a bit of work we could get a good part of the Posix library >available on Win32, still via mingw. Any volunteers? I step back to make space for the volunteers, but mingw being minimalistic, what are the chances that it's posix support is a suitable alternative to cygwin's, which isn't complete, either? >3. Non-blocking I/O is a soluble problem: Win32 provides suitable >primitives. But they are different to the Unix primitives, so there is >work to do in the runtime system to make it work. This is harder >for a volunteer to do because it's in the runtime system, but not >impossible. As far as I know, cygwin (the *larger* cousin of mingw) is still waiting for someone to contribute solutions to I/O problems on top of windows.. Thanks for raising this issue, Claus PS. >The GHC core team is now down to Simon M and me. Sigbjorn >heroically helps out on Win32 stuff, but it isn't his job. So we have >strictly limited effort available. [I have to admit that I'm a bit concerned about the overall number of people involved in Haskell implementations. Fortunately, the licenses are very open, and fortunately, we do have those heroic volunteers, but the Haskell implementation core team isn't going to be much (if any) bigger than the GHC core team soon. Given the interests of some (well, at least one;) companies, and the volunteers working for those, perhaps they could acknowledge the work done by those volunteers as being essential for their business? And given the wide-spread use in academia as a research and teaching platform, does anyone know of a way of securing some kind of international platform funding, to keep the current implementations alive and to develop them further (as an academic complement to Galois' (?) and MS' contributions in terms of man-power)?]

1 0

trouble compiling under Solaris x86
by jonbernard＠iname.com 04 Apr '02

04 Apr '02

Hi, I'm having difficulty compiling nhc-1.12 for Solaris 2.8 x86. The trouble seems to be with DErrno.hs: make[1]: Entering directory `/home/jon/tgz/nhc/nhc98-1.12/src/prelude/ix86-solaris2' rm -f *.hi rm -f DErrNo.hc rm -f /home/jon/tgz/nhc/nhc98-1.12/targets/ix86-solaris2/obj/prelude/DErrNo/*.o *.o rm -f rm -f /home/jon/tgz/nhc/nhc98-1.12/script/nhc98 -cpp -c +CTS -lib -redefine -CTS +RTS -H32M -RTS -o /home/jon/tgz/nhc/nhc98-1.12/targets/ix86-solaris2/obj/prelude/DErrNo/DErrNo.o DErrNo.hs Killed make[1]: *** [/home/jon/tgz/nhc/nhc98-1.12/targets/ix86-solaris2/obj/prelude/DErrNo/DErrNo.o] Error 1 make[1]: Leaving directory `/home/jon/tgz/nhc/nhc98-1.12/src/prelude/ix86-solaris2' make: *** [targets/ix86-solaris2/compiler-gcc] Error 2 I've tried replacing the generated DErrno.hs with the default version using only the GNU utils (ie, removing /usr/ccs/bin from my PATH) using gcc without any optimization applying both patches to 1.12 (the hmake and ranlib patches) to no avail. I'm attaching the generated DErrno.hs and the output of LD_OPTIONS="-L/opt/sfw/lib -R/opt/sfw/lib" ./configure --buildwith=gcc --buildopts="-I/opt/sfw/include" --prefix=/usr/local/$(basename $(pwd)) | tee install_notes I can of course send you any other files, output, etc you might need. By the way, on Solaris /usr/ccs/bin/make and /usr/xpg4/bin/make complain about unexpected end of lines in Makefile.inc (and other Makefiles). Thanks, Jon Bernard

3 3

RE: [nhc-bugs] Building nhc98 on Windows 2000
by Simon Peyton-Jones 04 Apr '02

04 Apr '02

| > I don't know whether Sigbjorn plans to continue supporting | this route | > - Sigbjorn? | > | | Is there really a demand for it? Judging by the download logs | for the cygwin snapshot I put out last week, I remain | unconvinced that it's worth the effort (i.e., 'wasting' a | day+ to fix up & package a release that's been downloaded by | _one_ single soul, doesn't strike me as a worthwhile way to | be spending my free time.) I agree! (See my recent message.) Simon

1 0

Re: [nhc-bugs] Building nhc98 on Windows 2000
by C.Reinke 03 Apr '02

03 Apr '02

> > 1) what exactly is "fullname" supposed to do in configure? > > > > if fullname 2>>/dev/null # cope with symbolic links in directory > > What it says in the comment... :-) If `fullname' is available it > gives the absolute pathname to its argument, i.e. it expands symbolic > links fully in the directory part. I can't see this under Solaris either, so the number of systems having it might be limited? > > Updating targets/ix86-CYGWIN_NT-5.0/hmake3.config... > > fullname: not found > > If your system doesn't have it, it won't be executed. You definitely > shouldn't see the `not found' message, because that was redirected to > /dev/null. ?? you seem to assume that the redirection affects the executing shell itself, whereas, IMO, it only affects the command. so, if the shell can't find the command, no redirection, and the shell reports the error as usual, no? > Curiously enough, the only reason I introduced `fullname' was because > of Cygwin. Remember the business with $(PWD) vs $(shell pwd) in > Makefiles (Cygwin requires the latter)? Well in Unix systems, the > two forms give different results if there are symbolic links in the > directory path. Hence `fullpath' is used as a hack to try to patch > up the difference. I admire everyone who is fighting to smooth over incompatibilities to produce portable systems!-) > No, and if you look closely it isn't the line I wrote either... :-) > It actually reads > $ grep '^NHC98INCDIR' ... oops, my bad! > I think I can see how this is failing now. Consider this code: > > runAndReadStdout cmd = do > ... > s <- readFile output > removeFile output -- file will not be removed until readFile closes it > return (safeinit s) -- strip trailing newline added by shell I was indeed homing in on that strange artifact (btw, don't you want to force the call to safeinit, so that readFile can complete and removeFile can proceed?). > The file-removal assumes the unix-like property that you can unlink a > file while it still has a (lazy) reader attached to it, and the file > contents will stick around until the reader has finished with it. > It is perfectly possible to create a new (different) file with the > same name as the old one whilst the old one is still being read. Ah, I had almost forgotten about that old magic:) Old wizards used to say: don't use magic for ordinary tasks. It may be cute that it works on real systems, but it isn't really needed here, so why not go for the ordinary, boring way? > Am I right in guessing that the Cygwin filesystem doesn't have > these semantics? Windows doesn't seem to agree with these semantics, so you might not want to run your Haskell-code in plain-Windows hugs/ghc.. Cygwin itself tries to smooth things over, but there seem to be an awful lot of ways that can go wrong. The particular problem most relevant to our case seems to be described here: http://www.cygwin.com/ml/cygwin/2001-07/msg01799.html in other words, the open-unlink-read thing kind of works, but if you then try a write on top of it all (as in the second call to runAndReadStdout), the current unlink hackery doesn't seem to cope (I don't know the details, but one rumour has it that unlinks of open files are simply queued for later removal), which might explain the permission problem. Forcing the call to safeinit, so that output is no longer open via readFile when removeFile is called, should get rid of that? Claus

3 2

RE: [nhc-bugs] Building nhc98 on Windows 2000
by Simon Marlow 03 Apr '02

03 Apr '02

I've had half an eye on this discussion... just a couple of things to add: > > grep: /cygdrive/c/ghc/ghc-5.02.2/bin/ghc: No such file or > directory > > Ah, yes I think I remember reading once that GHC/mingw32 does not have > a driver script, only a directly executable binary. Hence, grepping > through the script for configuration information (as hmake-config is > attempting to do here) is no longer an option. Unfortunately, I'm not > aware of any other way to reliably get config info out of GHC. 'ghc -v' on 5.00 and 5.02 (and later versions) will tell you where the package config file is, and the rest of the info can be extracted from that. However, you do know that we're planning to move to binary interface files, right? Perhaps we should rethink how hmake gets hold of its info about libraries - what exactly does it need to know? > Sadly, the difficulty of using GHC/mingw32 as a bootstrapping compiler > seems to be increasing the more we delve into it. Perhaps it would > be safest for us simply to recommend GHC/cygwin instead, and disallow > the GHC/mingw32 route. I don't know whether Sigbjorn plans to continue supporting this route - Sigbjorn? Cheers, Simon

3 2

Re: [nhc-bugs] Building nhc98 on Windows 2000
by C.Reinke 03 Apr '02

03 Apr '02

Hi again, no real progress, but a few small points (--buildwith=gcc): 1) what exactly is "fullname" supposed to do in configure? if fullname 2>>/dev/null # cope with symbolic links in directory paths then echo "$BUILDBINDIR/hmake-config $BUILDLIBDIR/$MACHINE/hmakerc \ add `fullname ./script/nhc98`" \ >>targets/$MACHINE/hmake3.config fi; And where is it supposed to come from? I can't find it, and neither can configure: Updating targets/ix86-CYGWIN_NT-5.0/hmake3.config... fullname: not found Saving current configuration in targets/ix86-CYGWIN_NT-5.0/config.cache Done. 2) is this really the line you want to get (in MkConfig.hs:210)? $ grep 'NHC98INCDIR' /tmp/nhc98-1.12/script/nhc98 | cut -c27- | cut -d'}' -f1 | head -1 find the hi files for the standard prelude, The path appears to be the second line in the output, just after the comment line;-) 3) after telling hmake-config not to bother with ghc, the case of the failing write to /tmp/.. appears to be in the second call to runAndReadStdout in MkConfig.hs (see 2), and all those calls use the same tmpfile for output from "system" calls. If the "grep" is the second call, that means that one call has succeeded without permission problems. That looks a lot as if "noclobber" was set in the system shell (causing output redirections to existing files to fail), only that if I just ask my toplevel bash, it claims that noclobber is off. Does system itself do anything fancy here (probably not)? If I wouldn't be compiling from .hc-files, I could just play with MkConfig.hs (using a different tmpfile for each call, or removing the tmpfiles after use, or even using ">|" for redirection to override noclobber). And I can't just run MkConfig.hs through hugs or ghc, because they would both defer system calls to the windows-shell, not to a version of sh, as the cygwin-based nhc will do, right? Is there an easy way for me to generate MkConfig.hc from MkConfig.hs, so that I can do some debugging? Any other ideas? Anyone else in the game?-) Claus

2 1