On Mon, Sep 22, 2008 at 03:32:40PM +0200, Christian Maeder wrote:

I've tried to build a binary dist on x86 under Solaris and did not succeed.

"make binary-dist" failed with

1. for FILE in ; do if [ -e $FILE ]; then echo ghc-6.10.0.20080921/gmp/$FILE >> /export/local1/home/maeder/haskell/ghc-6.10.0.20080921/bindist-list ; fi; done /bin/sh: syntax error at line 1: `;' unexpected gmake[1]: *** [binary-dist] Error 2

I added "strip" to bindist.mk: ifneq "$(strip $(BINDIST_EXTRAS))" ""

This part could be done a little bit different (without the conditional): ... # And enything else echo $(BINDIST_EXTRAS) | \ xargs -n1 | \ sed '/^$/d;s/.*/test -e & \&\& echo $(WHERE_AM_I)\/&/' | \ sh >> $(BIND_DIST_LIST) (untested!)

2. /bin/sh: test: argument expected gmake[1]: *** [binary-dist] Error 1

-e does not work for test under "sh", so I changed it to "-r": ... if [ -r $$FILE ]; then ...

I doubt `-e' doesn't work on Solaris, because `-e' is POSIX. Does this "argument expected" still appear with your fix to 1.?

3. tar hcf /export/local1/home/maeder/haskell/ghc-6.10.0.20080921/ghc-6.10.0. 20080921-i386-unknown-solaris2.tar -T /export/local1/home/maeder/haskell/ghc-6.10.0.20080921/bindist-list tar: -T: No such file or directory gmake: *** [binary-dist] Error 1

I changed tar to gtar

Or use pax(1), which in contrast to tar(1) and gtar(1) is POSIX: pax -hwf $(BIN_DIST_TAR) < $(BIN_DIST_LIST) (also untested, but should work)

4. gtar: ghc-6.10.0.20080921/gmp/{}: Cannot stat: No such file or directory

The file bindist-list contained "{}" instead of filenames, so I changed find to gfind.

Or just omit all the -exec echo ${WHERE_AM_I}/{} goo and use find(1) and sed(1), e.g.: find $(WHATEVER) -print | sed 's/^/$(WHERE_AM_I}\//'

5. When trying to install the binary distribution I got:

Installing executable(s) in /local/home/maeder/bin installPackage: dist-install/build/installPackage/installPackage: copyFile: does not exist (No such file or directory)

Maybe fallout from some of the above problems? Ciao, Kili

The error far below is caused by "-perm /a+x" in mk/bindist.mk during find: I've changed it to "-perm -111" Then "make install" could not replace links: ln -s runghc /local/home/maeder/bin/runhaskell ln: cannot create /local/home/maeder/bin/runhaskell: File exists gmake[2]: *** [install] Error 2 But finally installation succeeded (editline is missing and the arrow keys don't work). Why are there 2 base packages? Cheers Christian -bash-3.1$ ghc-pkg list /local/home/maeder/share/ghc-6.10.0.20080921/./package.conf: Cabal-1.5.5, HUnit-1.2.0.0, QuickCheck-1.1.0.0, array-0.2.0.0, base-3.0.3.0, base-4.0.0.0, bytestring-0.9.0.1.2, containers-0.2.0.0, directory-1.0.0.2, (dph-base-0.3), (dph-par-0.3), (dph-prim-interface-0.3), (dph-prim-par-0.3), (dph-prim-seq-0.3), (dph-seq-0.3), filepath-1.1.0.1, (ghc-6.10.0.20080921), ghc-prim-0.1.0.0, haddock-2.2.2, haskell-src-1.0.1.2, haskell98-1.0.1.0, hpc-0.5.0.2, html-1.0.1.1, integer-0.1.0.0, mtl-1.1.0.1, network-2.2.0.0, old-locale-1.0.0.1, old-time-1.0.0.1, packedstring-0.1.0.1, parallel-1.0.0.1, parsec-2.1.0.1, pretty-1.0.1.0, process-1.0.1.0, random-1.0.0.1, regex-base-0.72.0.1, regex-compat-0.71.0.1, regex-posix-0.72.0.2, rts-1.0, stm-2.1.1.1, syb-0.1.0.0, template-haskell-2.3.0.0, time-1.1.2.1, unix-2.3.1.0, xhtml-3000.2.0.1 Christian Maeder wrote:

...

...

5. When trying to install the binary distribution I got:

Installing executable(s) in /local/home/maeder/bin installPackage: dist-install/build/installPackage/installPackage: copyFile: does not exist (No such file or directory) Maybe fallout from some of the above problems?

No, on an Intel Mac I got the same error (without the previous problems):

Installing executable(s) in /Users/Shared/maeder/bin installPackage: dist-install/build/installPackage/installPackage: copyFile: does not exist (No such file or directory) make[2]: *** [install] Error 1 make[1]: *** [install.installPackage] Error 2 make: *** [install] Error 2

Thanks anyway Christian

Judah Jacobson wrote:

On Tue, Sep 23, 2008 at 6:38 AM, Christian Maeder wrote:

...

But finally installation succeeded (editline is missing and the arrow keys don't work).

This means that the editline package could not be built for some reason. Is this on your OS X machine? If so, it's strange because libedit should be installed on OS X by default; what OS version are you running? If you separately download and build the editline package from hackage, what errors do you get?

It works fine under OS X. My problem is under x86 solaris. See below my output when trying to install http://hackage.haskell.org/packages/archive/editline/0.2/editline-0.2.tar.gz Cheers Christian -bash-3.1$ cp /local/home/maeder/lib/ghc-6.10.0.20080921/unlit /local/home/maeder/share/ghc-6.10.0.20080921/ -bash-3.1$ ghc --make Setup.lhs [1 of 1] Compiling Main ( Setup.lhs, Setup.o ) Setup.lhs:3:0: Warning: In the use of `defaultUserHooks' (imported from Distribution.Simple): Deprecated: "Use simpleUserHooks or autoconfUserHooks, unless you need Cabal-1.2 compatibility in which case you must stick with defaultUserHooks" Linking Setup ... -bash-3.1$ ./Setup configure --prefix=/local/home/maeder Warning: defaultUserHooks in Setup script is deprecated. Configuring editline-0.2... checking for gcc... gcc checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ANSI C... none needed checking for tputs in -lncurses... yes checking for el_init... no checking for readline... no checking how to run the C preprocessor... gcc -E checking for egrep... egrep checking for ANSI C header files... no checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking editline/readline.h usability... no checking editline/readline.h presence... no checking for editline/readline.h... no checking editline/editline.h usability... no checking editline/editline.h presence... no checking for editline/editline.h... no checking readline/readline.h usability... yes checking readline/readline.h presence... yes checking for readline/readline.h... yes checking for sign of read_history result on error... negative configure: error: editline not found, so this package cannot be built See `config.log' for more details.

