March 2002 - Nhc-bugs

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 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

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

Axis of Evil
by Wanted! 21 Mar '02

21 Mar '02

1 0

Re: [nhc-bugs] problems with 1.12
by Malcolm Wallace 20 Mar '02

20 Mar '02

> The whole thing failed at the end because we don't have Java, but I > guess this is not really needed for anything? ;-) You are right, it is not needed. I will disable the java build in the standard setup, since we supply a pre-built .jar file anyway. > P.S. Since I've also had transmission problems, I attach yesterday's > mail about the Solaris build. Thanks for the copy, but I received it yesterday. My reply (again) went to you alone, so I guess you are not receiving direct emails, only the ones on the nhc-bugs list. I'll copy that message to the list as well, to ensure you receive it. Regards, Malcolm

1 0

Fw: Re: [nhc-bugs] problems with 1.12
by Malcolm Wallace 20 Mar '02

20 Mar '02

Hi Feliks, > > (Forwarded message, original mistakenly sent only to Feliks.) > Never got the first one. [ I got a "not-delivered after 24 hours" warning on the original, which alerted me to the fact it was addressed only to you. ] > It's just that I was so impressed with the ease of porting the previous > two versions that I wondered whether there was anything in your > "process" that gave this effect and that you might be able to restore. Well it is true that at one time we built the compiler regularly on three different machine architectures (ix86-Linux, mips-IRIX, sparc-solaris). We no longer have any mips-IRIX machines, and the nightly sparc-solaris build is currently on hold due to an annoying feature of SSH, so there is only one machine/OS combination being tested daily at the moment. You are absolutely right that we should try to restore this part of our "process", since I am sure that its lack is the cause of many of the small errors you and others have been seeing. > Since hbc more or less expired, and ghc is excellent, but devilishly > difficult to port, I would imagine that portability could be _the_ > "selling" point for nhc, now that memory has become so cheap. We have always sold nhc98 on portability, and would like to continue to do so. > The file is there, and the symbols are there, too. > > I have a vague recollection that half a year ago (in another context, > nothing to do with nhc) I encountered a similar problem and that it had > something to do with assumptions about whether a library file is in > shareable format... I have a suggestion - try running `ranlib' on the archive file. I think the GNU ar does this automatically at creation time, but the BSD ar probably does not. If this fixes the problem, then I will add it to the Makefile. > I don't even know what "observe" does, so this might be irrelevant. It implements fast file-access primitives for the hat-observe program, which is (obviously) one of the Hat trace-browsing tools. If you aren't intending to use tracing (why not?! :-) then this part of the build doesn't matter to you anyway. Regards, Malcolm

1 0

Re: [nhc-bugs] problems with 1.12
by Malcolm Wallace 20 Mar '02

20 Mar '02

(Forwarded message, original mistakenly sent only to Feliks.) Feliks Kluzniak <feliks(a)crt.se> writes: > I find this a little worrying. The previous two versions of nhc were > quite painless to build on all sorts of systems, including Solaris and > OpenBSD: this is not an advantage that should be given up easily! I am sorry that you are having these problems, but it is inevitable that different operating systems have slightly different properties, and we cannot possibly test on all of them. Nevertheless, we do aim for nhc98 to be as painless as possible to build on any Unix-like machine. Your bug reports are very valuable in helping us to achieve that aim. > cd /q/pd/nhc/nhc98-1.12/targets/ix86-OpenBSD/obj/hattools && > /q/pd/nhc/nhc98-1.12/script/nhc98 +RTS -K10M -RTS +CTS -H20M -CTS > -o HatObserve Run.o PrettyLibHighlight.o HighlightStyle.o PrettyExp.o > HatExpressionTree.o HatTrie.o HatTrace.o HatObserve.o > /q/pd/nhc/nhc98-1.12/targets/ix86-OpenBSD/obj/hattools/hatlib.a > > observe.c:604: Undefined symbol `_newFunTable' referenced from text > segment observe.c:616: Undefined symbol `_addToFunTable' referenced > from text segment observe.c:624: Undefined symbol > `_FunTableCheckArities' referenced from text segment collect2: ld > returned 1 exit status It looks like your machine's version of 'ar' might differ from GNU ar. Those symbols are defined in the source file src/hat/tools/FunTable.c, which is compiled by $(CC) and added to the hatlib.a archive by the command ar -rc $(OBJDIR)/hatlib.a $(THOROBJS) The error messages refer to `observe.c', which is also a member of the archive. Perhaps you can use nm .../targets/ix86-OpenBSD/obj/hattools/hatlib.a to determine whether the file Funtable.o exists in the archive, and whether it does indeed define the symbols which are claimed to be missing. Send me any interesting information you find. Regards, Malcolm

1 0

a problem with 1.12
by Feliks Kluzniak 19 Mar '02

19 Mar '02

Hello, When I tried to build 1.12 (from the sources, on Solaris, with GHC, worked perfectly with 1.10), I got gcc -c -I../Kernel -I/q/pd/nhc/nhc98-1.12/include -D__EXTENSIONS__ -O3 -DHIGH_BYTE_FIRST -o /q/pd/nhc/nhc98-1.12/targets/sparc-solaris2/obj/runtime/Builtin/cFFI.o cFFI.c In file included from cFFI.c:3: HsFFI.h:5: stdint.h: No such file or directory Regards, -- Feliks

3 3