I assume this is the correct mailing list to send a report of my workings on nhc98 to get an updated NetBSD port. It is sent CC to since he is the current nhc98 maintainer of the NetBSD package in the NetBSD pkgsrc tree. I am reporting on a number of issues with the package. The rationale for this report is to inform various parties of the problems I have encountered, so they can be thought of in later releases. As a consequence the emphasis of this mail will target the build system, the system infrastructure at york(!) and interfacing with NetBSD in general. Communication often makes the difference between a success and failure when porting software. I also hope Krister does not feel I have hi-jacked his work. A NetBSD package is a Makefile, along with some helping files. The makefile accepts a number of targets which fetches the source code, configures it for NetBSD, patches the sources, compiles the program and installs the program in such a way it can be easily deleted again. The approach is different from binary package distribution, but is equal to other Operating systems, noteably the *BSD family and Gentoo Linux. The first problem with updating the package is the retrieval phase. This is done by a program, ftp(1), which will try to fetch the file ftp://ftp.cs.york.ac.uk/pub/haskell/nhc98/nhc98src-1.18.tar.gz. Unfortunately, this fails because the york ftp-server and ftp(1) agrees on entering Extended Passive Mode (EPRT and EPSV as per RFC 2428) which I then suspect the york firewall to disallow. Note that programs such as FreeBSDs fetch(1) and wget(1) of GNU chooses not entering EPRT/EPSV mode; thus having no problems fetching the source code. The direct solution to this problem would be to fix the firewall. We could add a workaround into the packages fetching process, but this has a number of implications. First, it is not the correct solution to the problem. Second, the fetching is generalized and not necessarily done by ftp(1). Altering the options given to the ${FETCH_COMMAND} is not portable if another retrieval program is chosen. The obvious way to bootstrap nhc98 would be by gcc. Unfortunately, NetBSDs package tree can select the compiler to be something other than gcc. The reason is the portability of NetBSD. If running on another architecture than, say i386, one could choose a native compiler over gcc for compilation. As a consequence $(CC) is set to be ``cc'' when compiling the nhc98 Makefile; not ``gcc'' as expected. My crude solution were to oversteer $(CC) and substitute it for ${BUILDCOMP}, see patches further down. This leads to my question: Can nhc98 be compiled by anything else than nhc98? Have you tried? I can alter the package to constrain itself to certain compilers in the case of impossibility. The next problem I ran into in the upgrade process from 1.16 is a number of old patches we put on the source code before compiling. The patches are all laid out at the following url: http://cvsweb.netbsd.org/bsdweb.cgi/pkgsrc/lang/nhc98/patches/ I will write [aa] for patch-aa, [ab] for patch-ab and so forth. Here is my findings. [aa] concerns an addition of $LDFLAGS to the curses compilation. This is done because the NetBSD package system can set further linker directives in this variable and we need to honour them. [ab] concerns an errornous way of calling abort(3). This is fixed in 1.18 and can go away. [ac, ad, af, ag] are all patches from the nhc98 homepage for nhc1.16. These are obviously not needed for 1.18 and can go away. [ae] does not seem to apply anymore. I am on a -current NetBSD and had no build problems. [ah] adjusts for $(CC) by substituting it for $(BUILDCOMP). I think this is the correct solution, so I have adapted that one. That is all. Unless I get complaints from any department - I will submit a change to the NetBSD bug-tracker in a couple of days. -- jlouis