Hi, On Sat, Jun 20, 2009 at 09:14:54AM -0700, Judah Jacobson wrote:

...

Oops! The last sentence is a little bit misleading. The real problem seems to be the way haskeline's Setup.hs tries to check for libiconv (it doesn't use /usr/local/lib and /usr/local/include for libraries and include files even if you pass them via environment in LDDFLAGS and CPPFLAGS to configure for a complete ghc buidl).

Are you building ghc-6.10 or 6.11? For 6.10.3, you can specify extra library/include folders using EXTRA_CABAL_CONFIGURE_FLAGS in your mk/build.mk:

http://www.haskell.org/ghc/download_ghc_6_10_3.html#sources

For 6.11, ghc doesn't use Haskeline's Setup.hs file anymore (since the base library now also uses iconv), so I wouldn't expect you to have that problem.

Well, I actually was building 6.11, but I got confused with several trees with recent and not-so-recent versions. The actual failure was in libraries/base, where LDFLAGS and CPPFLAGS in the environment aren't passed to the sub makes nor to calls of inplace/bin/ghc-cabal (with appropriate options). I'm not sure wether this should be addressed in ghc's build system, in base or in cabal. FTR, here are the last lines of a LDFLAGS=-L/usr/local/lib CPPFLAGS=-I/usr/local/include \ ./inplace/bin/ghc-cabal configure -v3 \ --with-ghc=/home/kili/src/ghc/ghc-head/inplace/bin/dummy-ghc \ --with-ghc-pkg=/home/kili/src/ghc/ghc-head/inplace/bin/ghc-pkg \ --with-gcc=gcc --configure-option=--with-cc=gcc \ --with-hscolour=/usr/local/bin/HsColour \ -- dist-ins tall libraries/base configure: creating ./config.status config.status: creating base.buildinfo config.status: creating include/HsBaseConfig.h config.status: include/HsBaseConfig.h is unchanged Reading parameters from ./base.buildinfo ("/usr/bin/gcc",["/tmp/14231.c","-o","/tmp/14231","-D__GLASGOW_HASKELL__=611","-Iinclude","-I.","-I/home/kili/src/ghc/ghc-head/includes","-I/home/kili/src/ghc/ ghc-head/libffi/build/include","-liconv"]) /usr/bin/gcc returned ExitFailure 1 with error message: /usr/bin/ld: cannot find -liconv collect2: ld returned 1 exit status ("/usr/bin/gcc",["/tmp/14231.c","-o","/tmp/14231","-liconv"]) /usr/bin/gcc returned ExitFailure 1 with error message: /usr/bin/ld: cannot find -liconv collect2: ld returned 1 exit status ("/usr/bin/gcc",["/tmp/14231.c","-o","/tmp/14231","-liconv"]) /usr/bin/gcc returned ExitFailure 1 with error message: /usr/bin/ld: cannot find -liconv collect2: ld returned 1 exit status ("/usr/bin/gcc",["/tmp/14231.c","-o","/tmp/14231","-c","-D__GLASGOW_HASKELL__=611","-Iinclude","-I.","-I/home/kili/src/ghc/ghc-head/includes","-I/home/kili/src /ghc/ghc-head/libffi/build/include"]) ghc-cabal: Missing dependency on a foreign library: * Missing C library: iconv This problem can usually be solved by installing the system package that provides this library (you may need the "-dev" version). If the library is already installed but in a non-standard location then you can use the flags --extra-include-dirs= and --extra-lib-dirs= to specify where it is. Ciao, Kili

On Tue, Jun 23, 2009 at 01:47:00PM +0100, Ian Lynagh wrote:

...

* Fix detection of libiconf. It's not enough to try to link against libiconv and look for a symbol iconv_open, because iconv may be installed in a way that internally renames iconv_foo to libiconv_foo in the library and adds corresponding #define iconv_foo libiconv_foo to iconv.h.

