- Nhc-bugs - Haskell.org

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

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

03 Apr '02

> > '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. > > Useful to know. However, the value of $libdir is not defined in the > package config file, and that is the information I was grepping for in > the driver script... You can assume that package.conf is in $libdir (that's currently how we find it in the first place - $libdir is the only bit of information about the host system that GHC knows when it starts up). > Actually, `ghc -v' (with 5.02.2) seems to dump the entire package > config to stdout with $libdir expanded out. This might be sufficient > for me, but I need to know whether that behaviour is consistent across > all versions of ghc >= 5.00? We only started doing this in 5.02 I think, and anyway I'm tempted to move it out of the default -v output and into -v3 or maybe -v4. > The format of the interface files is irrelevant to hmake - it doesn't > read them, it only checks for their existence. The basic requirement > for hmake is that every module mentioned in an import must have > a referent. The referent can be a source module (.hs, .lhs, .ly, > .gc, etc), or if the sources are not available (e.g. Prelude, or a > package module) then an interface (.hi file) will do. Source modules > are scanned for further dependencies, but interface-only modules are > assumed to be leaves of the graph. Ok, gotcha. Cheers, Simon

1 0

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

02 Apr '02

Malcolm, > > Ok, tried that (with the patches and with the include-modifications). > > It seems to run into a problem as well (haven't had time to look > > into this yet, but just in case you recognise the symptoms): > > > > hmake-config: Starting new config from scratch. > > cannot create /tmp/hmakeconfig.1748: permission denied > > Yuk. Is the existence of a writable /tmp something I can't assume > on Cygwin/Windows either? The real joke is that I was doing the whole thing in /tmp/nhc.., so /tmp definitely existed and was writable, or I wouldn't even have been able to unpack the stuff, let alone compile anything. So there is something odd with that error message, which is why I asked whether the symptoms ring a bell. Any ideas? > > 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. So it seems. And I've seen you trying to follow ghc's development here on numerous occasions. Given that you are all working to make Haskell a better platform, why do you have to guess each other's configuration info? Why not define the info everyone needs about each others implementations, and put that into a well known place (a show-config option to the compiler/interpreter, for instance). That would also come in handy for bug reports, and implementers would be free to change their code, as long as they still deliver the config data. > Unfortunately, I'm not > aware of any other way to reliably get config info out of GHC. > 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. As long as the gcc-route still works, that should be less of a problem for those who want a ghc with everything stable, but without the fun of compiling it. We'll see. One step after the other. Cheers, Claus

1 0

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

02 Apr '02

> Yes, it is still possible to build with a specified compiler, > overriding the detected choice of compiler, e.g. > ./configure --buildwith=gcc Ok, tried that (with the patches and with the include-modifications). It seems to run into a problem as well (haven't had time to look into this yet, but just in case you recognise the symptoms): cd src/hmake; make fromC config make[1]: Entering directory `/tmp/nhc98-1.12/src/hmake' mkdir -p /tmp/nhc98-1.12/targets/ix86-CYGWIN_NT-5.0/obj/hmake || /bin/true /tmp/nhc98-1.12/script/nhc98 -H4M -o /tmp/nhc98-1.12/lib/ix86-CYGWIN_NT-5.0/Mk Prog.exe -d /tmp/nhc98-1.12/targets/ix86-CYGWIN_NT-5.0/obj/hmake QSort.hc Unli t.hc Utils.hc Tsort.hc FileName.hc SymTab.hc Output.hc Order.hc ListUtil. hc Getmodtime.hc MkProg.hc IsPrefixOf.hc Compiler.hc PreProcessor.hc Argv. hc Graph.hc GetDep.hc ParseLib.hc Compat.hc Imports.hc Config.hc /tmp/nhc98-1.12/script/nhc98 -o /tmp/nhc98-1.12/lib/ix86-CYGWIN_NT-5.0/Ol der.exe -d /tmp/nhc98-1.12/targets/ix86-CYGWIN_NT-5.0/obj/hmake Older.hc /tmp/nhc98-1.12/script/nhc98 -o /tmp/nhc98-1.12/lib/ix86-CYGWIN_NT-5.0/MkCo nfig.exe -d /tmp/nhc98-1.12/targets/ix86-CYGWIN_NT-5.0/obj/hmake MkConfig.hc Co nfig.hc Compiler.hc strip /tmp/nhc98-1.12/lib/ix86-CYGWIN_NT-5.0/MkProg.exe /tmp/nhc98-1.12/lib/ix86 -CYGWIN_NT-5.0/Older.exe /tmp/nhc98-1.12/lib/ix86-CYGWIN_NT-5.0/MkConfig.exe sh /tmp/nhc98-1.12/targets/ix86-CYGWIN_NT-5.0/hmake3.config hmake-config: Warning: Config file not found: '/tmp/nhc98-1.12/lib/ix86-CYGWIN_NT-5.0/hmakerc' hmake-config: Starting new config from scratch. cannot create /tmp/hmakeconfig.1748: permission denied grep: /cygdrive/c/ghc/ghc-5.02.2/bin/ghc: No such file or directory I/O error (user-defined), call to function `userError': Command (grep '^libdir=' /cygdrive/c/ghc/ghc-5.02.2/bin/ghc | head -1 | sed 's /^libdir=.$.*$./\1/') failed grep: /cygdrive/c/ghc/ghc-5.02.2/bin/ghc: No such file or directory cannot create /tmp/hmakeconfig.1840: permission denied I/O error (user-defined), call to function `userError': Command (grep '^libdir=' /cygdrive/c/ghc/ghc-5.02.2/bin/ghc | head -1 | sed 's /^libdir=.$.*$./\1/') failed cannot create /tmp/hmakeconfig.1120: permission denied I/O error (user-defined), call to function `userError': Command (grep ^NHC98INCDIR /tmp/nhc98-1.12/script/nhc98| cut -c27- | cut -d'}' -f1) failed hmake-config: compiler not known: '/tmp/nhc98-1.12/script/nhc98' make[1]: *** [config] Error 2 make[1]: Leaving directory `/tmp/nhc98-1.12/src/hmake' make: *** [targets/ix86-CYGWIN_NT-5.0/hmake-gcc] Error 2 > > - inttypes.h and stdint.h don't exist > > #include <sys/types.h> instead > > Ok, I could place some more #ifdefs to solve this. > > > in include/HsFFI.h: > > #include <sys/types.h> instead, and > > typedef uint{8,16,32,64}_t yourself > > ... but `uint8_t' etc. are part of the C standard now are they not? I don't have the standard here, but the way I read the draft (N843, see first links at http://www.lysator.liu.se/c/ ), you seem to be right - they should be in stdint.h, which doesn't exist in cygwin (but has been added to mingw). Someone asked about this discrepancy on the cygwin mailing lists a while ago, but I can't see an answer.. <sys/types.h> defines the signed versions (intN_t), and a variant of the unsigned versions (u_intN_t), protected by "#ifdef __MS_types_". If you really only need the four typedefs, perhaps it is safest to define them yourself in the __CYGWIN32__ case, until cygwin catches up? > There must be a standard include for them. "should"?-) > > 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: > > No such file or directory > > I *think* the problem here is that the standard GHC distribution for > Windows is now a mingw32 application, and it translates paths to > "native" format, which apparently the Cygwin assembler doesn't like. > Sigbjorn has recently made a GHC-for-Cygwin binary package available > which might solve this problem. Tracking a separate (no-thrills) version of GHC-for-Cygwin just to compile nhc doesn't sound attractive, though I applaud Sigbjorn's efforts for those who don't have another route. As I mentioned, cygwin and ghc are flexible enough to work around this problem by choosing appropriate prefixes to those absolute paths affected. > > [I thought these ghc/cygwin-path problems were an old Hat by now?-] > > So did I, but GHC's move away from Cygwin to support a native Windows > configuration seems to have broken several things that used to work. Yeah, "never change a winning team", they say. On the one hand, I can see the attraction of getting closer to stand-alone executables. On the other hand, going from a relatively complete system (cygwin) to a minimalist one (mingw) has its disadvantages, such as > > c:\ghc\ghc-5.02.2\gcc-lib\ld.exe: cannot find -lHSposix > > My fault. I assumed that GHC's -package posix would be available in > all current GHC's. But of course, Windows is a non-Posix environment. Well, cygwin has good posix support, but mingw (on which ghc relies now) hasn't. There you go.. http://www.mingw.org/x86-win32-ports.shtml > I'll try to find a simple fix that removes the Posix dependency under > Windows - it is only used in a trivial way anyhow. Sounds like the way to go? I will look into the buildwith=gcc problems another time. Let me know when you've got an idea about the posix part, and I'll try buildwith=ghc again. Cheers, Claus