On Wed, Sep 24, 2008 at 3:09 AM, Christian Maeder wrote:

Hi Judah,

libedit is simply missing. but ghci used to work with readline! Do I need to install i.e. http://www.thrysoee.dk/editline/libedit-20080712-2.11.tar.gz as a static library in order to create code depending on libedit that can be run on machines without libedit? (This reminds me to the gmp and readline whims on Macs.)

Sure, if you're talking about a program that does user interaction with the libedit library, then I suppose so. But I don't expect this to cause many problems in practice, since - Programs compiled with ghc don't need libedit to run unless they explicitly depend on the editline package, and - There's nothing stopping you from writing and distributing programs that depend on readline instead; just install the readline package from Hackage. -Judah

On Tue, Sep 23, 2008 at 08:34:36PM +0200, Matthias Kilian wrote:

...

I've changed it to "-perm -111"

Unfortunately, this will only find files with the executable bit set for user, group and owner, so it should be "-perm +111". However, even more unfortunately, at least the find(1) on OpenBSD doesn't support the +mode pattern.[...]

According to http://www.opengroup.org/onlinepubs/000095399/utilities/find.html `-perm +onum' (where onum is an octal number) seems to be yet another gnuism, so `-perm -100' is probably the most portable (and least breaking) option for any system not using gfind. Ciao, Kili