This patch is needed on OpenBSD (but it's not enough, since cabal suffers from the same problem).

Thanks for the patch; unfortunately, it makes the build fail for me on OS X:

Undefined symbols: "_iconv_close", referenced from: _s20j_info in libHSbase-4.1.0.0.a(Iconv.o) "_iconv", referenced from: _s218_info in libHSbase-4.1.0.0.a(Iconv.o) "_iconv_open", referenced from: _s20d_info in libHSbase-4.1.0.0.a(Iconv.o) ld: symbol(s) not found collect2: ld returned 1 exit status make[1]: *** [utils/hsc2hs/dist-install/build/tmp/hsc2hs] Error 1 make[1]: *** Waiting for unfinished jobs.... Undefined symbols: "_iconv_close", referenced from: _s20j_info in libHSbase-4.1.0.0.a(Iconv.o) "_iconv", referenced from: _s218_info in libHSbase-4.1.0.0.a(Iconv.o) "_iconv_open", referenced from: _s20d_info in libHSbase-4.1.0.0.a(Iconv.o) ld: symbol(s) not found collect2: ld returned 1 exit status make[1]: *** [utils/ghc-pkg/dist-install/build/tmp/ghc-pkg] Error 1 make: *** [all] Error 2

Well, at least your build on MacOS X gets further than my build on OpenBSD ;-)

I haven't looked into what's going wrong yet.

Are there different versions of libiconv hanging around on MacOS X? What's the output from configure in libraries/base, and what's in config.log and config.status? If the configure test succeeds, then ghc-pkg is linking with different parameters than the configure test (which is similar to what happens for me on OpenBSD, but there ghc-cabal even fails to find libiconv and the build stops at ghc-cabal configure ... dist-install libraries/base). Ciao, Kili

On Wed, Jun 24, 2009 at 01:10:28AM +0100, Ian Lynagh wrote:

...

Thanks for the patch; unfortunately, it makes the build fail for me on OS X:

I haven't looked into what's going wrong yet.

OK, there were a number of problems, starting with the C program it tests not compiling due to NULL not being defined.

Ouch! Sorry.

Can you try with this instead, and let me know if it works for you please? And if not, please send me a copy of your config.log and base.buildinfo.

AC_SEARCH_LIBS(iconv_open, iconv, [EXTRA_LIBS="$EXTRA_LIBS $ac_lib"], [exit 1])

No, I can't, because now the build stops even earlier during ghc-cabal configure ,,, libraries/integer-gmp (see end of mail for the output). But your proposed AC_SEARCH_LIBS won't help anyway, because it generates a test program that just references the iconv_open() function without #including . However, on OpenBSD, libiconv.a does not define a symbol named iconv_open but libiconv_open: $ nm /usr/local/lib/libiconv.a | grep iconv_open 00011f84 T libiconv_open 000124b8 T libiconv_open_into And iconv.h #defines iconv_open to libiconv_open: $ grep -w libiconv_open /usr/local/include/iconv.h #define iconv_open libiconv_open I think if you take my diff and either just add an #include *or* remove the iconv(cd,NULL,NULL,NULL,NULL), it should survive on OS X. There is, however, still the problem that library and include paths passed to configure via the environment (like LDFLAGS, CPPFLAGS) aren't recognized by cabal, so even if configure is successfull, cabal (or ghc-pkg configure, in my case) will fail. Ciao, Kili here's the current failure on libraries/integer-gmp: "inplace/bin/ghc-cabal" configure --with-ghc="/home/kili/src/ghc/ghc-head/inplace/bin/dummy-ghc" --with-ghc-pkg="/home/kili/src/ghc/ghc-head/inplace/bin/ghc-pk g" --with-gcc="gcc" --configure-option=--with-cc="gcc" --with-hscolour="/usr/local/bin/HsColour" --configure-option=CFLAGS="-O -g -O2 " --configure-option=LD FLAGS="-L/usr/local/lib " -- dist-install libraries/integer-gmp Configuring integer-gmp-0.1.0.0... checking build system type... x86_64-unknown-openbsd4.5 checking host system type... x86_64-unknown-openbsd4.5 checking target system type... x86_64-unknown-openbsd4.5 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 __gmpz_fdiv_qr in -lgmp... yes configure: creating ./config.status config.status: creating integer-gmp.buildinfo config.status: creating gmp/config.mk ghc-cabal: Missing dependency on a foreign library: * Missing C library: gmp This problem can usually be solved by installing the system package that provides this library (you may need the "-dev" version). If the library is already installed but in a non-standard location then you can use the flags --extra-include-dirs= and --extra-lib-dirs= to specify where it is. gmake[1]: *** [libraries/integer-gmp/dist-install/package-data.mk] Error 1

On Wed, Jun 24, 2009 at 02:13:48PM +0100, Ian Lynagh wrote:

...

$ nm /usr/local/lib/libiconv.a | grep iconv_open 00011f84 T libiconv_open 000124b8 T libiconv_open_into

And iconv.h #defines iconv_open to libiconv_open: $ grep -w libiconv_open /usr/local/include/iconv.h #define iconv_open libiconv_open

Ah, I see what you mean. Does the attached patch work for you?