2 1

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

02 Apr '02

> > I am not able to fully build nhc98 V1.12 under Windows 2000 (cygwin): > > building hmake constantly fails. just gave it a quick try (cygwin,Win2k,nhc-1.12+ranlib/hmake-patches). > > I was able to work around several other problems: > > a) inclusion of stdint.h (which gave name conflicts), only exists in mingw part (no experience with that, not sure whether its a good idea to include its version of stdint.h?) > > b) inclusion of inttypes.h (this file is not even present) and doesn't exist in cygwin. > Could you supply some more details, particularly about how you worked > around problems (a) and (b)? The only reason for #include'ing those > files is to get the standard typedef for int64_t etc. Is there an > alternative location for that in Cygwin? here's my problem log so far (btw, configure found my ghc-5.02.2; there used to be a way to install with gcc only - is this still there?): - inttypes.h and stdint.h don't exist in src/runtime/kernel/mark.h: #include <sys/types.h> instead in include/HsFFI.h: #include <sys/types.h> instead, and typedef uint{8,16,32,64}_t yourself - ... make[1]: Leaving directory `/tmp/nhc98-1.12/src/hat/runtime' touch targets/ix86-CYGWIN_NT-5.0/runtime cd src/hmake; make HC=ghc install config make[1]: Entering directory `/tmp/nhc98-1.12/src/hmake' mkdir -p /tmp/nhc98-1.12/targets/ix86-CYGWIN_NT-5.0/obj/hmake || /bin/true 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 : No such file or directory make[1]: *** [/tmp/nhc98-1.12/targets/ix86-CYGWIN_NT-5.0/obj/hmake/QSort.o] Error 1 make[1]: Leaving directory `/tmp/nhc98-1.12/src/hmake' make: *** [targets/ix86-CYGWIN_NT-5.0/hmake-ghc] Error 2 in src/hmake/Makefile: $(BUILDDIR) and $(DST) are absolute, cygwin-style pathnames, but will be passed to (non-cygwin) ghc, so we need to replace those with non-cygwin-style pathnames. the proper way would probably use cygpath, but then we'd need to escape the \s for use in the cygwin-tools (using patsubst?). for now, just prefix them with c:/cygwin (ghc can handle / and \). [I thought these ghc/cygwin-path problems were an old Hat by now?-] - ... cd src/hmake; make HC=ghc install config make[1]: Entering directory `/tmp/nhc98-1.12/src/hmake' ghc -package lang -package posix -o c:/cygwin/tmp/nhc98-1.12/lib/ix86-CYGWIN_NT-5.0/MkProg.exe c:/cygwin/tmp/nhc98-1.12/targets/ix86-CYGWIN_NT-5.0/obj/hmake/QSort.o c:/cygwin/tmp/nhc98-1.12/targets/ix86-CYGWIN_NT-5.0/obj/hmake/Unlit.o c:/cygwin/tmp/nhc98-1.12/targets/ix86-CYGWIN_NT-5.0/obj/hmake/Utils.o c:/cygwin/tmp/nhc98-1.12/targets/ix86-CYGWIN_NT-5.0/obj/hmake/Tsort.o c:/cygwin/tmp/nhc98-1.12/targets/ix86-CYGWIN_NT-5.0/obj/hmake/FileName.o c:/cygwin/tmp/nhc98-1.12/targets/ix86-CYGWIN_NT-5.0/obj/hmake/SymTab.o c:/cygwin/tmp/nhc98-1.12/targets/ix86-CYGWIN_NT-5.0/obj/hmake/Output.o c:/cygwin/tmp/nhc98-1.12/targets/ix86-CYGWIN_NT-5.0/obj/hmake/Order.o c:/cygwin/tmp/nhc98-1.12/targets/ix86-CYGWIN_NT-5.0/obj/hmake/ListUtil.o c:/cygwin/tmp/nhc98-1.12/targets/ix86-CYGWIN_NT-5.0/obj/hmake/Getmodtime.o c:/cygwin/tmp/nhc98-1.12/targets/ix86-CYGWIN_NT-5.0/obj/hmake/MkProg.o c:/cygwin/tmp/nhc98-1.12/targets/ix86-CYGWIN_NT-5.0/obj/hmake/IsPrefixOf.o c:/cygwin/tmp/nhc98-1.12/targets/ix86-CYGWIN_NT-5.0/obj/hmake/Compiler.o c:/cygwin/tmp/nhc98-1.12/targets/ix86-CYGWIN_NT-5.0/obj/hmake/PreProcessor.o c:/cygwin/tmp/nhc98-1.12/targets/ix86-CYGWIN_NT-5.0/obj/hmake/Argv.o c:/cygwin/tmp/nhc98-1.12/targets/ix86-CYGWIN_NT-5.0/obj/hmake/Graph.o c:/cygwin/tmp/nhc98-1.12/targets/ix86-CYGWIN_NT-5.0/obj/hmake/GetDep.o c:/cygwin/tmp/nhc98-1.12/targets/ix86-CYGWIN_NT-5.0/obj/hmake/ParseLib.o c:/cygwin/tmp/nhc98-1.12/targets/ix86-CYGWIN_NT-5.0/obj/hmake/Compat.o c:/cygwin/tmp/nhc98-1.12/targets/ix86-CYGWIN_NT-5.0/obj/hmake/Imports.o c:/cygwin/tmp/nhc98-1.12/targets/ix86-CYGWIN_NT-5.0/obj/hmake/Config.o c:\ghc\ghc-5.02.2\gcc-lib\ld.exe: cannot find -lHSposix make[1]: *** [c:/cygwin/tmp/nhc98-1.12/lib/ix86-CYGWIN_NT-5.0/MkProg.exe] Error 1 make[1]: Leaving directory `/tmp/nhc98-1.12/src/hmake' make: *** [targets/ix86-CYGWIN_NT-5.0/hmake-ghc] Error 2 Enough for today;-( Claus