On Sep 22, 2008, at 13:43 , Christian Maeder wrote:

Matthias Kilian wrote:

...

...

2. /bin/sh: test: argument expected gmake[1]: *** [binary-dist] Error 1

-e does not work for test under "sh", so I changed it to "-r": ... if [ -r $$FILE ]; then ...

I doubt `-e' doesn't work on Solaris, because `-e' is POSIX. Does this "argument expected" still appear with your fix to 1.?

It does not work on my system (SunOS 5.10 Generic_137112-07 i86pc):

Solaris's /bin/sh is not POSIX; /usr/xpg4/bin/sh is the POSIX compatible shell. -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH

Ian Lynagh wrote:

On Mon, Sep 22, 2008 at 03:32:40PM +0200, Christian Maeder wrote:

...

Ian Lynagh wrote:

...

Right now we have the source bundles:

http://www.haskell.org/ghc/dist/stable/dist/ghc-6.10.0.20080921-src.tar.bz2 http://www.haskell.org/ghc/dist/stable/dist/ghc-6.10.0.20080921-src-extralib... I've tried to build a binary dist on x86 under Solaris and did not succeed.

Thanks Christian et al; all the issues you've identified should now be fixed in darcs.

Yes, I've noticed your patches. They look good (but how knows without testing). Thank You! Christian

On Mon, Sep 22, 2008 at 2:28 PM, Wei Hu wrote:

I tried it out in Emacs, but ghci always displays some sort of garbage message. For example, when I ask for the value of 0, I get: 0^J0

Is it because ghci switched to libedit? I'm running Emacs-23 with haske-mode- cvs on Debian unstable.

Do you have the libedit-dev package installed? If not, the editline backend may not have been built. You can check whether it was built by running ghci from a command prompt and checking whether the arrow keys work. -Judah

On Tue, Sep 23, 2008 at 05:02:23AM +0000, Wei Hu wrote:

I forgot to mention that I was running the binary package -- didn't bother to build ghc from source. Because the binary package relies on libedit.so.0 and Debian only comes with libedit2, I created a symbolic link for libedit.so.0 pointing to libedit.so.2. Could that be a problem for Emacs? But the libedit backend works fine when running ghci from a command line.

It sounds like emacs isn't understanding the libedit output then. Can any emacs experts provide any clues? Thanks Ian

Hi Paul, On Tue, Sep 23, 2008 at 09:09:03PM -0400, Paul Jarc wrote:

I ran into some problems due to having gmp installed in an unusual place. I passed --with-gmp-{includes,libraries} to ./configure, set $CPPFLAGS and $LDFLAGS for ./configure, and set the corresponding -optl, etc., flags in SRC_HC_OPTS and GHC_CC_OPTS in mk/build.mk.

With all that, the first problem I hit was with utils/pwd/pwd. ./configure builds it by calling ghc without any special flags, so the binary can't find libgmp.so at runtime.

I'm confused. If the bootstrapping GHC uses a gmp from a non-standard directory, then that directory should be listed in the "library-dirs" field of the rts package. You shouldn't need to tell GHC where it is whenever you run GHC. Thanks Ian

Hi Paul, On Wed, Sep 24, 2008 at 05:02:28PM -0400, Paul Jarc wrote:

Ian Lynagh wrote:

...

I'm confused. If the bootstrapping GHC uses a gmp from a non-standard directory, then that directory should be listed in the "library-dirs" field of the rts package.

Running "strings" on the bootstrap compiler's lib/ghc-6.8.3/libHSrts* shows some references to the gmp include directory, but none to the library directory. I can try rebuilding 6.8.3, keeping the build directory for inspection afterwards to see what's happening there.

