From: Duncan C. <dun...@wo...> - 2007-02-04 16:25:00
|
On Sun, 2007-02-04 at 16:02 +0000, Axel Simon wrote: > On Sun, 2007-02-04 at 14:37 +0000, Duncan Coutts wrote: > > On Sun, 2007-02-04 at 12:49 +0000, Axel Simon wrote: > > > Duncan, > > > > > > you're really living on the edge: I need to update pkg-config to 0.21 > > > since in version 0.20 the macro PKG_CHECK_MODULES does not exist. > > > > I'm using pkg-config 0.20 and it has those macros > > (in /usr/share/aclocal/pkg.m4). I think it's had them for ages. There > > must be something wrong with the pkg-config package on your system. > > Arrgh. Yes, there is. I locally installed a new autoconf version in > order to get the AC_PROG_GREP etc. macros. However, this installs an > aclocal with its only directory of macros, in particular, the > system-wide pkg-config installed its macros in /usr/share/aclocal/pkg.m4 > which the new aclocal in /usr/local/bin does not search for. Hence, the > new autoconf gives me AC_PROG_GREP, but not PKG_CHECK_MODULES and all > the other macros of software that is installed. Yay for autotools hell. The long term plan has to be to move to using Cabal to build. This will require improvements in c2hs and Cabal. > Solution: > > > I suppose we could. We'd only have top copy PKG_PROG_PKG_CONFIG and > > PKG_CHECK_MODULES from pkg.m4. > > I copied the necessary definitions of AC_PROG_GREP and AC_PROG_SED into > acinclude.m4 with the appropriate comments that we remove these as soon > as we require 2.61 (rather than 2.59). Ok great. I just tried it on an FC3 box with AC 2.59 and it now works fine. > > Quick summary of feedback on RC2: > > > > So far there have been 83 downloads from 67 separate ip addresses > > (excluding 11 by myself and bizarrely 32 downloads from > > bugs.haskell.org). 44 people have downloaded the tarball and 25 the > > windows installer. I've received successful build reports from people on > > FreeBSD and Mac OS X 10.4 as well as the usual Linux and Windows. > > Cool. I've seen about 4 or 5 people subscribing to gtk2hs-users, which > is good, too. Oh, nice. > > So far I've had two build bug reports: one about too-long command line > > lengths on Linux when ld'ing the split-objs .o files and the other some > > as-yet undiagnosed problem with the in-place package registration. > > I'm now using in-place (to avoid the root-problem) and had no problems > so far. So thanks for putting this option back in. Oh, this is a different thing I think. Allowing it to register with the "--user" package db when we install is one thing, the inplace registration of packages in ${top}/package.conf.inplace is another. The report I had was that when it started compiling the cairo package it failed to find the glib-0.9.10.6 package that should have been registered in package.conf.inplace. (cairo is the first package that gets compiled that depends on another package.) We're still investigating why that happens. Duncan |