Yes, it seems to fix configure.

...

There is, however, still the problem that library and include paths passed to configure via the environment (like LDFLAGS, CPPFLAGS) aren't recognized by cabal, so even if configure is successfull, cabal (or ghc-pkg configure, in my case) will fail.

In rules/build-package-data.mk there are two lines:

$1_$2_CONFIGURE_OPTS += --configure-option=CFLAGS="$$(filter-out -Werror,$$(SRC_CC_OPTS)) $$($1_CC_OPTS) $$($1_$2_CC_OPTS)" $1_$2_CONFIGURE_OPTS += --configure-option=LDFLAGS="$$(SRC_LD_OPTS) $$($1_LD_OPTS) $$($1_$2_LD_OPTS)"

If you add two more lines:

$1_$2_CONFIGURE_OPTS += --gcc-options="$$(filter-out -Werror,$$(SRC_CC_OPTS)) $$($1_CC_OPTS) $$($1_$2_CC_OPTS)" $1_$2_CONFIGURE_OPTS += --ld-options="$$(SRC_LD_OPTS) $$($1_LD_OPTS) $$($1_$2_LD_OPTS)"

then does that fix the problem?

The second added line doesn't work as expected. I explicitely have to set CFLAGS="-I/usr/local/include -L/usr/local/lib". It seems like cabal only uses --gcc-options when running gcc (and ignoring --ld-options). So for now, the addition of --gcc-options helps me to build ghc-head again. FYI, below is the output of ghc-cabal with an added -v3 when CFLAGS="-I/usr/local/include" (without -L/usr/local/lib). Ciao, Kili $ "inplace/bin/ghc-cabal" configure --with-ghc="/home/kili/src/ghc/ghc-head/inplace/bin/dummy-ghc" --with-ghc-pkg="/home/kili/src/ghc/ghc-head/inplace/bin/ghc-pkg" --with-gcc="gcc" --configure-option=--with-cc="gcc" --with-hscolour="/usr/local/bin/HsColour" --configure-option=CFLAGS="-O -I/usr/local/include " --configure-option=LDFLAGS="-L/usr/local/lib " --gcc-options="-O -I/usr/local/include " --ld-options="-L/usr/local/lib " -v3 -- dist-install libraries/integer-gmp [boring stuff skipped] ("sh",["configure","--with-compiler=ghc","--with-cc=gcc","CFLAGS=-O -I/usr/local/include ","LDFLAGS=-L/usr/local/lib "]) checking build system type... x86_64-unknown-openbsd4.5 checking host system type... x86_64-unknown-openbsd4.5 checking target system type... x86_64-unknown-openbsd4.5 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 __gmpz_fdiv_qr in -lgmp... yes configure: creating ./config.status config.status: creating integer-gmp.buildinfo config.status: creating gmp/config.mk Reading parameters from ./integer-gmp.buildinfo ("/usr/bin/gcc",["-O","-I/usr/local/include","/tmp/2499.c","-o","/tmp/2499","-O","-I/usr/local/include","-D__GLASGOW_HASKELL__=611","-I.","-I/home/kili/src/ghc/ghc-head/includes","-I/home/kili/src/ghc/ghc-head/libffi/build/include","-lgmp"]) /usr/bin/gcc returned ExitFailure 1 with error message: /usr/bin/ld: cannot find -lgmp collect2: ld returned 1 exit status ("/usr/bin/gcc",["-O","-I/usr/local/include","/tmp/2499.c","-o","/tmp/2499","-lgmp"]) /usr/bin/gcc returned ExitFailure 1 with error message: /usr/bin/ld: cannot find -lgmp collect2: ld returned 1 exit status ("/usr/bin/gcc",["-O","-I/usr/local/include","/tmp/2499.c","-o","/tmp/2499","-lgmp"]) /usr/bin/gcc returned ExitFailure 1 with error message: /usr/bin/ld: cannot find -lgmp collect2: ld returned 1 exit status ("/usr/bin/gcc",["-O","-I/usr/local/include","/tmp/2499.c","-o","/tmp/2499","-c","-O","-I/usr/local/include","-D__GLASGOW_HASKELL__=611","-I.","-I/home/kili/src/ghc/ghc-head/includes","-I/home/kili/src/ghc/ghc-head/libffi/build/include"]) ghc-cabal: Missing dependency on a foreign library: * Missing C library: gmp This problem can usually be solved by installing the system package that provides this library (you may need the "-dev" version). If the library is already installed but in a non-standard location then you can use the flags --extra-include-dirs= and --extra-lib-dirs= to specify where it is.