2 1

Patches for building NHC98 with current GHC
by Sven Panne 02 Apr '02

02 Apr '02

Although it's not good style to simply post to a mailing list without thoroughly browsing the its archives for a similar problem, I'll do it anyway... >:-) To build NHC98 1.12 with a current (= from CVS) GHC, two patches have to be applied: * PrelBase has gone and there are probably *very* few people out there (if any :-) with an ancient GHC <= 2.02, so the lines which make hmake fail can simply be nuked. * Besides other things, -fglasgow-exts switches on the handling of implicit paramters and the syntax %foo for linear implicit parameters. Alas, a space is missing then in LexLow.hs. Cheers, S. diff -u -r nhc98-1.12-orig/src/greencard/Decl.lhs nhc98-1.12/src/greencard/Decl.lhs --- nhc98-1.12-orig/src/greencard/Decl.lhs Mon Oct 11 12:50:38 1999 +++ nhc98-1.12/src/greencard/Decl.lhs Tue Apr 2 06:52:53 2002 @@ -20,10 +20,6 @@ import Pretty -#if defined(__GLASGOW_HASKELL__) && __GLASGOW_HASKELL__ <= 202 -import PrelBase(maybe) -- workaround for GHC 2.02 -#endif - \end{code} \begin{code} diff -u -r nhc98-1.12-orig/src/greencard/FillIn.lhs nhc98-1.12/src/greencard/FillIn.lhs --- nhc98-1.12-orig/src/greencard/FillIn.lhs Tue Oct 12 12:19:38 1999 +++ nhc98-1.12/src/greencard/FillIn.lhs Tue Apr 2 06:53:10 2002 @@ -33,11 +33,6 @@ import Monad (MonadPlus(mplus)) #endif -#if defined(__GLASGOW_HASKELL__) && __GLASGOW_HASKELL__ <= 202 -import PrelBase(maybe) -- workaround for GHC 2.02 -#endif - - \end{code} %************************************************************************ diff -u -r nhc98-1.12-orig/src/greencard/Process.lhs nhc98-1.12/src/greencard/Process.lhs --- nhc98-1.12-orig/src/greencard/Process.lhs Fri Jun 8 19:03:58 2001 +++ nhc98-1.12/src/greencard/Process.lhs Tue Apr 2 06:53:25 2002 @@ -24,10 +24,6 @@ import Target( Target(..) ) import NHCBackend (cNhc, hNhc) -#if defined(__GLASGOW_HASKELL__) && __GLASGOW_HASKELL__ <= 202 -import PrelBase(maybe) -- workaround for GHC 2.02 -#endif - #if defined(__HASKELL98__) # if !defined(__HBC__) import IO(hPutStrLn) diff -u -r nhc98-1.12-orig/src/compiler98/LexLow.hs nhc98-1.12/src/compiler98/LexLow.hs --- nhc98-1.12-orig/src/compiler98/LexLow.hs Tue Dec 11 10:55:13 2001 +++ nhc98-1.12/src/compiler98/LexLow.hs Tue Apr 2 07:28:21 2002 @@ -240,7 +240,7 @@ lexHelp i (c'',s,m,e:xs'') | (e == 'e' || e == 'E') = case lexExp c'' xs'' of - (c''',e,xs''') -> (r,c''',L_RATIONAL ((((i*s+m)%s)::Rational)*10^^e),xs''') + (c''',e,xs''') -> (r,c''',L_RATIONAL ((((i*s+m) % s)::Rational)*10^^e),xs''') --- (c''',e,xs''') -> (r,c''',L_RATIONAL ((((i*s+m)%s)::Rational){-*(fromInteger 10^^e)-}),xs''') --- GOFER ONLY !!! lexHelp i (c'',s,m,xs'') = (r,c'',L_RATIONAL ((i*s+m) % s),xs'')