Running ghc-pkg describe rts will show you library-dirs, amongst other things. If that's the problem then you should be able to edit /usr/lib/ghc-6.8.2/package.conf or similar, and add the directory to the libraryDirs of the rts package entry. Thanks Ian

On Sat, Sep 27, 2008 at 03:10:04PM +0200, Matthias Kilian wrote:

BTW: I had some problems running the testsuite some weeks ago, because some autoconf'd stuff was missing. When building from the repository (*not* from the source tarballs), are there any additional steps beyond

sh boot ./configure --prefix=... gmake install

required?

I'm not sure if running "gmake install" without first running "gmake" works. Also, note that if you are building the extralibs then you need to run "sh boot" after getting them. Thanks Ian

On Mon, Sep 29, 2008 at 07:07:33PM +0200, Matthias Kilian wrote:

And my problem with the testsuite was a PEBKAC (of course): on OpenBSD, python is installed as python-2.3, python-2.4, python-2.5 (you can have several versions installed in parallel), which isn't found by configure, which in turn lets the testsuite bail out. Setting PythonCmd during configure fixed it.

I've yet to evaluate the results of the testsuite. I'll post it in a few hours.

Summary (skipping all the details): OVERALL SUMMARY for test run started at Sun Sep 28 17:57:33 CEST 2008 2233 total tests, which gave rise to 12011 test cases, of which 0 caused framework failures 2244 were skipped 9324 expected passes 140 expected failures 20 unexpected passes 283 unexpected failures This looks more scary than it is; many unexpected failures are caused by a change in Rational formatin ("17%42" vs. "17 % 42"), some others are probably caused by OpenBSD specific stuff (e.g., warnings about the use of unsafe functions like strcpy(3), different output behaviour on signals like SIGSEGV, and, well the unicode (causing unexpected passes) and some threading differences are most probably also OS-dependent candidates). Some problems are not strictly OpenBSD specific, but just triggered due to the more restrictive default limits (number of open file descriptors, datasize, etc.). Finally, some tests just did time out (this isn't the fastest machine in the universe). A full test log is available at http://openbsd.dead-parrot.de/ghctests/ghc-6.10-openbsd-i386.log And a shorter log (using a really horrible awk script for stripping down the full log): http://openbsd.dead-parrot.de/ghctests/ghc-6.10-openbsd-i386.shortlog Fallout from the following tests looks a little bit suspicious: num009 num012 galois_raytrace (well, I didn't read the whol diff ;-)) driver019 (I think a fix for this has been pushed during the last 24 hours) ffi009 tough all the hpc stuff copyFile001 (but there was a push for it recently, IIRC) Ciao, Kili

On Mon, Sep 29, 2008 at 10:26:35PM +0200, Matthias Kilian wrote:

A full test log is available at http://openbsd.dead-parrot.de/ghctests/ghc-6.10-openbsd-i386.log

Same for openbsd-amd64, built from sources pulled from the darcs repository at 15/Oct/2008:13:00:00 +0200: http://openbsd.dead-parrot.de/ghctests/ghc-6.10-openbsd-amd64.log OVERALL SUMMARY for test run started at Wed Oct 15 21:07:08 CEST 2008 2252 total tests, which gave rise to 12108 test cases, of which 0 caused framework failures 2301 were skipped 8846 expected passes 128 expected failures 0 unexpected passes 833 unexpected failures And for ghc-head (pulled an hour later): http://openbsd.dead-parrot.de/ghctests/ghc-head-openbsd-amd64.log OVERALL SUMMARY for test run started at Thu Oct 16 12:36:23 CEST 2008 2252 total tests, which gave rise to 12108 test cases, of which 0 caused framework failures 2294 were skipped 8917 expected passes 128 expected failures 0 unexpected passes 769 unexpected failures Most failures are caused by ghci which is still broken for openbsd-amd64. Unfortunately, I don't have enough time to look at the other failures now. Ciao, Kili