On Wed, Jun 24, 2009 at 06:03:27PM +0200, Matthias Kilian wrote:

On Wed, Jun 24, 2009 at 04:43:02PM +0200, Matthias Kilian wrote:

...

...

$1_$2_CONFIGURE_OPTS += --gcc-options="$$(filter-out -Werror,$$(SRC_CC_OPTS)) $$($1_CC_OPTS) $$($1_$2_CC_OPTS)" $1_$2_CONFIGURE_OPTS += --ld-options="$$(SRC_LD_OPTS) $$($1_LD_OPTS) $$($1_$2_LD_OPTS)"

then does that fix the problem?

The second added line doesn't work as expected. I explicitely have to set CFLAGS="-I/usr/local/include -L/usr/local/lib". It seems like cabal only uses --gcc-options when running gcc (and ignoring --ld-options). So for now, the addition of --gcc-options helps me to build ghc-head again.

Except that now ghc-stage1 fails to link ghc-stage2:

"inplace/bin/ghc-stage1" -o ghc/stage2/build/tmp/ghc-stage2 -H32m -O -i -ighc/. -ighc/stage2/build -ighc/stage2/build/autogen -Ighc/stage2/build -Ighc/stage2/build/autogen -O -fasm -DGHCI -threaded -package ghc-6.11.20090624 -package haskeline -XCPP -XPatternGuards -XForeignFunctionInterface -XUnboxedTuples -XFlexibleInstances -XMagicHash -no-user-package-conf -odir ghc/stage2/build -hidir ghc/stage2/build -stubdir ghc/stage2/build -hisuf hi -osuf o -hcsuf hc ghc/stage2/build/Main.o ghc/stage2/build/GhciMonad.o ghc/stage2/build/GhciTags.o ghc/stage2/build/InteractiveUI.o /usr/bin/ld: cannot find -liconv

I could probably "fix" it by setting LD_OPTS, but I don't think that's a proper fix. I didn't find where compiler/stage2/package-data.mk gets its compiler_stage2_LD_OPTS variable set (i tried to set $1_$2_LD_OPTS in rules/build-package-data.mk, but it didn't help). And it's probably still the wrong place to fix it. The knowledge that linking against base needs -L/usr/local/lib (for to find libiconv) should be stored in the entry of base in the package.conf.

We don't have that knowledge, though. All we could do is to stick all the linker flags we are using in there, which might include all sorts of things that you wouldn't want in the package.conf. One possibility is we could have some sort of base_linker_flags variable, that you would manually set to -L/usr/local/lib, and we could put that in the package.conf. But what I don't get is: If you need to specify -L/usr/local/lib when linking a C program against iconv, why should you expect to be able to link a Haskell program against base without specifying -L/usr/local/lib? It's probably a bug that the stage2 link step isn't using the flag, if you've got this far. Where do you have -L/usr/local/lib now? Just in LD_FLAGS? Thanks Ian

On Wed, Jun 24, 2009 at 04:43:02PM +0200, Matthias Kilian wrote:

On Wed, Jun 24, 2009 at 02:13:48PM +0100, Ian Lynagh wrote:

...

...

$ nm /usr/local/lib/libiconv.a | grep iconv_open 00011f84 T libiconv_open 000124b8 T libiconv_open_into

And iconv.h #defines iconv_open to libiconv_open: $ grep -w libiconv_open /usr/local/include/iconv.h #define iconv_open libiconv_open

Ah, I see what you mean. Does the attached patch work for you?

Yes, it seems to fix configure.

Great, thanks; I've pushed it.

...

$1_$2_CONFIGURE_OPTS += --gcc-options="$$(filter-out -Werror,$$(SRC_CC_OPTS)) $$($1_CC_OPTS) $$($1_$2_CC_OPTS)" $1_$2_CONFIGURE_OPTS += --ld-options="$$(SRC_LD_OPTS) $$($1_LD_OPTS) $$($1_$2_LD_OPTS)"

then does that fix the problem?

The second added line doesn't work as expected. I explicitely have to set CFLAGS="-I/usr/local/include -L/usr/local/lib". It seems like cabal only uses --gcc-options when running gcc (and ignoring --ld-options). So for now, the addition of --gcc-options helps me to build ghc-head again. FYI, below is the output of ghc-cabal with an added -v3 when CFLAGS="-I/usr/local/include" (without -L/usr/local/lib).

Thanks; I've filed a ticket here: http://hackage.haskell.org/trac/hackage/ticket/564 Thanks Ian