2 1

Building nhc98 on Windows 2000
by "Holzmüller, Bernd" 27 Mar '02

27 Mar '02

I am not able to fully build nhc98 V1.12 under Windows 2000 (cygwin): building hmake constantly fails. Has anyone ever tried to compile the latest release under Windows? I was able to work around several other problems: a) inclusion of stdint.h (which gave name conflicts), b) inclusion of inttypes.h (this file is not even present) and c) make clean removing all .hc files which subsequently were needed to build the thing again. I would be very glad to have a pre-built binary installation for Windows and not needing to build that of my own! (I assume I am not the only one :-) Regards, Bernd Holzmüller

2 1

Fw: Re: [nhc-bugs] a problem with 1.12
by Malcolm Wallace 26 Mar '02

26 Mar '02

[Forwarded message - original mistakenly sent only to Feliks] > It turned out that I had everything, except for > , includePaths = [""] > > Anyway, I fixed this manually, and the build seemed to proceed smoothly. > Installation complained a little: > > Adjusting... hmakerc > shUsage: grep [OPTION]... PATTERN [FILE]... > Try `grep --help' for more information. > : NHC98INCDIR: not found > shUsage: grep [OPTION]... PATTERN [FILE]... > Try `grep --help' for more information. > : NHC98INCDIR: not found > hat-trail.jar > hood.jar Nasty. > Unfortunately, the problem reappeared during an attempt to use the > compiler: I would guess that the installation of the hmakerc file changed the includePaths definition back to [""] for the installed location of the compiler. For now, the easiest solution might be to find the installed copy of the hmakerc file /usr/local/lib/hmake/sparc-solaris2/hmakerc (or with your own prefix instead of /usr/local) and add the correct location of the installed include files, e.g. includePaths = ["/usr/local/include/nhc98"] There are probably at least two entries for nhc98; don't forget to change both of them. Regards, Malcolm

1 1

a problem with "clean"?
by Feliks Kluzniak 22 Mar '02

22 Mar '02

Hello, Just a minor gripe. I wanted to increase the default heap size, so just to be on the safe side I cleaned up the subdirectories created by "install", then did "gmake clean", run "config" with the new parameter and tried to build again: > time gmake all gmake: *** No rule to make target `src/compiler98/*.hc', needed by `targets/ix86-OpenBSD/compiler-gcc'. Stop. I had to import the entire tar file again. Could it be that "clean" was a bit too eager? Or not eager enough? Regards, -- Feliks

2 1